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

[Jarielle Catbagan]

On Mon, Jun 22, 2015 at 6:54 AM, Ed Sutter <ed.sutter at alcatel-lucent.com> wrote:
> On 6/22/2015 8:28 AM, Chris Johns wrote:
>>
>> On 22/06/2015 2:16 pm, Jarielle Catbagan wrote:
>>>
>>> On Sun, Jun 21, 2015 at 4:47 PM, Chris Johns <chrisj at rtems.org> wrote:
>>>>
>>>> On 22/06/2015 2:27 am, Jarielle Catbagan wrote:
>>>>>
>>>>> I was testing the "help", "dm" and "pm" commands on the Umon command
>>>>> line and they resulted in what appears to cause the program to hang.
>>>>> I captured the result and it can be found here
>>>>>
>>>>> https://drive.google.com/file/d/0B_44Dkqbmn75TjQwZjJaczNJYk0/view?usp=sharing.
>>>>>
>>>>> After doing some debugging, I was able to pinpoint the location that
>>>>> results in a halt in program execution.  It hangs when isspace() is
>>>>> executed in strtol() in strtol.c.
>>>>>
>>>> Where do the libc functions come from ? What is the linker command line
>>>> ?
>>>>
>>> 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().
>>
>> My concern is the multilibs and what is needed by umon and what is
>> needed by RTEMS. For example on the Zynq I build the Xilinx bootloader
>> code for ARM in thumb mode while Xilinx do not (I know because I needed
>> to fix it). I actually use the same flags I use for RTEMS.
>>
>> With umon having the ability to integrate with RTEMS the need to match
>> the ABI is important.
>>
>>>>> Whenever Umon is built, there are two important images built.
>>>>> boot.bin and boot.elf.  boot.bin is a raw image and is the image that
>>>>> is booted on the BBB.  I wanted to see how the image was assembled,
>>>>> and so I ran "arm-none-eabi-objdump -S boot.elf".  I am focusing on
>>>>
>>>>                  ^^^^^^^^^^^^^
>>>>
>>>> What tool set is being used ?
>>>
>>>
>>> I am using arm-none-eabi-gcc 4.9.2 and binutils 2.25.0.
>>>
>> Where did you get this compiler from ? Who built it ?
>>

I obtained the compiler from the Arch Linux repositories via "pacman".

>> How do we track what is needed by users ? I for one cannot contribute
>> because I do not have this compiler.
>>

I agree, having the same toolset among users and contributors will be
better in the long run.

>> Why not use the RTEMS compiler ?
>>

I chose not to modify the existing build process of Umon, (i,e, using
arm-none-eabi-gcc, etc.), for now.  I am certainly open to the idea of
transitioning to the RTEMS compiler now, especially if it means that
complexities would be avoided later down the road.

>> It may mean we need to tell gcc not to use stand includes or libs which
>> means we need to include the bits of libc used by umon in the umon
>> package but I feel this is ok.
>>

I can certainly implement the bits of libc.  It was just that when I
originally cloned the Umon repo from the RTEMS git repos,
strtol.c/strtoul.c included the standard-defined ctype.h and I wanted
to work with what was there.  The previous Umon sources had a
locally-defined ctype.h where isspace() was defined.  This
locally-defined ctype.h was used instead of the standard defined
ctype.h.  If I implement isspace() in a locally defined ctype.h, the
data exception would be immediately removed.  I just wanted to see if
I could get it to work if the standard-defined ctype.h was used, but I
am puzzled as to how the assembly code is generated for
while(isspace(c)) in strtol.c/strtoul.c as it seems to be accessing
invalid memory.

>> Chris
>> _______________________________________________
>> umon-devel mailing list
>> umon-devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/umon-devel
>
> Yea this is a good point.
> I have not been using the RTEMS compiler thus far.  I just used the
> arm cross compiler that can be directly installed with apt-get on
> ubuntu 14.04.  I don't think it will solve any of the immediate problems,
> nevertheless, we should transition to the same toolset.
>
>
>
>
> --
> 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