bbb update..

Ed Sutter edsutterjr at gmail.com
Wed Jun 24 01:36:31 UTC 2015


I guess my home machine is more of a 'dog' than I thought...
Taking much too long to build.  Might be time to invest in a new machine!
I was hoping to get the tools built, and your patches committed after testing
on the board....  Not looking too good so far.  :-(
> 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
> _______________________________________________
> umon-devel mailing list
> umon-devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/umon-devel
>




More information about the umon-devel mailing list