BBB/AM335x: isspace() results in data abort exception in strtol() in strtol.c and strtoul() in strtoul.c
ed.sutter at alcatel-lucent.com
Tue Jun 23 13:49:47 UTC 2015
On 6/23/2015 9:39 AM, Jarielle Catbagan wrote:
> 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
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
> 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
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
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
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.
> 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().
>> 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.
>> umon-devel mailing list
>> umon-devel at rtems.org
> umon-devel mailing list
> umon-devel at rtems.org
Alcatel-Lucent Technologies -- Bell Laboratories
Email: ed.sutter at alcatel-lucent.com
More information about the umon-devel