[Bug binutils/18288] New: linker -s output suboptimal
https://sourceware.org/bugzilla/show_bug.cgi?id=18288 Bug ID: 18288 Summary: linker -s output suboptimal Product: binutils Version: 2.25 Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: dilyan.palauzov at aegee dot org I have binutils 2.25/gold 1.11. I compile a program with `ld.gold -s', do `readelf --all` on in. Then I `strip' the program and do `readelf --all' on the results. Then I compare the outputs of the two `readelf' invocations. I expected these to be identical. However, they are not, here the diff: --- r-gold-stripped2015-04-21 12:00:29.206029031 + +++ r-gold-orig2015-04-21 12:00:22.532028940 + @@ -10,7 +10,7 @@ Version: 0x1 Entry point address: 0x40c084 Start of program headers: 64 (bytes into file) - Start of section headers: 469920 (bytes into file) + Start of section headers: 469928 (bytes into file) Flags: 0x0 Size of this header: 64 (bytes) Size of program headers: 56 (bytes) The sizes also differ: 471648 - stripped 471656 - unstripped Then I did the same procedure with the ld.bfd - linker. The numbers coincide with ld.gold. To my understanding the linker option -s is supposed to make running `strip' after compiling superfluous. But it doesn't, as strip reduces the file size further, without doing anything else. Hence I consider this as bug (in both ld and gold). -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/18289] New: Support copy relocation in PIE
https://sourceware.org/bugzilla/show_bug.cgi?id=18289 Bug ID: 18289 Summary: Support copy relocation in PIE Product: binutils Version: 2.26 (HEAD) Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: hjl.tools at gmail dot com Target: i386-elf This main: call__x86.get_pc_thunk.ax addl$_GLOBAL_OFFSET_TABLE_, %eax movl$4, optopt@GOTOFF(%eax) xorl%eax, %eax ret should work with copy relocation in PIE. But we get [hjl@gnu-tools-1 copyreloc]$ gcc -pie -m32 x.s /usr/local/bin/ld: /tmp/ccCk6nT6.o: relocation R_386_GOTOFF against undefined symbol `optopt@@GLIBC_2.0' can not be used when making a shared object /usr/local/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status [hjl@gnu-tools-1 copyreloc]$ We need to implement x86-64 commit 631d040f80d99b7b993abd77c9d064fa8bccd711 on i386 and handle cases similar to PRs 17689/17827/17847 if needed. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/18288] linker -s output suboptimal
https://sourceware.org/bugzilla/show_bug.cgi?id=18288 Jevin Sweval changed: What|Removed |Added CC||jsweval at arxan dot com -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/18289] Support copy relocation in PIE
https://sourceware.org/bugzilla/show_bug.cgi?id=18289 Jevin Sweval changed: What|Removed |Added CC||jsweval at arxan dot com -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/18209] objdump -h is not very helpful printing decompressed section names
https://sourceware.org/bugzilla/show_bug.cgi?id=18209 --- Comment #7 from dje at google dot com --- (In reply to Nick Clifton from comment #3) > Hi Doug, > > It is an artifact of the BFD library that objdump -h shows the > uncompressed versions of compressed debug sections. It could be argues that > this is in fact more helpful to the user, since it gives an idea of the > total amount of debugging information in the executable. > > So I have uploaded a proposed patch which extends the -j option of objdump > so that it will accept .debug. as an alias for .zdebug.. It also > updates the documentation of objdump to describe the behaviour of the -h > option in more detail. Please could you try out this patch and let me know > what you think. > > Cheers > Nick fwiw, I'd prefer it if the tools didn't try to be clever like this by default. Such things can and do lead to confusion. Feel free to add an option to do this kind of thing, but if you're asking for my opinion :-), I'd rather tools like objdump be literal by default, not clever. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
