[Bug binutils/16177] R_ARM_COPY reloc generated for reference in writable section

https://sourceware.org/bugzilla/show_bug.cgi?id=16177 Nick Bowler changed: What|Removed |Added CC||nbowler at draconx dot ca -- You are

[Bug gold/23856] Executables linked with gold against musl segfault at startup

https://sourceware.org/bugzilla/show_bug.cgi?id=23856 Nick Bowler changed: What|Removed |Added CC||nbowler at draconx dot ca -- You are

[Bug binutils/25355] nm reports a variable as "T" with -flto and -fno-common

https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #10 from Nick Bowler --- (In reply to Martin Liška from comment #9) > > Amusingly, "nm" is also busted on objects using this trick with -flto, > > showing a_ as an undefined symbol which is not the case. But that > > shouldn't

[Bug binutils/25355] nm reports a variable as "T" with -flto and -fno-common

https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #7 from Nick Bowler --- (In reply to Nick Clifton from comment #6) > (In reply to Nick Bowler from comment #5) > > > - The configure test actually links together the results for two > >features (global_symbol_pipe and global_

[Bug binutils/25355] nm reports a variable as "T" with -flto and -fno-common

https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #5 from Nick Bowler --- (In reply to Martin Liška from comment #4) > That's true, but it's only related to .o files (LTO bytecode). If you link > a final executable (or a shared library), you'll get proper type information: > > $

[Bug binutils/25355] nm reports a variable as "T" with -flto and -fno-common

https://sourceware.org/bugzilla/show_bug.cgi?id=25355 Nick Bowler changed: What|Removed |Added CC||nbowler at draconx dot ca --- Comment

[Bug ld/24289] New: MEMORY regions can no longer use LENGTH and ORIGIN (2.32 regression).

: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: nbowler at draconx dot ca Target Milestone: --- Created attachment 11659 --> https://sourceware.org/bugzilla/attachment.cgi?id=11659&action=edit Possible fix C

[Bug ld/24289] MEMORY regions can no longer use LENGTH and ORIGIN (2.32 regression).

https://sourceware.org/bugzilla/show_bug.cgi?id=24289 --- Comment #1 from Nick Bowler --- (In reply to Nick Bowler from comment #0) > This works as exepcted with ld-2.31: the codestart symbol gets the value 0 > and the datastart symbol gets the value 16777216. However, 2.32 appears to > reject t

[Bug ld/23648] Symbols based on MEMORY regions confuse --gc-sections.

https://sourceware.org/bugzilla/show_bug.cgi?id=23648 --- Comment #1 from Nick Bowler --- Created attachment 11243 --> https://sourceware.org/bugzilla/attachment.cgi?id=11243&action=edit Possible patch Simply moving the call to lang_do_memory_regions earlier in lang_process is sufficient to ma

[Bug ld/23648] New: Symbols based on MEMORY regions confuse --gc-sections.

Component: ld Assignee: unassigned at sourceware dot org Reporter: nbowler at draconx dot ca Target Milestone: --- It seems that ld's --gc-sections feature can get confused by the MEMORY command. It is possible to define symbols that depend on the memory regio