bbb update..

[Jarielle Catbagan]

Ed,

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)

$(HOME)/opt/arm-rtems4.11/lib/libc.a


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
process.

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
process.

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:
>>
>> Jarielle,
>> 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.
>> Ed
>> _______________________________________________
>> umon-devel mailing list
>> umon-devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/umon-devel