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

Tue Jun 23 14:44:22 UTC 2015

That is, I'll get started :-)

On Tue, Jun 23, 2015 at 7:42 AM, Jarielle Catbagan
<jcatbagan93 at gmail.com> wrote:
> 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
>>