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

[Ed Sutter]

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).
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!!!
>
> 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