public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
* [Bug target/63373] New: ELF symbol sizes for variable-length objects are too small @ 2014-09-25 17:26 srk31 at srcf dot ucam.org 2014-09-26 8:22 ` [Bug middle-end/63373] " rguenth at gcc dot gnu.org ` (5 more replies) 0 siblings, 6 replies; 7+ messages in thread From: srk31 at srcf dot ucam.org @ 2014-09-25 17:26 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63373 Bug ID: 63373 Summary: ELF symbol sizes for variable-length objects are too small Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: srk31 at srcf dot ucam.org Created attachment 33569 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33569&action=edit Source files used in the bug description Suppose I have an object file containing a data object of some variable-length type. $ cat section-size-test.c struct blah { float foo; int i[]; }; struct blah b = { 42.0, { 1, 2, 3, 4, 0 } }; $ cc -c -o section-size-test.o section-size-test.c Now I have an object of size 24 bytes. From ELF's point of view, we have a section of size 24 but a symbol of size only 4. $ readelf -Ss section-size-test.o There are 9 section headers, starting at offset 0xc8: Section Headers: [Nr] Name Type Address Offset Size EntSize Flags Link Info Align [ 0] NULL 0000000000000000 00000000 0000000000000000 0000000000000000 0 0 0 [ 1] .text PROGBITS 0000000000000000 00000040 0000000000000000 0000000000000000 AX 0 0 1 [ 2] .data PROGBITS 0000000000000000 00000040 0000000000000018 0000000000000000 WA 0 0 4 [ 3] .bss NOBITS 0000000000000000 00000058 0000000000000000 0000000000000000 WA 0 0 1 [ 4] .comment PROGBITS 0000000000000000 00000058 0000000000000024 0000000000000001 MS 0 0 1 [ 5] .note.GNU-stack PROGBITS 0000000000000000 0000007c 0000000000000000 0000000000000000 0 0 1 [ 6] .shstrtab STRTAB 0000000000000000 0000007c 0000000000000045 0000000000000000 0 0 1 [ 7] .symtab SYMTAB 0000000000000000 00000308 00000000000000c0 0000000000000018 8 7 8 [ 8] .strtab STRTAB 0000000000000000 000003c8 0000000000000017 0000000000000000 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings), l (large) I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown) O (extra OS processing required) o (OS specific), p (processor specific) Symbol table '.symtab' contains 8 entries: Num: Value Size Type Bind Vis Ndx Name 0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND 1: 0000000000000000 0 FILE LOCAL DEFAULT ABS section-size-test.c 2: 0000000000000000 0 SECTION LOCAL DEFAULT 1 3: 0000000000000000 0 SECTION LOCAL DEFAULT 2 4: 0000000000000000 0 SECTION LOCAL DEFAULT 3 5: 0000000000000000 0 SECTION LOCAL DEFAULT 5 6: 0000000000000000 0 SECTION LOCAL DEFAULT 4 7: 0000000000000000 4 OBJECT GLOBAL DEFAULT 2 b The bug is that when copy relocations are used, the variable-length part of the object will get thrown away. I think the symbol size should also be 24 (hence filing a gcc bug not a binutils bug). Continuing: I create a shared library out of this object file, and an executable that depends on my object. $ cat exe.c struct blah { float foo; int i[]; }; extern struct blah b; int main(void) { return (unsigned long long) &b % 32; } $ cc -shared -o section-size-test.so section-size-test.o $ cc -o exe exe.c section-size-test.so Now the executable is using a copy reloc to address my variable-length object. $ objdump -RT exe exe: file format elf64-x86-64 DYNAMIC SYMBOL TABLE: 0000000000000000 w D *UND* 0000000000000000 _ITM_deregisterTMCloneTable 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 __libc_start_main 0000000000000000 w D *UND* 0000000000000000 __gmon_start__ 0000000000000000 w D *UND* 0000000000000000 _Jv_RegisterClasses 0000000000000000 w D *UND* 0000000000000000 _ITM_registerTMCloneTable 0000000000601038 g D .data 0000000000000000 Base _edata 0000000000601040 g D .bss 0000000000000000 Base _end 0000000000601038 g D .bss 0000000000000000 Base __bss_start 0000000000400550 g DF .init 0000000000000000 Base _init 0000000000601038 g DO .bss 0000000000000004 b 0000000000400724 g DF .fini 0000000000000000 Base _fini DYNAMIC RELOCATION RECORDS OFFSET TYPE VALUE 0000000000600ff8 R_X86_64_GLOB_DAT __gmon_start__ 0000000000601038 R_X86_64_COPY b 0000000000601018 R_X86_64_JUMP_SLOT __libc_start_main 0000000000601020 R_X86_64_JUMP_SLOT __gmon_start__ We can see that b has size 4, and the object has been truncated, since _end is at b+8. The variable-length part of the object has not been copy-relocated. I would guess that the right behaviour is to emit the symbol as having the "full" size of the object, which is clearly known at compile time. Then the linker will (I hope?) create a big enough copy reloc. ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug middle-end/63373] ELF symbol sizes for variable-length objects are too small 2014-09-25 17:26 [Bug target/63373] New: ELF symbol sizes for variable-length objects are too small srk31 at srcf dot ucam.org @ 2014-09-26 8:22 ` rguenth at gcc dot gnu.org 2014-09-26 20:04 ` mikpelinux at gmail dot com ` (4 subsequent siblings) 5 siblings, 0 replies; 7+ messages in thread From: rguenth at gcc dot gnu.org @ 2014-09-26 8:22 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63373 Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jsm28 at gcc dot gnu.org Component|target |middle-end --- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> --- This is also a question if it is valid (GNU) C. The types in both units are definitely not the same. Joseph? ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug middle-end/63373] ELF symbol sizes for variable-length objects are too small 2014-09-25 17:26 [Bug target/63373] New: ELF symbol sizes for variable-length objects are too small srk31 at srcf dot ucam.org 2014-09-26 8:22 ` [Bug middle-end/63373] " rguenth at gcc dot gnu.org @ 2014-09-26 20:04 ` mikpelinux at gmail dot com 2014-09-26 21:21 ` joseph at codesourcery dot com ` (3 subsequent siblings) 5 siblings, 0 replies; 7+ messages in thread From: mikpelinux at gmail dot com @ 2014-09-26 20:04 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63373 --- Comment #2 from Mikael Pettersson <mikpelinux at gmail dot com> --- Related to PR57180? ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug middle-end/63373] ELF symbol sizes for variable-length objects are too small 2014-09-25 17:26 [Bug target/63373] New: ELF symbol sizes for variable-length objects are too small srk31 at srcf dot ucam.org 2014-09-26 8:22 ` [Bug middle-end/63373] " rguenth at gcc dot gnu.org 2014-09-26 20:04 ` mikpelinux at gmail dot com @ 2014-09-26 21:21 ` joseph at codesourcery dot com 2015-03-01 22:03 ` steve at sk2 dot org ` (2 subsequent siblings) 5 siblings, 0 replies; 7+ messages in thread From: joseph at codesourcery dot com @ 2014-09-26 21:21 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63373 --- Comment #3 from joseph at codesourcery dot com <joseph at codesourcery dot com> --- I agree with the analysis in bug 28865 that .size should reflect the presence of the initializer. That bug was marked FIXED, but I'm not clear if the issue described in its summary - "Structures with a flexible arrray member have wrong .size" - did in fact get fixed for some configurations (but not all? or became unfixed?) or only some related issue that was sufficient for the testcases added to pass. I think this code should be considered valid GNU C. ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug middle-end/63373] ELF symbol sizes for variable-length objects are too small 2014-09-25 17:26 [Bug target/63373] New: ELF symbol sizes for variable-length objects are too small srk31 at srcf dot ucam.org ` (2 preceding siblings ...) 2014-09-26 21:21 ` joseph at codesourcery dot com @ 2015-03-01 22:03 ` steve at sk2 dot org 2015-03-01 22:04 ` steve at sk2 dot org 2021-09-12 23:02 ` [Bug target/63373] " pinskia at gcc dot gnu.org 5 siblings, 0 replies; 7+ messages in thread From: steve at sk2 dot org @ 2015-03-01 22:03 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63373 Stephen Kitt <steve at sk2 dot org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |steve at sk2 dot org --- Comment #4 from Stephen Kitt <steve at sk2 dot org> --- Created attachment 34912 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34912&action=edit Pre-processed source reproducing the bug ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug middle-end/63373] ELF symbol sizes for variable-length objects are too small 2014-09-25 17:26 [Bug target/63373] New: ELF symbol sizes for variable-length objects are too small srk31 at srcf dot ucam.org ` (3 preceding siblings ...) 2015-03-01 22:03 ` steve at sk2 dot org @ 2015-03-01 22:04 ` steve at sk2 dot org 2021-09-12 23:02 ` [Bug target/63373] " pinskia at gcc dot gnu.org 5 siblings, 0 replies; 7+ messages in thread From: steve at sk2 dot org @ 2015-03-01 22:04 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63373 --- Comment #5 from Stephen Kitt <steve at sk2 dot org> --- Oops sorry, wrong bug... ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug target/63373] ELF symbol sizes for variable-length objects are too small 2014-09-25 17:26 [Bug target/63373] New: ELF symbol sizes for variable-length objects are too small srk31 at srcf dot ucam.org ` (4 preceding siblings ...) 2015-03-01 22:04 ` steve at sk2 dot org @ 2021-09-12 23:02 ` pinskia at gcc dot gnu.org 5 siblings, 0 replies; 7+ messages in thread From: pinskia at gcc dot gnu.org @ 2021-09-12 23:02 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63373 Andrew Pinski <pinskia at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Component|c |target --- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> --- all (majority of) elf targets was fixed with r5-2566 will file bugs about the other targets. I already filed a bug about the C++ front-end not updating DECL_SIZE (PR 102295). ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2021-09-12 23:02 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-09-25 17:26 [Bug target/63373] New: ELF symbol sizes for variable-length objects are too small srk31 at srcf dot ucam.org 2014-09-26 8:22 ` [Bug middle-end/63373] " rguenth at gcc dot gnu.org 2014-09-26 20:04 ` mikpelinux at gmail dot com 2014-09-26 21:21 ` joseph at codesourcery dot com 2015-03-01 22:03 ` steve at sk2 dot org 2015-03-01 22:04 ` steve at sk2 dot org 2021-09-12 23:02 ` [Bug target/63373] " pinskia at gcc dot gnu.org
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).