[Bug target/63373] New: ELF symbol sizes for variable-length objects are too small

[Bug target/63373] New: ELF symbol sizes for variable-length objects are too small

[srk31 at srcf dot ucam.org]

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.

[Bug middle-end/63373] ELF symbol sizes for variable-length objects are too small

[rguenth at gcc dot gnu.org]

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?

[Bug middle-end/63373] ELF symbol sizes for variable-length objects are too small

[mikpelinux at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63373

--- Comment #2 from Mikael Pettersson <mikpelinux at gmail dot com> ---
Related to PR57180?

[Bug middle-end/63373] ELF symbol sizes for variable-length objects are too small

[joseph at codesourcery dot com]

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.

[Bug middle-end/63373] ELF symbol sizes for variable-length objects are too small

[steve at sk2 dot org]

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

[Bug middle-end/63373] ELF symbol sizes for variable-length objects are too small

[steve at sk2 dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63373

--- Comment #5 from Stephen Kitt <steve at sk2 dot org> ---
Oops sorry, wrong bug...

[Bug target/63373] ELF symbol sizes for variable-length objects are too small

[pinskia at gcc dot gnu.org]

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).