https://sourceware.org/bugzilla/show_bug.cgi?id=21448
--- Comment #9 from Michael Deutschmann ---
My system is a hobby on old computers, so my pagesize is 4k.
> OK, it's still true that the fix for pr20995 is necessary for security.
You keep saying this, but I don't see how it's a problem that
https://sourceware.org/bugzilla/show_bug.cgi?id=21448
--- Comment #7 from Michael Deutschmann ---
My example involves an ordinary, absolute executable, not a PIE.
And my point is that all the magic has to be in the linker, not GCC.
If there are no relocations inside the array (there are in the
https://sourceware.org/bugzilla/show_bug.cgi?id=21448
--- Comment #5 from Michael Deutschmann ---
> but the reason you see a .dynbss/.data.rel.ro copy of shared lib variables
> and copy relocs is code in the *executable*
But not because of anything special GCC does in the executable.
The trivi
https://sourceware.org/bugzilla/show_bug.cgi?id=21448
--- Comment #3 from Michael Deutschmann ---
GCC (6.3.0) doesn't seem to be doing anything magical in the .s files. It
looks like the behavior is triggered only by a ".size" directive on the shared
library side, and ".size" isn't documented to
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: michael at talosis dot ca
Target Milestone: ---
Binutils 2.28 links certain executables into much larger binaries compared to
the 2.27 linker with
https://sourceware.org/bugzilla/show_bug.cgi?id=17773
--- Comment #2 from Michael Deutschmann ---
Just the two-line assembler file:
.global _start
_start: hlt
suffices to demonstrate the behavior.
If this is assembled (with as directly, no options besides -o) and linked
(directly, just -s and
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: michael at talosis dot ca
When the "-s" option is used, the binutils 2.25 linker produces ELF executables
with a 4-byte gap between the last section and the section headers.
The 2
