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

Jarielle Catbagan jcatbagan93 at gmail.com
Tue Jun 23 14:40:41 UTC 2015


Dr. Joel,


On Mon, Jun 22, 2015 at 9:31 AM, Joel Sherrill
<joel.sherrill at oarcorp.com> wrote:
>
>
> On 6/22/2015 9:59 AM, Jarielle Catbagan wrote:
>>
>> 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.
>
>
> I wonder..... does the arm-none-eabi toolset you downloaded actually have
> the right multilib for this board.  Can you provide a list of the full
> paths of all the libc.a files provided by this toolset?

After running "arm-none-eabi-gcc -print-multi-lib", the output I got is

.;
thumb;@mthumb
fpu;@mfloat-abi=hard
armv6-m;@mthumb at march=armv6s-m
armv7-m;@mthumb at march=armv7-m
armv7e-m;@mthumb at march=armv7e-m
armv7-ar/thumb;@mthumb at march=armv7
armv7e-m/softfp;@mthumb at march=armv7e-m at mfloat-abi=softfp at mfpu=fpv4-sp-d16
armv7e-m/fpu;@mthumb at march=armv7e-m at mfloat-abi=hard at mfpu=fpv4-sp-d16
armv7-ar/thumb/softfp;@mthumb at march=armv7 at mfloat-abi=softfp at mfpu=vfpv3-d16
armv7-ar/thumb/fpu;@mthumb at march=armv7 at mfloat-abi=hard at mfpu=vfpv3-d16


Seeing the paths of all libc.a files provided by arm-none-eabi-gcc
with "arm-none-eabi-gcc -print-file-name=libc.a", the output I got is

/usr/lib/gcc/arm-none-eabi/4.9.2/../../../../arm-none-eabi/lib/libc.a


>
> And is a "-r" or "-Wl,-r" anywhere in the verbose build log when you get
> the multiply defined error? Somewhere in the build process, a partial link
> could be pulling in symbols from libc.a into an intermediate object file.
> If this happened, a multiply defined symbol is a typical outcome.

The linker is invoked at the end of the build process and is as follows:

/usr/bin/arm-none-eabi-ld -nostartfiles -o
build_BEAGLEBONEBLACK/boot.elf -T BEAGLEBONEBLACK_boot.ld -e coldstart
 vectors_arm.o cpuio.o etherdev.o ldatags.o except_arm.o misc_arm.o
strace_arm.o arp.o cast.o cache.o chario.o cmdtbl.o docmd.o dhcp_00.o
dhcpboot.o dns.o edit.o env.o ethernet.o flash.o gdb.o icmp.o if.o
ledit_vt100.o monprof.o fbi.o font.o mprintf.o memcmds.o malloc.o
moncom.o memtrace.o misccmds.o misc.o nand.o password.o redirect.o
reg_cache.o sbrk.o sd.o start.o struct.o symtbl.o syslog.o tcpstuff.o
tfs.o tfsapi.o tfsclean1.o tfscli.o tfsloader.o tfslog.o tftp.o
timestuff.o tsi.o xmodem.o s29gl512n_16x1.o smsc911x.o uart16550.o
fb_draw.o monbuilt.o libz.a \
libg.a -L /usr/lib/gcc/arm-none-eabi/4.9.2
`/usr/bin/arm-none-eabi-gcc --print-libgcc-file-name`
/usr/bin/arm-none-eabi-objcopy -O binary
build_BEAGLEBONEBLACK/boot.elf build_BEAGLEBONEBLACK/boot.bin
/usr/bin/arm-none-eabi-nm --numeric-sort
build_BEAGLEBONEBLACK/boot.elf > build_BEAGLEBONEBLACK/boot.gsym

>
>>>> With umon having the ability to integrate with RTEMS the need to match
>>>> the ABI is important.
>
>
> Yep.
>
> For the purposes of uMon, I wouldn't expect anything to be used that is OS
> specific anyway. Worst case, uMon itself could provide the equivalent of the
> libgloss glue.
>
>
>>>>>>> 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
>>
>> _______________________________________________
>> umon-devel mailing list
>> umon-devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/umon-devel
>>
>
> --
> Joel Sherrill, Ph.D.             Director of Research & Development
> joel.sherrill at OARcorp.com        On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> Support Available                (256) 722-9985


More information about the umon-devel mailing list