bbb update..

Ed Sutter edsutterjr at gmail.com
Wed Jun 24 01:33:23 UTC 2015


No worries, I understood...
> 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"
> commands.
>
> On Tue, Jun 23, 2015 at 5:55 PM, Jarielle Catbagan
> <jcatbagan93 at gmail.com> wrote:
>> 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