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

Tue Jun 23 14:42:37 UTC 2015

I totally agree with you.  We should just get right into using the
RTEMS toolset.

I'll let you know, if I encounter anything during the transition process.

On Tue, Jun 23, 2015 at 7:35 AM, Ed Sutter <ed.sutter at alcatel-lucent.com> wrote:
> On 6/23/2015 10:27 AM, Jarielle Catbagan wrote:
>>
>> 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.
>
>
> 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
> field.
> 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 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
>
>
>
> --
> Ed Sutter
> Alcatel-Lucent Technologies -- Bell Laboratories
> Phone: 908-582-2351
> Email: ed.sutter at alcatel-lucent.com
>