[Bug binutils/3315] New: ld --gc-sections *.o produces big(ger than possible) executables
Basically, I compile an executable from same set of source files.
First I compile .c modules into .o with -ffunction-sections
-fdata-sections, and then I can do something a-la
"gcc -o executable -Wl,--gc-sections *.o"
or I can bundle almost all .o files into lib.a using ar and do
"gcc -o executable -Wl,--gc-sections main.o lib.a"
The second method gives much better results:
# size */busybox
textdata bss dec hex filename
14186 868 24 150783ae6 busybox.1.t/busybox
2682 304 243010 bc2 busybox.2.t/busybox
However, there is no reason to believe that all is good now.
I tent to fear than suboptimal link-time dead code elimination
is still happening, only on lesser scale (within each individual .o file
pulled from lib.a, not over whole set of .o files).
Extended explanation is at http://busybox.net/~vda/Kbuild_new_2006/
I will attach objdump -xsdr of both executables.
comparing those, I see:
* extra EH_FRAME section
* sections .hash, .dynstr, .dynsym, are much longer
Unstripped executables also available for comparison at the above URL.
One thing has been tracked down to this test case:
/* Compile:
** gcc -ffunction-sections -fdata-sections -c -o test.o test.c
** gcc -o test -Wl,--gc-sections test.o
**
** First call to notexist() is optimized away by linker because
** function eliminated() is, er, eliminated by section GC.
**
** But second call to notexist() is not optimized away,
** despite the fact that getpwnam_r() is not called from anywhere.
** Then linking fails because notexist() isn't exist.
**
** Renaming getpwnam_r to any other name "fixes" this! */
void notexist(void);
int main(void) { return 0; }
void eliminated(void) { notexist(); }
void getpwnam_r(void) { notexist(); } // HERE
Rest are not researched in depth.
--
Summary: ld --gc-sections *.o produces big(ger than possible)
executables
Product: binutils
Version: 2.17
Status: NEW
Severity: normal
Priority: P2
Component: binutils
AssignedTo: unassigned at sources dot redhat dot com
ReportedBy: vda dot linux at googlemail dot com
CC: bug-binutils at gnu dot org
GCC build triplet: i386-pc-linux-gnu
GCC host triplet: i386-pc-linux-gnu
GCC target triplet: i386-pc-linux-gnu
http://sourceware.org/bugzilla/show_bug.cgi?id=3315
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/3315] ld --gc-sections *.o produces big(ger than possible) executables
--- Additional Comments From vda dot linux at googlemail dot com 2006-10-06 15:48 --- Created an attachment (id=1354) --> (http://sourceware.org/bugzilla/attachment.cgi?id=1354&action=view) objdump of ld *.o result -- http://sourceware.org/bugzilla/show_bug.cgi?id=3315 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/3315] ld --gc-sections *.o produces big(ger than possible) executables
--- Additional Comments From vda dot linux at googlemail dot com 2006-10-06 15:49 --- Created an attachment (id=1355) --> (http://sourceware.org/bugzilla/attachment.cgi?id=1355&action=view) objdump of ld main.o lib.a result -- http://sourceware.org/bugzilla/show_bug.cgi?id=3315 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/4992] New: ld: --print-gc-sections + --verbose = mess
ld version 2.18 introduced --print-gc-sections, and it seems
to have problem coexisting with --verbose.
This is what I see in the build log when I redirect both stdout and stderr to a
file:
(arch/x86_64/lib/lib.a)rwlock.o
(arch/x86_64/lib/lib.a)thunk.o
(arch/x86_64/lib/lib.a)usercopy.o
attempt to openx86_64-pc-linux-gnu-ld: Removing unused section
'.bss.Version_132631' in file 'init/built-in.o'
x86_64-pc-linux-gnu-ld: Removing unused section '.text.bad_intr' in file
'arch/x86_64/kernel/built-in.o'
x86_64-pc-linux-gnu-ld: Removing unused section '.text.do_device_not_available'
in file 'arch/x86_64/kernel/built-in.o'
x86_64-pc-linux-gnu-ld: Removing unused section '.text.check_tsc_unstable' in
file 'arch/x86_64/kernel/built-in.o'
...
...
...
x86_64-pc-linux-gnu-ld: Removing unused section '.bss.tr_table' in file
'net/built-in.o'
x86_64-pc-linux-gnu-ld: Removing unused section '.eh_frame' in file
'arch/x86_64/lib/lib.a(csum-copy.o)'
lib/built-in.o succeeded
lib/built-in.o
attempt to open arch/x86_64/lib/built-in.o succeeded
"attempt to open lib/built-in.o succeeded" was printed to stdout,
and due to stdout being fully-buffered when redirected to a file,
it got split in mid-line by output to stderr here:
bfd/elflink.c:
if (info->print_gc_sections && o->size != 0)
_bfd_error_handler (_("Removing unused section '%s' in file '%B'"),
sub, o->name);
The fix is to either make _bfd_error_handler() always do
fflush(stdout) internally before printing to stderr,
or to do setlinebuf(stdout) at the very beginning of ld's main().
--
Summary: ld: --print-gc-sections + --verbose = mess
Product: binutils
Version: 2.18
Status: NEW
Severity: normal
Priority: P2
Component: ld
AssignedTo: unassigned at sources dot redhat dot com
ReportedBy: vda dot linux at googlemail dot com
CC: bug-binutils at gnu dot org
GCC build triplet: any
GCC host triplet: any
GCC target triplet: any
http://sourceware.org/bugzilla/show_bug.cgi?id=4992
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/5006] New: ld --gc-sections erroneously discards a section
I think I have a testcase where ld --gc-sections erroneously
discards a section. I'd appreciate if someone will take
a look at it.
You can download it from
http://busybox.net/~vda/ksymtab_bug.tar.bz2
This testcase is adapted from Linux kernel build.
Kernel image is linked using custom linker script. It must contain some
special sections needed for dynamic loading of external modules at runtime.
One such section is __ksymtab.
It seems that in this testcase ld does not follow instructions
given to it in custom linker script (arch_x86_64_kernel_vmlinux.lds).
For some reason __ksymtab___const_udelay and __ksymtab_synchronize_irq
symbols are not included into zz_vmlinux_bad, while other __ksymtab_*
symbols are included, as intended (for example, __ksymtab___udelay).
--print-gc-sections does not report them as discarded,
and they shouldn't be, because they are coming from __ksymtab input
sections, and arch_x86_64_kernel_vmlinux.lds has KEEP directive for those:
__ksymtab : { KEEP(*(__ksymtab)) }
[in fact, zz_discarded.lst does not indicate any of __ksymtab sections as
discarded]
__ksymtab___const_udelay is in arch_x86_64_lib_lib.a,
__ksymtab_synchronize_irq is in kernel_built-in.o,
so it doesn't seem to be caused by .a versus .o difference.
__ksymtab___const_udelay and __ksymtab_synchronize_irq
are specific to this particular set of .o/.a files.
With slightly different kernel .config, other __ksymtab_XXX sections
will be erroneously discarded. There is no apparent pattern
in which ones will be affected.
# x86_64-pc-linux-gnu-ld -v
GNU ld (GNU Binutils) 2.18
# Bad link:
x86_64-pc-linux-gnu-ld -m elf_x86_64 --gc-sections --print-gc-sections \
--build-id \
-o zz_vmlinux_bad \
-Map zz_link_bad.map -T arch_x86_64_kernel_vmlinux.lds \
\
arch_x86_64_kernel_head.o arch_x86_64_kernel_head64.o \
arch_x86_64_kernel_init_task.o init_built-in.o \
--start-group \
usr_built-in.o arch_x86_64_kernel_built-in.o arch_x86_64_mm_built-in.o \
arch_x86_64_crypto_built-in.o arch_x86_64_vdso_built-in.o \
arch_x86_64_ia32_built-in.o kernel_built-in.o mm_built-in.o \
fs_built-in.o ipc_built-in.o security_built-in.o crypto_built-in.o \
block_built-in.o lib_lib.a arch_x86_64_lib_lib.a lib_built-in.o \
arch_x86_64_lib_built-in.o drivers_built-in.o sound_built-in.o \
arch_x86_64_pci_built-in.o net_built-in.o \
--end-group \
.tmp_kallsyms3.o \
2>zz_discarded.lst
# Here you will see __ksymtab___udelay but no __ksymtab___const_udelay
objdump -x zz_vmlinux_bad | grep 'ksymtab[a-z_]*udelay'
echo
objdump -x zz_vmlinux_bad | grep '_synchronize_irq'
echo
# If one removes --gc-sections, link works:
x86_64-pc-linux-gnu-ld -m elf_x86_64 \
--build-id \
-o zz_vmlinux_good \
-Map zz_link_good.map -T arch_x86_64_kernel_vmlinux.lds \
\
arch_x86_64_kernel_head.o arch_x86_64_kernel_head64.o \
arch_x86_64_kernel_init_task.o init_built-in.o \
--start-group \
usr_built-in.o arch_x86_64_kernel_built-in.o arch_x86_64_mm_built-in.o \
arch_x86_64_crypto_built-in.o arch_x86_64_vdso_built-in.o \
arch_x86_64_ia32_built-in.o kernel_built-in.o mm_built-in.o \
fs_built-in.o ipc_built-in.o security_built-in.o crypto_built-in.o \
block_built-in.o lib_lib.a arch_x86_64_lib_lib.a lib_built-in.o \
arch_x86_64_lib_built-in.o drivers_built-in.o sound_built-in.o \
arch_x86_64_pci_built-in.o net_built-in.o \
--end-group \
.tmp_kallsyms3.o
# Here you will see both __ksymtab___udelay and __ksymtab___const_udelay
objdump -x zz_vmlinux_good | grep 'ksymtab[a-z_]*udelay'
echo
objdump -x zz_vmlinux_good | grep '_synchronize_irq'
echo
Sample output:
806e0f00 l O __ksymtab 0010 __ksymtab___udelay
(__ksymtab___const_udelay should be listed too, but it isnt)
806eb590 l O __kcrctab 0008
__kcrctab_synchronize_irq
806f4b20 l O __ksymtab_strings 0010
__kstrtab_synchronize_irq
e523ad75 g *ABS* __crc_synchronize_irq
806e7050 l O __ksymtab 0010
__ksymtab___const_udelay
806e7060 l O __ksymtab 0010 __ksymtab___udelay
806f16f0 l O __kcrctab 0008
__kcrctab_synchronize_irq
806e3b90 l O __ksymtab 0010
__ksymtab_synchronize_irq
806fac80 l O __ksymtab_strings 0010
__kstrtab_synchronize_irq
e523ad75 g *ABS* __crc_synchronize_irq
--
Summary: ld --gc-sections erroneously discards a section
Product: binutils
Version: 2.18
Status: NEW
Severity: normal
Priority: P2
Component: ld
AssignedTo: unassigned at sources dot redhat dot com
ReportedBy: vda dot linux at googlemail dot com
CC: bug-binutils at gnu dot org
GCC build triplet: x86_64-pc-linux-gnu
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux
[Bug ld/4992] ld: --print-gc-sections + --verbose = mess
--- Additional Comments From vda dot linux at googlemail dot com 2007-09-08 13:57 --- Tested, works for me. Thanks! -- http://sourceware.org/bugzilla/show_bug.cgi?id=4992 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/5006] Alignment padding for bss overwrites random file locations
--- Additional Comments From vda dot linux at googlemail dot com
2007-09-08 14:36 ---
Thanks for incredibly fast analysis and bugfix!
I looked into how .bss_page_aligned got progbits in first place.
GCC seems to infer nobits v. progbits based on *section name*! Oh crap...
char boot_cpu_stack[IRQSTACKSIZE] __attribute__((section(".bss.page_aligned")));
gets nobits,
char boot_cpu_stack[IRQSTACKSIZE] __attribute__((section(".bss_page_aligned")));
gets progbits.
Somehow it doesn't feel like the Right Thing to do.
Jakub Jelinek already was pointing this out here
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00258.html
Anyway, I will be able to make it work now.
Thanks again!
--
http://sourceware.org/bugzilla/show_bug.cgi?id=5006
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/5025] New: SEGV with ld --build-id + "/DISCARD/ : { *(.note.gnu.build-id) }"
$ echo "int main() { return 1; }" >t.c
$ gcc -Wl,--verbose t.c >script.lds
Edit script.lds like this
- .note.gnu.build-id : { *(.note.gnu.build-id) }
+ /DISCARD/ : { *(.note.gnu.build-id) }
(and remove everything except linker script, of course)
Now try to link with --build-id:
$ gcc -Wl,--build-id -Wl,-T -Wl,script.lds t.c
collect2: ld terminated with signal 11 [Segmentation fault]
$ ld -v
GNU ld (GNU Binutils) 2.18
--
Summary: SEGV with ld --build-id + "/DISCARD/ : {
*(.note.gnu.build-id) }"
Product: binutils
Version: 2.18
Status: NEW
Severity: normal
Priority: P2
Component: ld
AssignedTo: unassigned at sources dot redhat dot com
ReportedBy: vda dot linux at googlemail dot com
CC: bug-binutils at gnu dot org
GCC build triplet: i386-pc-linux-gnu
GCC host triplet: i386-pc-linux-gnu
GCC target triplet: i386-pc-linux-gnu
http://sourceware.org/bugzilla/show_bug.cgi?id=5025
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/5543] Assembler crashes on .set
--- Additional Comments From vda dot linux at googlemail dot com
2008-02-20 00:00 ---
bfd/elf.c:
static bfd_boolean
swap_out_syms (bfd *abfd,
struct bfd_strtab_hash **sttp,
int relocatable_p) {
...
/* Writing this would be a hell of a lot easier if
we had some decent documentation on bfd, and
knew what to expect of the library, and what to
demand of applications. For example, it
appears that `objcopy' might not set the
section of a symbol to be a section that is
actually in the output file. */
fprintf(stderr, "vda: sec->name '%s'\n", sec->name);
sec2 = bfd_get_section_by_name (abfd, sec->name);
if (sec2 == NULL)
{
_bfd_error_handler (_("\
Unable to find equivalent output section for symbol '%s' from section '%s'"),
syms[idx]->name ? syms[idx]->name :
"",
sec->name);
bfd_set_error (bfd_error_invalid_operation);
_bfd_stringtab_free (stt);
return FALSE;
}
fprintf(stderr, "vda: sec2->name '%s'\n", sec2->name);
shndx = _bfd_elf_section_from_bfd_section (abfd, sec2);
BFD_ASSERT (shndx != -1);
Both print the same:
vda: sec->name '*GAS `reg' section*'
vda: sec2->name '*GAS `reg' section*'
This section is created here: gas/as.c:
static void perform_an_assembly_pass (int argc, char ** argv) {
...
reg_section = subseg_new ("*GAS `reg' section*", 0);
and is removed in gas/write.c:
void write_object_file (void) {
...
bfd_section_list_remove (stdoutput, reg_section);
write_object_file() is invoked in main() way before xexit() ->
-> bfd_close()
-> BFD_SEND_FMT (abfd, _bfd_write_contents, (abfd)))
-> _bfd_elf_write_object_contents
-> _bfd_elf_compute_section_file_positions
-> swap_out_syms
--
http://sourceware.org/bugzilla/show_bug.cgi?id=5543
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/5543] Assembler crashes on .set
--- Additional Comments From vda dot linux at googlemail dot com 2008-02-21 11:58 --- Sorry H.J. Lu, I tried the patch and both test programs: .globl foo .setfoo,(%eax) and .setfoo,(%eax) .globl foo still produced this message: ./gas/as-new: BFD (GNU Binutils) 2.18.50.20080219 assertion fail ../../bfd/elf.c:6344 ./gas/as-new: BFD (GNU Binutils) 2.18.50.20080219 internal error, aborting at ../../bfd/elfcode.h line 221 in bfd_elf32_swap_symbol_out ./gas/as-new: Please report this bug. -- http://sourceware.org/bugzilla/show_bug.cgi?id=5543 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/5543] Assembler crashes on .set
--- Additional Comments From vda dot linux at googlemail dot com 2008-02-21 12:00 --- Created an attachment (id=2279) --> (http://sourceware.org/bugzilla/attachment.cgi?id=2279&action=view) Fix for bug 5543: disallow symbols .set to register name to be .global Behavior with this patch: .globl foo .setfoo,(%eax) z.s: Assembler messages: z.s:2: Error: attempt to produce global register symbol and .setfoo,(%eax) .globl foo z2.s: Assembler messages: z2.s:2: Error: cannot make register symbol global -- http://sourceware.org/bugzilla/show_bug.cgi?id=5543 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/4907] readelf doesn't dump .eh_frame_hdr section
--- Additional Comments From vda dot linux at googlemail dot com 2008-02-22 13:30 --- Created an attachment (id=2288) --> (http://sourceware.org/bugzilla/attachment.cgi?id=2288&action=view) First stab at dumping .eh_frame[_hdr] sections With this patch dumping "head" from coreutils (readelf -all -w head) looks like this: Exception information header section '.eh_frame_hdr' Addr: 0x0804d850 Offset: 0x005850 Version: 1 eh_frame_ptr: 0x28 Binary search table of 0x4 elements: 0: 0xea20 0x44 1: 0xeb78 0x64 2: 0xed04 0x84 3: 0xee10 0xa4 Exception information section '.eh_frame' Addr: 0x0804d87c Offset: 0x00587c CFI 0: Length: 0x0014 - CIE: Version: 1 Augmentation string: 'zR' Code Alignment Factor: 0x1 Data Alignment Factor: 0xfffc Augmentation Data (8 bytes): 0x01 0x1b 0x0c 0x04 0x04 0x88 0x01 0x00 Length: 0x001c - FDE 0: CIE ptr: 0x001c Length: 0x001c - FDE 1: CIE ptr: 0x003c Length: 0x001c - FDE 2: CIE ptr: 0x005c Length: 0x001c - FDE 3: CIE ptr: 0x007c -- http://sourceware.org/bugzilla/show_bug.cgi?id=4907 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/3134] objdump incompletely decodes mov disp:32 instruction
--- Additional Comments From vda dot linux at googlemail dot com
2008-02-22 15:04 ---
According to the .pdf, MOV.L ERs,@(d:32,ERd) instruction has this encoding:
[01] [00] [78] [0erd 0] [6B] [A 0ers] [disp:32]
or
[01] [00] [78] [1erd 0] [6B] [A 0ers] [disp:32]
where "[]" are bytes (or bigger: disp is 4 bytes).
I think it corresponds to this line in include/opcode/h8300.h:
{O (O_MOV, SL), AV_H8H, 6, "mov.l", {{DISP32SRC, RD32, E}},
{{PREFIX_0100, 0x7, 0x8, B30 | DISPREG, 0x0, 0x6, 0xb, 0x2, RD32, SRC |
DISP32LIST, E}}},
"PREFIX_0100, 0x7, 0x8, B30 | DISPREG..." part directly corresponds to
"[01] [00] [78] [0erd 0]"
B30 constant seems to mean "bit 3 in the nibble must be low":
B30 = 0x2000, /* Bit 3 must be low. */
So, just removing it (replacing "B30 | DISPREG" by "DISPREG" in that line)
should do the trick. Markus, can you try it?
--
http://sourceware.org/bugzilla/show_bug.cgi?id=3134
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
