#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:2 Changed on Jan 21, 2019 at 6:17:19 AM 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 Jan 29, 2019 at 8:04:26 AM by Sebastian Huber

Resolution: wontfix
Status: newclosed
Note: See TracTickets for help on using tickets.