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

Ed Sutter ed.sutter at
Tue Jun 23 14:35:12 UTC 2015

On 6/23/2015 10:27 AM, Jarielle Catbagan wrote:
> On Tue, Jun 23, 2015 at 6:49 AM, Ed Sutter <ed.sutter at> 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.

I'm flip-flopping here myself... It may be more efficient to just get 
onto the RTEMS toolset
because if we're real lucky, the problem will just go away because 
appropriate libraries will
be pulled in.  Even if it doesn't at least we'll be playing in the same 
It's your call, it could be messy trying to shoehorn it in.
>> 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> 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
>>> _______________________________________________
>>> umon-devel mailing list
>>> umon-devel at
>> --
>> Ed Sutter
>> Alcatel-Lucent Technologies -- Bell Laboratories
>> Phone: 908-582-2351
>> Email: ed.sutter at
>> _______________________________________________
>> umon-devel mailing list
>> umon-devel at

Ed Sutter
Alcatel-Lucent Technologies -- Bell Laboratories
Phone: 908-582-2351
Email: ed.sutter at

More information about the umon-devel mailing list