Summary: | Alignment padding for bss overwrites random file locations | ||
---|---|---|---|
Product: | binutils | Reporter: | Denis Vlasenko <vda.linux> |
Component: | ld | Assignee: | Alan Modra <amodra> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | bug-binutils |
Priority: | P2 | ||
Version: | 2.18 | ||
Target Milestone: | --- | ||
Host: | x86_64-pc-linux-gnu | Target: | x86_64-pc-linux-gnu |
Build: | x86_64-pc-linux-gnu | Last reconfirmed: | 2007-09-08 02:32:07 |
Description
Denis Vlasenko
2007-09-07 13:41:40 UTC
Looks like alignment padding for .bss is being written to the file and overwriting the symbol table. Alignment padding should not be written for .bss, but it is because the output .bss has SEC_HAS_CONTENTS set. See ldwite.c:build_link_order <case lang_padding_statement_enum>. SEC_HAS_CONTENTS is set because arch_x86_64_kernel_built-in.o .bss_page_aligned is SHT_PROGBITS. This is wrong. A bss style section should be SHT_NOBITS. However, linking a SHT_PROGBITS section into .bss should simply make .bss SHT_PROGBITS. It doesn't, because .bss has its ELF section type set via bfd_elf_special_section to SHT_NOBITS too early. http://sourceware.org/ml/binutils-cvs/2007-09/msg00030.html http://sourceware.org/ml/binutils-cvs/2007-09/msg00031.html 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 <jakub at redhat dot com> 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! |