Opened on 01/21/19 at 00:41:14
Closed on 01/29/19 at 08:04:26
#3677 closed defect (wontfix)
ARM BSP contains ARM code in THUMB only build
Reported by: | Chris Johns | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | 5.1 |
Component: | tool/gcc | Version: | 5 |
Severity: | normal | Keywords: | |
Cc: | Blocked By: | ||
Blocking: |
Description
The xilinx_zynq_a9_qemu
BSP contains a memcpy
that is ARM mode code and not THUMB. This can be seen with hello.exe
and vlan01.exe
in the libbsd examples.
The script run with the command that follows shows there is a single ARM function in the executable. The python script is:
from __future__ import print_function import sys for line in sys.stdin: ls = line.split() if len(ls) == 8 and ls[0][-1] == ':' and ls[3] == 'FUNC': addr = int(ls[1], 16) if addr & 1 == 0: print(ls[7])
Command with output:
$ arm-rtems5-readelf -a `find . -name hello.exe` | python ./arm-thumb.py memcpy
The presence of this single function makes me wonder why and if something is wrong in the building of the memcpy
function.
Examination with rtems-exeinfo
shows the code is built by GNU AS from the file memcpy-armv7a.S
while other asm files are not generating ARM code. The section of the output from:
$ rtems-exeinfo -a `find . -name hello.exe`
is:
GNU AS 2.31.1: 14 objects | arm_exc_interrupt.S | armv4-exception-default.S | bpabi.S | bpabi.S | bsp-start-memcpy.S | cpu_asm.S | lib1funcs.S | lib1funcs.S | lib1funcs.S | memchr.S | memcpy-armv7a.S | start.S | strcmp-armv7.S | strlen-armv7.S
GNU LD is correctly managing the interworking and the code runs however is this behavior expected and understood?
Note, the existence of this code breaks libdl's loading of dhcpcd.c
as section .rel.text.dhcpcd_handle_hwaddr
contains a R_ARM_THM_JUMP24
relocation record which requires a veneer in large memory application as well as bl
to blx
support. This support could be added but I am not currently in favor of having this support for something that should not happen.
Change History (3)
comment:1 Changed on 01/21/19 at 00:44:30 by Chris Johns
comment:2 Changed on 01/21/19 at 06:17:19 by Sebastian Huber
The interworking support is mandatory in ARM EABI. The memcpy() code is from ARM, I guess they know what they are doing.
comment:3 Changed on 01/29/19 at 08:04:26 by Sebastian Huber
Resolution: | → wontfix |
---|---|
Status: | new → closed |
Hmmmm ....
https://github.com/RTEMS/sourceware-mirror-newlib-cygwin/blob/master/newlib/libc/machine/arm/memcpy-armv7a.S#L47