BBB/AM335x: isspace() results in data abort exception in strtol() in strtol.c and strtoul() in strtoul.c

[Jarielle Catbagan]

On Tue, Jun 23, 2015 at 6:49 AM, Ed Sutter <ed.sutter at alcatel-lucent.com> wrote:
> On 6/23/2015 9:39 AM, Jarielle Catbagan wrote:
>>
>> Ed,
>>
>> I was doing some further investigation last night and I found the same
>> results as well in that for some reason the table that __ctype_ptr__
>> is suppose to point to is not included in the build, and hence not
>> updated accordingly.
>>
>> I had a look at the standard-defined header file <ctype.h> that was
>> included when I installed "arm-none-eabi-gcc" and found the
>> declaration of __ctype_ptr__.
>>
>> >From <ctype.h> it is:
>>
>> extern __IMPORT char *__ctype_ptr__;
>>
>>
>> If I am interpreting this correctly, implementations that include
>> <ctype.h> rely on __ctype_ptr__ to be defined else where.  The
>> question is where?  Could it perhaps be defined in the chunk of code
>> along with the ctype-ish table, but is not included by gcc which is
>> why the link fails without the declartion of the __ctype_ptr__.
>
> I've seen it go both ways depending on the system/toolset. Sometimes there's
> an array named ctype_something[], and an initialized pointer (like
> __ctype_ptr__)
> that is pointing to it.  Other times, there's just an array and the macros
> use it
> directly.  If you google __ctype_ptr__ you'll see a variety.  Not sure why
> this is.
>>
>> To me, it makes sense that the __ctype_ptr__ should be updated
>> appropriately during the build process right after the ctype-ish table
>> is integrated.  This leads me to the question as to what could be
>> missing during the link process?  I'll definitely be looking into this
>> more.
>>
>> I was thinking a solution to this, which would probably not be
>> practical and elegant and possibly only a temporary one if ever, is to
>> define the ctype-ish table and just update __ctype_ptr__ to point to
>> that.  That's probably only a last case scenario.  It would make sense
>> that this table should be pulled into the build automatically, but
>> it's not.  I'll be looking more into this.
>
> Right, that's essentially what I removed from the umon1.19 stuff when I was
> creating
> the initial umon tarball for RTEMS.  The original uMon code always had all
> of this stuff
> as part of its source code; however, some of it I pulled in from places that
> may not be
> appropriate for RTEMS; hence the error I put in there...
>
>>
>> I agree that we should transition now to the RTEMS tools that way
>> we'll be able to focus solely on any issues that can arise when using
>> the RTEMS tools rather than focusing on the issues with
>> arm-none-eabi-gcc/etc. which probably won't matter once we transition
>> over.
>
> Yep...
> As a quick check (to make sure things work afterwards); if you wanna try
> adding a ctype[]
> array (you can probably just pull in the one that is in umon1.19
> temporarily).

I think the table would require some modification because the macros
that access the ctype table are different.

In Umon 1.19 isspace() expands to:

        (ctypetbl[(int) c] & (_S | _C))

whereas in the standard-defined <ctype.h> it is:

        (__ctype_lookup(__c) & _S)

        where __ctype_looup expands to:

                ((__ctype_ptr__ + sizeof(""[__c]))[(int)(__c)]) which
is equivalent to (__ctype_ptr__ + 1)[(int)(__c)].

Despite this difference, I will look into getting this ctype table
working as a temporary solution for now before transitioning to the
RTEMS tools.

> Then, assuming that fixes things, transition to the RTEMS tools, remove all
> the homegrown
> ctype stuff and then we need to figure out how to get it to build.
> I'll join you in this hunt tonight.
> Good work!!!
>

Thank you for the encouragement, and thank you for taking the time in
assisting me!

>>
>> On Tue, Jun 23, 2015 at 4:00 AM, Ed Sutter <edsutterjr at gmail.com> wrote:
>>>
>>> On 6/22/2015 9:54 AM, Ed Sutter wrote:
>>>>
>>>> isspace() seems to be pulled in just fine from
>>>> /usr/arm-none-eabi/include, because removing <ctype.h> from strtol.c
>>>> results in an undefined reference to isspace().
>>>
>>> Jarielle,
>>> The ctype.h file usually just includes the macros that depend on
>>> some ctype-ish array.  So, you're right that the header file is
>>> correctly pulling in the macros; but that's not the end of it.
>>> I think the problem (aside from the fact that we need to get on
>>> the RTEMS compiler) is that this array (apparently called or
>>> pointed to by "__ctype_ptr__") does not exist in the build;
>>> hence my incorrect attempt to cure the problem by declaring
>>> __ctype_ptr___ in docmd.c
>>>
>>> So, I suggest getting on the RTEMS compiler, removing those __ctype_ptr__
>>> declarations at the top of docmd.c and building again.  Figure out why
>>> the ctype array is not being pulled in by a basic library and my hunch is
>>> you'll be good-to-go with this problem.
>>> 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
>
>
>
> --
> Ed Sutter
> Alcatel-Lucent Technologies -- Bell Laboratories
> Phone: 908-582-2351
> Email: ed.sutter at alcatel-lucent.com
>
> _______________________________________________
> umon-devel mailing list
> umon-devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/umon-devel