[RTEMS Project] #3677: ARM BSP contains ARM code in THUMB only build

[RTEMS trac]

#3677: ARM BSP contains ARM code in THUMB only build
--------------------------+--------------------
  Reporter:  Chris Johns  |      Owner:  (none)
      Type:  defect       |     Status:  new
  Priority:  normal       |  Milestone:  5.1
 Component:  tool/gcc     |    Version:  5
  Severity:  normal       |   Keywords:
Blocked By:               |   Blocking:
--------------------------+--------------------
 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.

--
Ticket URL: <http://devel.rtems.org/ticket/3677>
RTEMS Project <http://www.rtems.org/>
RTEMS Project