> I assume that you mean "readelf -D -r w" here, as you are looking for
dynamic relocs ?
...
000096e4 00000b14 R_ARM_COPY 000096e4 debug_f
found.
> What happens when you run the compiled w.c test program ? Is there a
seg-fault for
> accessing memory at address 0 ?
Yes.
I switched to uclibc.
---- ---- ---- libw.c
int debug_f = 1;
---- ---- ----
> /opt/arm-epson_uclibc2/bin/arm-none-linux-uclibcgnueabi-gcc
-march=armv7-a -shared -fPIC -o libw.so libw.c
> LD_PRELOAD=./libw.so ./w
Segmentation fault
> gdb w
(gdb) set environment LD_PRELOAD=./libw.so
(gdb) b main
Breakpoint 1 at 0x10490
(gdb) run
Starting program: /opt/w
Breakpoint 1, 0x00010490 in main ()
(gdb) info proc map
process 414
Mapped address spaces:
Start Addr End Addr Size Offset objfile
0x10000 0x11000 0x1000 0x0 /opt/w
0x20000 0x21000 0x1000 0x0 /opt/w
0x4007b000 0x4007c000 0x1000 0x0
0x40094000 0x40095000 0x1000 0x0
0x400de000 0x400e5000 0x7000 0x0 /lib/ld-uClibc-1.0.12.so
0x400f4000 0x400f5000 0x1000 0x6000 /lib/ld-uClibc-1.0.12.so
0x400f5000 0x400f6000 0x1000 0x7000 /lib/ld-uClibc-1.0.12.so
0x400f6000 0x401b6000 0xc0000 0x0 /lib/libuClibc-1.0.12.so
0x401b6000 0x401c5000 0xf000 0x0
0x401c5000 0x401c6000 0x1000 0xbf000 /lib/libuClibc-1.0.12.so
0x401c6000 0x401c7000 0x1000 0xc0000 /lib/libuClibc-1.0.12.so
0x401c7000 0x401cb000 0x4000 0x0
0x40227000 0x40228000 0x1000 0x0 /opt/libw.so
0x40228000 0x40237000 0xf000 0x0
0x40237000 0x40238000 0x1000 0x0 /opt/libw.so
0xbefa8000 0xbefc9000 0x21000 0x0 [stack]
0xffff0000 0xffff1000 0x1000 0x0 [vectors]
(gdb) info shared
>From To Syms Read Shared Object Library
0x400dee10 0x400e4348 Yes (*) /lib/ld-uClibc.so.0
0x402273cc 0x4022759c Yes ./libw.so
0x40100090 0x40180728 Yes (*) /lib/libc.so.1
(*): Shared library is missing debugging information.
(gdb) disassemble main
Dump of assembler code for function main:
0x0001047c <+0>: push {r11, lr}
0x00010480 <+4>: add r11, sp, #4
0x00010484 <+8>: sub sp, sp, #8
0x00010488 <+12>: str r0, [r11, #-8]
0x0001048c <+16>: str r1, [r11, #-12]
=> 0x00010490 <+20>: movw r3, #0 <- debug_f
0x00010494 <+24>: movt r3, #0 <- debug_f
0x00010498 <+28>: ldr r3, [r3]
0x0001049c <+32>: mov r1, r3
0x000104a0 <+36>: movw r0, #1228 ; 0x4cc
0x000104a4 <+40>: movt r0, #1
0x000104a8 <+44>: bl 0x102fc <printf@plt>
0x000104ac <+48>: mov r3, #0
0x000104b0 <+52>: mov r0, r3
0x000104b4 <+56>: sub sp, r11, #4
0x000104b8 <+60>: pop {r11, pc}
End of assembler dump.
(gdb)
Looking at the assembly code, I think that movw, movt should be rewritten.
Are two instructions rewritten with one R_ARM_COPY?
But R_ARM_MOVW_ABS_NC/R_ARM_MOVT_ABS processing is not in glibc
<sysdeps/arm/dl-machine.h> and uclibc <ldso/ldso/arm/elfinterp.c>.
Where is wrong?
In Ubuntu 16.10 (amd64)
> lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.10
Release: 16.10
Codename: yakkety
> gcc --version
gcc (Ubuntu 6.2.0-5ubuntu12) 6.2.0 20161005
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> ld --version
GNU ld (GNU Binutils for Ubuntu) 2.27
Copyright (C) 2016 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later
version.
This program has absolutely no warranty.
> gcc -o w w.c
> gcc -shared -fPIC -o libw.so libw.c
> LD_PRELOAD=./libw.so ./w
debug 1
As expected.
Movement is different between ARM and X86(amd64).
--------
Katsuya TANAKA.
_______________________________________________
bug-binutils mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-binutils
