https://sourceware.org/bugzilla/show_bug.cgi?id=19891
--- Comment #2 from dimitry ---
Hi,
This is the source file:
https://android.googlesource.com/platform/bionic/+/master/tests/libs/dlopen_testlib_ifunc.c
--
You are receiving this mail because:
You are on the CC list for the bug.
___
Severity: normal
Priority: P2
Component: gold
Assignee: ccoutant at gmail dot com
Reporter: dimitry at google dot com
CC: ian at airs dot com
Target Milestone: ---
Here readelf -r -W output for arm library:
Relocation section '.rel.dy
https://sourceware.org/bugzilla/show_bug.cgi?id=19163
--- Comment #2 from dimitry ---
by *reloc I meant mapped memory from elf file at Elf64_Rela::r_offset.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils
Priority: P2
Component: gold
Assignee: ccoutant at gmail dot com
Reporter: dimitry at google dot com
CC: ian at airs dot com
Target Milestone: ---
Android linker has a bug (affecting version L, L-MR1 and M) where it processes
R_AARCH64_ABS
https://sourceware.org/bugzilla/show_bug.cgi?id=18596
dimitry changed:
What|Removed |Added
CC||dimitry at google dot com
--
You are
https://sourceware.org/bugzilla/show_bug.cgi?id=17615
dimitry changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID
https://sourceware.org/bugzilla/show_bug.cgi?id=17615
--- Comment #12 from dimitry ---
and yes; there is no .bss section when I use ld directly.. so is this gcc bug
then?
--
You are receiving this mail because:
You are on the CC list for the bug.
___
https://sourceware.org/bugzilla/show_bug.cgi?id=17615
--- Comment #11 from dimitry ---
(In reply to H.J. Lu from comment #10)
> Use "ld --gc-sections -shared" directly. You will see there is no
> .bss section at all. The .bss section you see comes from other
> input files added by GCC driver.
https://sourceware.org/bugzilla/show_bug.cgi?id=17615
--- Comment #9 from dimitry ---
hi, I was looking at the .so file. I guess the part I do not understand is that
.bss section is there; and PT_LOADS seems to be in place; so as far as I
understand there is no reason for making st_shndx for hz_i
https://sourceware.org/bugzilla/show_bug.cgi?id=17615
--- Comment #4 from dimitry ---
attached tar.gz files contain object files as well as linked ip binary
(unstripped version is under LINKED/)
The symbol in question is __iproute2_user_hz_internal; It is referenced by
ipneigh.o and iproute.o
-
https://sourceware.org/bugzilla/show_bug.cgi?id=17615
--- Comment #3 from dimitry ---
Created attachment 7952
--> https://sourceware.org/bugzilla/attachment.cgi?id=7952&action=edit
ip-arm-intermediates
--
You are receiving this mail because:
You are on the CC list for the bug.
__
https://sourceware.org/bugzilla/show_bug.cgi?id=17615
--- Comment #2 from dimitry ---
Created attachment 7951
--> https://sourceware.org/bugzilla/attachment.cgi?id=7951&action=edit
ip-arm64-intermediates
--
You are receiving this mail because:
You are on the CC list for the bug.
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: dimitry at google dot com
when compiling iproute2 'ip' binary for arm64 ld.bfd produces following symbol
in .dynsym section
11: 4 OBJECT GLOBAL DEFAULT ABS
__iproute2_user_h
13 matches
Mail list logo