jcatbagan93 at gmail.com
Wed Jun 24 01:03:55 UTC 2015
I realize that my statement about being able to execute any of the
commands is ambiguous. I meant to refer to the "help", "dm", and "pm"
On Tue, Jun 23, 2015 at 5:55 PM, Jarielle Catbagan
<jcatbagan93 at gmail.com> wrote:
> Ok, so the data exception has been removed and now executing any of
> the commands can complete successfully. I built Umon using the
> arm-rtems4.11 toolset.
> The steps I had to take to successfully build Umon after removing the
> __ctype_ptr__ pointers in docmd.c is quite involving and I was able to
> reach a solution after several hours of debugging.
> I will now elaborate the situation that I underwent:
> The first thing that I did was I replaced the arm-none-eabi toolset
> with the arm-rtems4.11 toolset in the BBB Makefile. I next removed
> the __ctype_ptr__ pointers from docmd.c. With that in place, I built
> Umon but it failed with the linking process indicating the there was
> undefined reference to __ctype_ptr__.
> I figured that __ctype_ptr__ is defined in the the C library that came
> with the arm-rtems4.11 toolset and so I directly linked to the C
> library during the linking process with the file (for me arm-rtems4.11
> toolset is installed under 'opt' in my home directory)
> Doing this caused several errors. The first is that linking this
> library also had undefined references. After some extensive analysis,
> these references were defined in $(HOME)/opt/arm-rtems4.11/lib/crt0.o
> and as a result I also had to link this file during the linking
> The last set of errors were multiple redefinitions. Since Umon has a
> set of internal functions whose names also coincide with those in the
> C library, incorporating locally defined functions together with
> standard-defined functions by linking the C library resulted in
> multiple definition errors. I rectified these errors by passing the
> option "--allow-multiple-defintion" to the linker during the linking
> With all of this set in place, I was able to build Umon successfully
> with the arm-rtems4.11 toolset and have verified that the images work
> on the BBB with no data abort exception occuring.
> One thing I'd like to mention is that these mechanisms in place does
> not feel natural to me. One of which is mixing locally defined
> functions with standard-defined functions with the same names.
> Another is having to specify an option to ignore multiple
> redefinitions. To me this could potentially be error prone if the
> order of libraries included defining the same set of functions does
> not match the intention of a particular function executing rather than
> the other.
> As a result, I want to find a more elegant solution. I am open to
> advice and suggestions on how to proceed.
> One thing that has occured to me, is that it seems that the same steps
> I undertook when setting up Umon to be built with the arm-rtems4.11
> toolset is that it looks like I could have done this as well with the
> arm-none-eabi toolset. Since the main focus is to transition to the
> RTEMS compiler, this probably doesn't matter anymore.
> I am curious, were these the same set of steps that you had to take to
> build Umon with the RTEMS toolset?
> On Tue, Jun 23, 2015 at 12:23 PM, Jarielle Catbagan
> <jcatbagan93 at gmail.com> wrote:
>> Hi Ed,
>> That is good news! I am currently setting up my development environment to
>> do the same as well. Once I get that done I'll be inspecting the binaries
>> and testing it on my BBB. I'll notify here how it goes.
>> On Jun 23, 2015 12:17 PM, "Ed Sutter" <ed.sutter at alcatel-lucent.com> wrote:
>>> Ok, I got the RTEMS based tools built on my machine here at work
>>> and then rebuilt with the __ctype_ptr__ stuff removed and it builds
>>> clean! This is (hopefully) great news.
>>> I can't test it till tonight (my beaglebone is at home); but my guess
>>> is that the isspace() mystery is solved.
>>> umon-devel mailing list
>>> umon-devel at rtems.org
More information about the umon-devel