Description of problem:
libvirt uses the "pdwtags" program from the dwarves RPM to validate struct ABI info in our test suite.  

Since the upgrade to  gcc-11.0.0-0.15.fc34.x86_64  we've seen bad information produced, claiming there is many entries of bogus padding being added to certain structs.

Using "sizeof" does not show this padding, only the debug symbols claim it exists.

Since libvirt code here is quite complex, I've narrowed it down to the following standalone reproducer


# cat admin.x

const THING_MAX = 16384;
typedef string thing<2>;

struct this {
  thing things<THING_MAX>;
};

struct that {
  thing things<THING_MAX>;
};


$ rpcgen  -c admin.x > admin.c
$ rpcgen  -h admin.x > admin.h
$ gcc -g -c `pkg-config --cflags --libs libtirpc`  -o admin.o admin.c
$ pdwtags --verbose admin.o


This will print out

struct {
        u_int                      things_len;           /*     0     4 */

        /* XXX 4 bytes hole, try to pack */

        thing *                    things_val;           /*     8     8 */

        /* Force padding: */
        thing *                    :64;
        thing *                    :64;
        thing *                    :64;
        thing *                    :64;
        thing *                    :64;
        thing *                    :64;
         ... repeated 16384 times...
        /* size: 0, cachelines: 0, members: 2 */
        /* sum members: 12, holes: 1, sum holes: 4 */
        /* padding: 65520 */

        /* BRAIN FART ALERT! 0 bytes != 12 (member bytes) + 0 (member bits) + 4 (byte holes) + 0 (bit holes), diff = -524288 bits */
}; /* size: 0 */


We can see there's an error message included there from pdwtags indicating there was something in the debuginfo data that it didn't like.

The "pahole" tool prints similar bogus data about padding.


If we ask  "objdump -D -S admin.o"  for a dissassembly of the admin.o file it reports "(bad)" against various asm instructions too.  eg.

Disassembly of section .debug_info:

0000000000000000 <.debug_info>:
{
   0:   d5                      (bad)  
   1:   04 00                   add    $0x0,%al
   3:   00 05 00 01 08 00       add    %al,0x80100(%rip)        # 80109 <xdr_that+0x8007c>
   9:   00 00                   add    %al,(%rax)
   b:   00 0f                   add    %cl,(%rdi)
   d:   00 00                   add    %al,(%rax)
   f:   00 00                   add    %al,(%rax)
         if (!xdr_string (xdrs, objp, 2))
  11:   1d 00 00 00 00          sbb    $0x0,%eax
        ...
  22:   e0 00                   loopne 24 <.debug_info+0x24>
        ...
                 return FALSE;
  2c:   00 00                   add    %al,(%rax)
  2e:   04 01                   add    $0x1,%al
  30:   08 00                   or     %al,(%rax)
  32:   00 00                   add    %al,(%rax)
        return TRUE;
  34:   00 04 02                add    %al,(%rdx,%rax,1)
  37:   07                      (bad)  
}

in both cases downgrading to gcc-11.0.0-0.14.fc34.x86_64 fixes it.

-0.16 is also broken the same as 0.15


What is also peculiar is that I can't make the reproducer any smaller that this admin.x example

eg if i remove 'struct this',  then that fixes debuginfo for "struct that", and vica-verca. Both of them have to be present and it causes bad debuginfo for both of them.

Version-Release number of selected component (if applicable):
gcc-11.0.0-0.15.fc34.x86_64 
dwarves-1.19-1.fc34.x86_64
binutils-2.35.1-16.fc34.x86_64