Re: relocation information disappears
> I assume that you mean "readelf -D -r w" here, as you are looking for
dynamic relocs ?
...
96e4 0b14 R_ARM_COPY96e4 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
0x10x11000 0x10000x0 /opt/w
0x20x21000 0x10000x0 /opt/w
0x4007b000 0x4007c000 0x10000x0
0x40094000 0x40095000 0x10000x0
0x400de000 0x400e5000 0x70000x0 /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 0x401b60000xc0x0 /lib/libuClibc-1.0.12.so
0x401b6000 0x401c5000 0xf0000x0
0x401c5000 0x401c6000 0x10000xbf000 /lib/libuClibc-1.0.12.so
0x401c6000 0x401c7000 0x10000xc /lib/libuClibc-1.0.12.so
0x401c7000 0x401cb000 0x40000x0
0x40227000 0x40228000 0x10000x0 /opt/libw.so
0x40228000 0x40237000 0xf0000x0
0x40237000 0x40238000 0x10000x0 /opt/libw.so
0xbefa8000 0xbefc90000x210000x0 [stack]
0x 0x1000 0x10000x0 [vectors]
(gdb) info shared
>FromTo 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>:movwr3, #0 <- debug_f
0x00010494 <+24>:movtr3, #0 <- debug_f
0x00010498 <+28>:ldr r3, [r3]
0x0001049c <+32>:mov r1, r3
0x000104a0 <+36>:movwr0, #1228 ; 0x4cc
0x000104a4 <+40>:movtr0, #1
0x000104a8 <+44>:bl 0x102fc
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
and uclibc .
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
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
Re: relocation information disappears
On 04/06/2017 04:20 AM, Katsuya TANAKA wrote: # ~/x-tools/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-gcc -march=armv7-a -o w w.c ~/x-tools/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-readelf -r w There is no "debug_f" symbol. Why not? The value of a weak symbol is evaluated at static link time. If a symbol is found, then that symbol address is used. If a symbol is not found, then the address is set to zero. In this testcase, there is no debug_f symbol, so the address is forced to zero at link time, and hence no relocs are necessary. # ~/x-tools/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-gcc -march=armv7-a -o w2 w2.c There is a debug_info symbol. Variable is not good. In this case, debug_info is a function call, and function calls always go through the PLT, so there will be a PLT reloc for the function, even though we know the address is zero at link time. The address check however gets forced to zero, and has no relocs, because none is necessary. Note that weak symbols are not very useful with shared libraries. They are primarily intended for use with static linking. If you are trying to do something with a shared library, then don't use weak. Put a default definition of the symbol in the shared library, and then if you want to override it in the main program, just put a local definition in one of the source files linked into the main program. Jim ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
Re: relocation information disappears
Hi Katsuya, > # ~/x-tools/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-readelf > -r w I assume that you mean "readelf -D -r w" here, as you are looking for dynamic relocs ? > Relocation section '.rel.dyn' at offset 0x270 contains 1 entries: > Offset InfoTypeSym.Value Sym. Name > 0002101c 0315 R_ARM_GLOB_DAT __gmon_start__ > > There is no "debug_f" symbol. > Why not? I cannot reproduce this. As in, when I compile your test file there is a reference to the debug_f symbol in the dynamic relocations. I am using a different version of the compiler (7.0.1) and the binutils (2.28.51) however, so that might explain it. What happens when you run the compiled w.c test program ? Is there a seg-fault for accessing memory at address 0 ? Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
relocation information disappears
w.c
#include
extern int debug_f __attribute__ ((weak));
int main(int, char *[]);
int main(int argc, char *argv[])
{
printf("flag %d", debug_f);
}
w.c
# ~/x-tools/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-gcc
-march=armv7-a -o w w.c
# ~/x-tools/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-readelf
-r w
Relocation section '.rel.dyn' at offset 0x270 contains 1 entries:
Offset InfoTypeSym.Value Sym. Name
0002101c 0315 R_ARM_GLOB_DAT __gmon_start__
Relocation section '.rel.plt' at offset 0x278 contains 4 entries:
Offset InfoTypeSym.Value Sym. Name
0002100c 0116 R_ARM_JUMP_SLOT printf@GLIBC_2.4
00021010 0216 R_ARM_JUMP_SLOT __libc_start_main@GLIBC_2.4
00021014 0316 R_ARM_JUMP_SLOT __gmon_start__
00021018 0416 R_ARM_JUMP_SLOT abort@GLIBC_2.4
There is no "debug_f" symbol.
Why not?
# ~/x-tools/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-gcc
-march=armv7-a -c w.c
# ~/x-tools/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-readelf
-r w.o
Relocation section '.rel.text' at offset 0x1dc contains 5 entries:
Offset InfoTypeSym.Value Sym. Name
0014 0d2b R_ARM_MOVW_ABS_NC debug_f
0018 0d2c R_ARM_MOVT_ABS debug_f
0024 072b R_ARM_MOVW_ABS_NC .LC0
0028 072c R_ARM_MOVT_ABS .LC0
002c 0e1c R_ARM_CALL printf
There is a "debug_f" symbol in object file.
w2.c
extern void debug_info(void) __attribute__ ((weak));
int main(int, char *[]);
int main(int argc, char *argv[])
{
if (debug_info) {
debug_info();
}
}
# ~/x-tools/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-gcc
-march=armv7-a -o w2 w2.c
# ~/x-tools/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-readelf
-r w2
Relocation section '.rel.dyn' at offset 0x274 contains 1 entries:
Offset InfoTypeSym.Value Sym. Name
0002101c 0315 R_ARM_GLOB_DAT __gmon_start__
Relocation section '.rel.plt' at offset 0x27c contains 4 entries:
Offset InfoTypeSym.Value Sym. Name
0002100c 0116 R_ARM_JUMP_SLOT debug_info
00021010 0216 R_ARM_JUMP_SLOT __libc_start_main@GLIBC_2.4
00021014 0316 R_ARM_JUMP_SLOT __gmon_start__
00021018 0416 R_ARM_JUMP_SLOT abort@GLIBC_2.4
There is a debug_info symbol.
Variable is not good.
tool verison is
# ~/x-tools/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=/home/tanaka/x-tools/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/home/tanaka/x-tools/arm-unknown-linux-gnueabi/libexec/gcc/arm-unknown-linux-gnueabi/6.3.0/lto-wrapper
Target: arm-unknown-linux-gnueabi
Configured with: /ftp/src/tools/.build/src/gcc-6.3.0/configure
--build=x86_64-build_pc-linux-gnu
--host=x86_64-build_pc-linux-gnu --target=arm-unknown-linux-gnueabi
--prefix=/home/tanaka/x-tools/arm-unknown-linux-gnueabi
--with-sysroot=/home/tanaka/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sysroot
--enable-languages=c
--with-pkgversion='crosstool-NG ' --enable-__cxa_atexit --enable-libmudflap
--enable-libgomp --enable-libssp
--disable-libquadmath --disable-libquadmath-support --disable-libsanitizer
--disable-libmpx
--with-gmp=/ftp/src/tools/.build/arm-unknown-linux-gnueabi/buildtools
--with-mpfr=/ftp/src/tools/.build/arm-unknown-linux-gnueabi/buildtools
--with-mpc=/ftp/src/tools/.build/arm-unknown-linux-gnueabi/buildtools
--with-isl=/ftp/src/tools/.build/arm-unknown-linux-gnueabi/buildtools
--enable-lto
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
--enable-threads=posix --enable-target-optspace --disable-plugin
--disable-nls
--enable-tls --disable-multilib
--with-local-prefix=/home/tanaka/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sysroot
--enable-long-long
Thread model: posix
gcc version 6.3.0 (crosstool-NG )
# ~/x-tools/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-ld -v
GNU ld (crosstool-NG ) 2.28
Katsuya TANAKA.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
