[Bug binutils/19446] BFD linker discards section without alloc section attribute under certain conditions
https://sourceware.org/bugzilla/show_bug.cgi?id=19446 --- Comment #11 from David Li --- No problem with this as long as ld does not throw away note sections. thanks, -- 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/19446] BFD linker discards section without alloc section attribute under certain conditions
https://sourceware.org/bugzilla/show_bug.cgi?id=19446
--- Comment #10 from Nick Clifton ---
Hi Xinliangli,
> However I do think ld's behavior is
> not correct here. Should linker first decide if some sections are 'root'
> sections that should not be throw away and then decide if other sections
> should
> be GCed? Here linker first prunes the references and then is forced to discard
> section not because it should do so, but to make the link succeed.
Yes, but... the linker has not been told that the UNREF section is a root
section. If the test had used a linker script that specified that the UNREF
section should be kept[1] then the linker would have acted differently. It
would keep the UNREF section and g0 variable and everything would have worked
as expected.
Since however the UNREF section is an orphan section, the linker has more
latitude in what it can do. The LD linker decides that since the section has
relocations against it, and since these relocations refers to symbols which are
otherwise unused, then it makes sense to discard the section. You disagree
with this decision. I don't. But since there are several
available workarounds, and, as far as I know, it is not breaking real programs,
I do not plan to make any changes to the linker.
Cheers
Nick
[1] ie:
UNREF : { KEEP (*(UNREF)) }
--
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
Re: [Bug binutils/19446] BFD linker discards section without alloc section attribute under certain conditions
Hi Xinliangli,
However I do think ld's behavior is
not correct here. Should linker first decide if some sections are 'root'
sections that should not be throw away and then decide if other sections should
be GCed? Here linker first prunes the references and then is forced to discard
section not because it should do so, but to make the link succeed.
Yes, but... the linker has not been told that the UNREF section is a root
section. If the test had used a linker script that specified that the UNREF
section should be kept[1] then the linker would have acted differently. It
would keep the UNREF section and g0 variable and everything would have worked
as expected.
Since however the UNREF section is an orphan section, the linker has more latitude in what it can do. The LD linker decides that since the section has relocations against it, and since these relocations refers to symbols which are otherwise unused, then it makes sense to discard the section. You disagree with this decision. I don't. But since there are several
available workarounds, and, as far as I know, it is not breaking real programs, I do not plan to make any changes to the linker.
Cheers
Nick
[1] ie:
UNREF : { KEEP (*(UNREF)) }
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10773] Malformed archive created when adding several files at once
https://sourceware.org/bugzilla/show_bug.cgi?id=10773 Nick Clifton changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME |--- --- Comment #12 from Nick Clifton --- Hi Jason, > I just tried with binutils-2.25.1 from RPM binutils-2.25.1-9.fc24.x86_64 and > the same problem occurred. In which case, please could you upload a testcase for us to try out ? Cheers Nick -- 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/19435] objdump receives SIGABRT when disassembling Mach O binary on OS X
https://sourceware.org/bugzilla/show_bug.cgi?id=19435
--- Comment #6 from Nick Clifton ---
I missed a bit...
diff --git a/bfd/mach-o.c b/bfd/mach-o.c
index 72454f9..a712ff6 100644
--- a/bfd/mach-o.c
+++ b/bfd/mach-o.c
@@ -5798,14 +5798,16 @@ bfd_mach_o_close_and_cleanup (bfd *abfd)
if (mdata->dsym_bfd != NULL)
{
bfd *fat_bfd = mdata->dsym_bfd->my_archive;
+#if 0
char *dsym_filename = (char *)(fat_bfd
? fat_bfd->filename
: mdata->dsym_bfd->filename);
+#endif
bfd_close (mdata->dsym_bfd);
mdata->dsym_bfd = NULL;
if (fat_bfd)
bfd_close (fat_bfd);
- free (dsym_filename);
+ /*free (dsym_filename);*/
}
}
Cheers
Nick
--
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
binutils 2.25.1 creates big sparse files
When building small libs/exec on ppc32 I usally get sparse files like so: ls -lsh | sort -n 64K -rwxr-xr-x 1 jocke users 68K Jan 22 11:20 mgmt_alarmd* 64K -rwxr-xr-x 1 jocke users 67K Jan 22 11:20 ne_memd* 56K -rwxr-xr-x 1 jocke users 67K Jan 22 11:20 cp_dummy* 56K -rwxr-xr-x 1 jocke users 66K Jan 22 11:20 mgmt_pmd* 48K -rwxr-xr-x 1 jocke users 69K Jan 22 11:20 ntpdate* 48K -rwxr-xr-x 1 jocke users 67K Jan 22 11:20 ne_rc* 48K -rwxr-xr-x 1 jocke users 66K Jan 22 11:20 relayd* 48K -rwxr-xr-x 1 jocke users 66K Jan 22 11:20 ntptimeset* 44K -rwxr-xr-x 1 jocke users 67K Jan 22 11:20 mgmt_backup_tftpd* ... 16K -rwxr-xr-x 1 jocke users 66K Jan 22 11:20 tosv_test* 16K -rwxr-xr-x 1 jocke users 66K Jan 22 11:20 tosv_supv* 16K -rwxr-xr-x 1 jocke users 66K Jan 22 11:20 ne_rc_supv* 16K -rwxr-xr-x 1 jocke users 66K Jan 22 11:20 ne_rc_memeater* 16K -rwxr-xr-x 1 jocke users 66K Jan 22 11:20 ne_rc_load* 16K -rwxr-xr-x 1 jocke users 66K Jan 22 11:20 ne_mem_ram_test* 16K -rwxr-xr-x 1 jocke users 66K Jan 22 11:20 alib_test_psup* 16K -rwxr-xr-x 1 jocke users 16K Jan 22 11:15 convert_backup* 15M -rwxr-xr-x 1 jocke users 15M Jan 22 11:20 emxp2_hw_bl* 12K -rwxr-xr-x 1 jocke users 9.0K Jan 22 11:18 swu_prepost_script.sh* 12K -rwxr-xr-x 1 jocke users 66K Jan 22 11:20 tickadj* 12K -rwxr-xr-x 1 jocke users 66K Jan 22 11:20 tclsh8.4* 12K -rwxr-xr-x 1 jocke users 66K Jan 22 11:20 genkeys* this is binutils 2.25.1 doing in this commit: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=9059a151e33f2f9b7b989a22e63d711a2c8a3 35b;hp=6e7e69e72dc1c53c8d5a8794c845026c48ff343a (Set ppc COMMONPAGESIZE to 64k) This is a huge problem as these sparse file are packaged into a tar file and when unpacked they lose the sparse attribute and will expand to 66K on disk and fill up the my small FS. I guess many packaging tools uses tar so I expect I other people will run into this to. I do wonder why it now became necessary to increase page size in binutils? ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
