* DWARF5 DW_AT_data_bit_offset
@ 2020-10-02 16:11 Mark Wielaard
2020-10-02 21:18 ` Arnaldo Carvalho de Melo
0 siblings, 1 reply; 7+ messages in thread
From: Mark Wielaard @ 2020-10-02 16:11 UTC (permalink / raw)
To: dwarves
Hi,
Seems pahole with a recent version of elfutils libdw already handles
most DWARF5 encodings. One thing it doesn't handle yet is
DW_AT_data_bit_offset (this is actually a DWARF4 thing, but gcc only
emits it for -gdwarf-5).
Note that the actual bit offset for the different attributes is defined
differently:
DW_AT_bit_offset: The bit offset attribute describes the offset in bits
of the high order bit of a value of the given type from the high order
bit of the storage unit used to contain that value.
DW_AT_data_bit_offset: the value is an integer constant that specifies
the number of bits from the beginning of the containing entity to the
beginning of the data member.
If there is a DW_AT_data_bit_offset instead of a
DW_AT_data_member_location then there will be no DW_AT_byte_size and no
DW_AT_bit_offset.
DWARF5 has some example for big and little endian in D.2.8 C/C++ Bit-
Field Examples
dwarf_loader.c already seems to do the right thing for little-endian
machines with DW_AT_data_member_location and DW_AT_bit_offset. For
DW_AT_data_bit_offset it doesn't have to do this fixup because it is
already defined as you would expect.
Example that shows the issue:
$ cat bf.c
struct pea
{
int type;
long a:1, b:1, c:1;
};
struct pea p;
$ gcc -gdwarf-4 -c bf.c
$ ./pahole ./bf.o
struct pea {
int type; /* 0 4 */
/* Bitfield combined with previous fields */
long int a:1; /* 0:32 8 */
long int b:1; /* 0:33 8 */
long int c:1; /* 0:34 8 */
/* size: 8, cachelines: 1, members: 4 */
/* bit_padding: 29 bits */
/* last cacheline: 8 bytes */
};
$ gcc -gdwarf-5 -c bf.c
$ ./pahole ./bf.o
DW_AT_<0xd>=0x21
DW_AT_<0xd>=0x21
DW_AT_<0xd>=0x21
struct pea {
int type; /* 0 4 */
static long int a; /* 0 0 */
static long int b; /* 0 0 */
static long int c; /* 0 0 */
/* size: 8, cachelines: 1, members: 1, static members: 3 */
/* padding: 4 */
/* last cacheline: 8 bytes */
};
Note that GCC11 might default to DWARF5.
Cheers,
Mark
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: DWARF5 DW_AT_data_bit_offset 2020-10-02 16:11 DWARF5 DW_AT_data_bit_offset Mark Wielaard @ 2020-10-02 21:18 ` Arnaldo Carvalho de Melo 2021-01-21 11:35 ` Mark Wielaard 0 siblings, 1 reply; 7+ messages in thread From: Arnaldo Carvalho de Melo @ 2020-10-02 21:18 UTC (permalink / raw) To: Mark Wielaard; +Cc: dwarves Em Fri, Oct 02, 2020 at 06:11:06PM +0200, Mark Wielaard escreveu: > Hi, > > Seems pahole with a recent version of elfutils libdw already handles > most DWARF5 encodings. One thing it doesn't handle yet is > DW_AT_data_bit_offset (this is actually a DWARF4 thing, but gcc only > emits it for -gdwarf-5). > > Note that the actual bit offset for the different attributes is defined > differently: > > DW_AT_bit_offset: The bit offset attribute describes the offset in bits > of the high order bit of a value of the given type from the high order > bit of the storage unit used to contain that value. > > DW_AT_data_bit_offset: the value is an integer constant that specifies > the number of bits from the beginning of the containing entity to the > beginning of the data member. > > If there is a DW_AT_data_bit_offset instead of a > DW_AT_data_member_location then there will be no DW_AT_byte_size and no > DW_AT_bit_offset. > > DWARF5 has some example for big and little endian in D.2.8 C/C++ Bit- > Field Examples > > dwarf_loader.c already seems to do the right thing for little-endian > machines with DW_AT_data_member_location and DW_AT_bit_offset. For > DW_AT_data_bit_offset it doesn't have to do this fixup because it is > already defined as you would expect. > > Example that shows the issue: > > $ cat bf.c > struct pea > { > int type; > long a:1, b:1, c:1; > }; > > struct pea p; > > $ gcc -gdwarf-4 -c bf.c > $ ./pahole ./bf.o > struct pea { > int type; /* 0 4 */ > > /* Bitfield combined with previous fields */ > > long int a:1; /* 0:32 8 */ > long int b:1; /* 0:33 8 */ > long int c:1; /* 0:34 8 */ > > /* size: 8, cachelines: 1, members: 4 */ > /* bit_padding: 29 bits */ > /* last cacheline: 8 bytes */ > }; > $ gcc -gdwarf-5 -c bf.c > $ ./pahole ./bf.o > DW_AT_<0xd>=0x21 > DW_AT_<0xd>=0x21 > DW_AT_<0xd>=0x21 > struct pea { > int type; /* 0 4 */ > static long int a; /* 0 0 */ > static long int b; /* 0 0 */ > static long int c; /* 0 0 */ > > /* size: 8, cachelines: 1, members: 1, static members: 3 */ > /* padding: 4 */ > /* last cacheline: 8 bytes */ > }; > > Note that GCC11 might default to DWARF5. Thanks for the detailed report, I'm releasing v1.18 right now, will look into that for v1.19. - Arnaldo ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: DWARF5 DW_AT_data_bit_offset 2020-10-02 21:18 ` Arnaldo Carvalho de Melo @ 2021-01-21 11:35 ` Mark Wielaard 2021-01-28 12:11 ` [PATCH/RFC] " Arnaldo Carvalho de Melo 0 siblings, 1 reply; 7+ messages in thread From: Mark Wielaard @ 2021-01-21 11:35 UTC (permalink / raw) To: Arnaldo Carvalho de Melo; +Cc: dwarves Hi, On Fri, Oct 02, 2020 at 06:18:19PM -0300, Arnaldo Carvalho de Melo wrote: > Em Fri, Oct 02, 2020 at 06:11:06PM +0200, Mark Wielaard escreveu: > > Seems pahole with a recent version of elfutils libdw already handles > > most DWARF5 encodings. One thing it doesn't handle yet is > > DW_AT_data_bit_offset (this is actually a DWARF4 thing, but gcc only > > emits it for -gdwarf-5). > > > > Note that the actual bit offset for the different attributes is defined > > differently: > > > > DW_AT_bit_offset: The bit offset attribute describes the offset in bits > > of the high order bit of a value of the given type from the high order > > bit of the storage unit used to contain that value. > > > > DW_AT_data_bit_offset: the value is an integer constant that specifies > > the number of bits from the beginning of the containing entity to the > > beginning of the data member. > > > > If there is a DW_AT_data_bit_offset instead of a > > DW_AT_data_member_location then there will be no DW_AT_byte_size and no > > DW_AT_bit_offset. > > > > DWARF5 has some example for big and little endian in D.2.8 C/C++ Bit- > > Field Examples > > > > dwarf_loader.c already seems to do the right thing for little-endian > > machines with DW_AT_data_member_location and DW_AT_bit_offset. For > > DW_AT_data_bit_offset it doesn't have to do this fixup because it is > > already defined as you would expect. > > > > Example that shows the issue: > > > > $ cat bf.c > > struct pea > > { > > int type; > > long a:1, b:1, c:1; > > }; > > > > struct pea p; > > > > $ gcc -gdwarf-4 -c bf.c > > $ ./pahole ./bf.o > > struct pea { > > int type; /* 0 4 */ > > > > /* Bitfield combined with previous fields */ > > > > long int a:1; /* 0:32 8 */ > > long int b:1; /* 0:33 8 */ > > long int c:1; /* 0:34 8 */ > > > > /* size: 8, cachelines: 1, members: 4 */ > > /* bit_padding: 29 bits */ > > /* last cacheline: 8 bytes */ > > }; > > $ gcc -gdwarf-5 -c bf.c > > $ ./pahole ./bf.o > > DW_AT_<0xd>=0x21 > > DW_AT_<0xd>=0x21 > > DW_AT_<0xd>=0x21 > > struct pea { > > int type; /* 0 4 */ > > static long int a; /* 0 0 */ > > static long int b; /* 0 0 */ > > static long int c; /* 0 0 */ > > > > /* size: 8, cachelines: 1, members: 1, static members: 3 */ > > /* padding: 4 */ > > /* last cacheline: 8 bytes */ > > }; > > > > Note that GCC11 might default to DWARF5. > > Thanks for the detailed report, I'm releasing v1.18 right now, will look > into that for v1.19. Note that GCC11 indeed just switched to producing DWARF5 by default. It is not released yet, but already in stage4 and Fedora will start doing a mass-rebuild with it soon to shake out the last remaining bugs. Cheers, Mark ^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH/RFC] Re: DWARF5 DW_AT_data_bit_offset 2021-01-21 11:35 ` Mark Wielaard @ 2021-01-28 12:11 ` Arnaldo Carvalho de Melo 2021-01-28 12:54 ` Daniel P. Berrangé 0 siblings, 1 reply; 7+ messages in thread From: Arnaldo Carvalho de Melo @ 2021-01-28 12:11 UTC (permalink / raw) To: Mark Wielaard; +Cc: Daniel Berrangé, dwarves Em Thu, Jan 21, 2021 at 12:35:16PM +0100, Mark Wielaard escreveu: > On Fri, Oct 02, 2020 at 06:18:19PM -0300, Arnaldo Carvalho de Melo wrote: > > Em Fri, Oct 02, 2020 at 06:11:06PM +0200, Mark Wielaard escreveu: > > > Seems pahole with a recent version of elfutils libdw already handles > > > most DWARF5 encodings. One thing it doesn't handle yet is > > > DW_AT_data_bit_offset (this is actually a DWARF4 thing, but gcc only > > > emits it for -gdwarf-5). <SNIP> > > > $ gcc -gdwarf-5 -c bf.c > > > $ ./pahole ./bf.o > > > DW_AT_<0xd>=0x21 > > > DW_AT_<0xd>=0x21 > > > DW_AT_<0xd>=0x21 > > > struct pea { > > > int type; /* 0 4 */ > > > static long int a; /* 0 0 */ > > > static long int b; /* 0 0 */ > > > static long int c; /* 0 0 */ > > > > > > /* size: 8, cachelines: 1, members: 1, static members: 3 */ > > > /* padding: 4 */ > > > /* last cacheline: 8 bytes */ > > > }; > > > Note that GCC11 might default to DWARF5. > > Thanks for the detailed report, I'm releasing v1.18 right now, will look > > into that for v1.19. > Note that GCC11 indeed just switched to producing DWARF5 by default. > It is not released yet, but already in stage4 and Fedora will start > doing a mass-rebuild with it soon to shake out the last remaining bugs. So, 1.20 will have the fix below, please check if what is in: https://git.kernel.org/pub/scm/devel/pahole/pahole.git/log/?h=DW_AT_data_bit_offset Fixes it for you, the cset with all the tests performed is this one: https://git.kernel.org/pub/scm/devel/pahole/pahole.git/commit/?h=DW_AT_data_bit_offset&id=a77f039bb49bc97badf938049245f013fe3de4aa Now looking at https://bugzilla.redhat.com/show_bug.cgi?id=1919965 ... For convenience: commit a77f039bb49bc97badf938049245f013fe3de4aa Author: Arnaldo Carvalho de Melo <acme@redhat.com> Date: Thu Jan 28 08:51:31 2021 -0300 dwarf_loader: Support DW_AT_data_bit_offset This appeared in DWARF4 but is supported only in gcc's -gdwarf-5, support it in a way that makes the output be the same for both cases: $ gcc -gdwarf-4 -c examples/dwarf5/bf.c $ pahole bf.o struct pea { long int a:1; /* 0: 0 8 */ long int b:1; /* 0: 1 8 */ long int c:1; /* 0: 2 8 */ /* XXX 29 bits hole, try to pack */ /* Bitfield combined with next fields */ int after_bitfield; /* 4 4 */ /* size: 8, cachelines: 1, members: 4 */ /* sum members: 4 */ /* sum bitfield members: 3 bits, bit holes: 1, sum bit holes: 29 bits */ /* last cacheline: 8 bytes */ }; $ gcc -gdwarf-5 -c examples/dwarf5/bf.c $ pahole bf.o struct pea { long int a:1; /* 0: 0 8 */ long int b:1; /* 0: 1 8 */ long int c:1; /* 0: 2 8 */ /* XXX 29 bits hole, try to pack */ /* Bitfield combined with next fields */ int after_bitfield; /* 4 4 */ /* size: 8, cachelines: 1, members: 4 */ /* sum members: 4 */ /* sum bitfield members: 3 bits, bit holes: 1, sum bit holes: 29 bits */ /* last cacheline: 8 bytes */ }; $ Now with an integer before the bitfield: $ cat examples/dwarf5/bf.c struct pea { int before_bitfield; long a:1, b:1, c:1; int after_bitfield; } p; $ gcc -gdwarf-4 -c examples/dwarf5/bf.c $ pahole bf.o struct pea { int before_bitfield; /* 0 4 */ /* Bitfield combined with previous fields */ long int a:1; /* 0:32 8 */ long int b:1; /* 0:33 8 */ long int c:1; /* 0:34 8 */ /* XXX 29 bits hole, try to pack */ int after_bitfield; /* 8 4 */ /* size: 16, cachelines: 1, members: 5 */ /* sum members: 8 */ /* sum bitfield members: 3 bits, bit holes: 1, sum bit holes: 29 bits */ /* padding: 4 */ /* last cacheline: 16 bytes */ }; $ gcc -gdwarf-5 -c examples/dwarf5/bf.c $ pahole bf.o struct pea { int before_bitfield; /* 0 4 */ /* Bitfield combined with previous fields */ long int a:1; /* 0:32 8 */ long int b:1; /* 0:33 8 */ long int c:1; /* 0:34 8 */ /* XXX 29 bits hole, try to pack */ int after_bitfield; /* 8 4 */ /* size: 16, cachelines: 1, members: 5 */ /* sum members: 8 */ /* sum bitfield members: 3 bits, bit holes: 1, sum bit holes: 29 bits */ /* padding: 4 */ /* last cacheline: 16 bytes */ }; $ And an array of long integers at the start, before the combination of an integer with a long integer bitfield: $ cat examples/dwarf5/bf.c struct pea { long array[3]; int before_bitfield; long a:1, b:1, c:1; int after_bitfield; } p; $ gcc -gdwarf-4 -c examples/dwarf5/bf.c $ pahole bf.o struct pea { long int array[3]; /* 0 24 */ int before_bitfield; /* 24 4 */ /* Bitfield combined with previous fields */ long int a:1; /* 24:32 8 */ long int b:1; /* 24:33 8 */ long int c:1; /* 24:34 8 */ /* XXX 29 bits hole, try to pack */ int after_bitfield; /* 32 4 */ /* size: 40, cachelines: 1, members: 6 */ /* sum members: 32 */ /* sum bitfield members: 3 bits, bit holes: 1, sum bit holes: 29 bits */ /* padding: 4 */ /* last cacheline: 40 bytes */ }; $ gcc -gdwarf-5 -c examples/dwarf5/bf.c $ pahole bf.o struct pea { long int array[3]; /* 0 24 */ int before_bitfield; /* 24 4 */ /* Bitfield combined with previous fields */ long int a:1; /* 24:32 8 */ long int b:1; /* 24:33 8 */ long int c:1; /* 24:34 8 */ /* XXX 29 bits hole, try to pack */ int after_bitfield; /* 32 4 */ /* size: 40, cachelines: 1, members: 6 */ /* sum members: 32 */ /* sum bitfield members: 3 bits, bit holes: 1, sum bit holes: 29 bits */ /* padding: 4 */ /* last cacheline: 40 bytes */ }; $ Reported-by: Mark Wielaard <mark@klomp.org> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> diff --git a/dwarf_loader.c b/dwarf_loader.c index 8d27e4fc236b9575..ac22c1b0883ddee6 100644 --- a/dwarf_loader.c +++ b/dwarf_loader.c @@ -776,27 +776,36 @@ static struct class_member *class_member__new(Dwarf_Die *die, struct cu *cu, Dwarf_Attribute attr; - if (dwarf_attr(die, DW_AT_data_member_location, &attr) != NULL) { - member->byte_offset = __attr_offset(&attr); + member->has_bit_offset = dwarf_attr(die, DW_AT_data_bit_offset, &attr) != NULL; + + if (member->has_bit_offset) { + member->bit_offset = __attr_offset(&attr); + // byte_offset and bitfield_offset will be recalculated later, when + // we discover the size of this bitfield base type. } else { - member->is_static = !in_union; + if (dwarf_attr(die, DW_AT_data_member_location, &attr) != NULL) { + member->byte_offset = __attr_offset(&attr); + } else { + member->is_static = !in_union; + } + + /* + * Bit offset calculated here is valid only for byte-aligned + * fields. For bitfields on little-endian archs we need to + * adjust them taking into account byte size of the field, + * which might not be yet known. So we'll re-calculate bit + * offset later, in class_member__cache_byte_size. + */ + member->bit_offset = member->byte_offset * 8; + member->bitfield_offset = attr_numeric(die, DW_AT_bit_offset); } - /* - * Bit offset calculated here is valid only for byte-aligned - * fields. For bitfields on little-endian archs we need to - * adjust them taking into account byte size of the field, - * which might not be yet known. So we'll re-calculate bit - * offset later, in class_member__cache_byte_size. - */ - member->bit_offset = member->byte_offset * 8; /* * If DW_AT_byte_size is not present, byte size will be * determined later in class_member__cache_byte_size using * base integer/enum type */ member->byte_size = attr_numeric(die, DW_AT_byte_size); - member->bitfield_offset = attr_numeric(die, DW_AT_bit_offset); member->bitfield_size = attr_numeric(die, DW_AT_bit_size); member->bit_hole = 0; member->bitfield_end = 0; @@ -2275,24 +2284,31 @@ static int class_member__cache_byte_size(struct tag *tag, struct cu *cu, return 0; } - /* - * For little-endian architectures, DWARF data emitted by gcc/clang - * specifies bitfield offset as an offset from the highest-order bit - * of an underlying integral type (e.g., int) to a highest-order bit - * of a bitfield. E.g., for bitfield taking first 5 bits of int-backed - * bitfield, bit offset will be 27 (sizeof(int) - 0 offset - 5 bit - * size), which is very counter-intuitive and isn't a natural - * extension of byte offset, which on little-endian points to - * lowest-order byte. So here we re-adjust bitfield offset to be an - * offset from lowest-order bit of underlying integral type to - * a lowest-order bit of a bitfield. This makes bitfield offset - * a natural extension of byte offset for bitfields and is uniform - * with how big-endian bit offsets work. - */ - if (cu->little_endian) { - member->bitfield_offset = member->bit_size - member->bitfield_offset - member->bitfield_size; + if (!member->has_bit_offset) { + /* + * For little-endian architectures, DWARF data emitted by gcc/clang + * specifies bitfield offset as an offset from the highest-order bit + * of an underlying integral type (e.g., int) to a highest-order bit + * of a bitfield. E.g., for bitfield taking first 5 bits of int-backed + * bitfield, bit offset will be 27 (sizeof(int) - 0 offset - 5 bit + * size), which is very counter-intuitive and isn't a natural + * extension of byte offset, which on little-endian points to + * lowest-order byte. So here we re-adjust bitfield offset to be an + * offset from lowest-order bit of underlying integral type to + * a lowest-order bit of a bitfield. This makes bitfield offset + * a natural extension of byte offset for bitfields and is uniform + * with how big-endian bit offsets work. + */ + if (cu->little_endian) + member->bitfield_offset = member->bit_size - member->bitfield_offset - member->bitfield_size; + + member->bit_offset = member->byte_offset * 8 + member->bitfield_offset; + } else { + // DWARF5 has DW_AT_data_bit_offset, offset in bits from the + // start of the container type (struct, class, etc). + member->byte_offset = member->bit_offset / 8; + member->bitfield_offset = member->bit_offset - member->byte_offset * 8; } - member->bit_offset = member->byte_offset * 8 + member->bitfield_offset; /* make sure bitfield offset is non-negative */ if (member->bitfield_offset < 0) { diff --git a/dwarves.h b/dwarves.h index 24405b79ac71e686..98caf1abc54d58fa 100644 --- a/dwarves.h +++ b/dwarves.h @@ -899,6 +899,7 @@ static inline int function__inlined(const struct function *func) * @accessibility - DW_ACCESS_{public,protected,private} * @virtuality - DW_VIRTUALITY_{none,virtual,pure_virtual} * @hole - If there is a hole before the next one (or the end of the struct) + * @has_bit_offset: Don't recalcule this, it came from the debug info (DWARF5's DW_AT_data_bit_offset) */ struct class_member { struct tag tag; @@ -915,6 +916,7 @@ struct class_member { uint32_t alignment; uint8_t visited:1; uint8_t is_static:1; + uint8_t has_bit_offset:1; uint8_t accessibility:2; uint8_t virtuality:2; uint16_t hole; ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH/RFC] Re: DWARF5 DW_AT_data_bit_offset 2021-01-28 12:11 ` [PATCH/RFC] " Arnaldo Carvalho de Melo @ 2021-01-28 12:54 ` Daniel P. Berrangé 2021-01-28 13:48 ` Arnaldo Carvalho de Melo 2021-01-28 13:54 ` Arnaldo Carvalho de Melo 0 siblings, 2 replies; 7+ messages in thread From: Daniel P. Berrangé @ 2021-01-28 12:54 UTC (permalink / raw) To: Arnaldo Carvalho de Melo; +Cc: Mark Wielaard, dwarves On Thu, Jan 28, 2021 at 09:11:22AM -0300, Arnaldo Carvalho de Melo wrote: > Em Thu, Jan 21, 2021 at 12:35:16PM +0100, Mark Wielaard escreveu: > > On Fri, Oct 02, 2020 at 06:18:19PM -0300, Arnaldo Carvalho de Melo wrote: > > > Em Fri, Oct 02, 2020 at 06:11:06PM +0200, Mark Wielaard escreveu: > > > > Seems pahole with a recent version of elfutils libdw already handles > > > > most DWARF5 encodings. One thing it doesn't handle yet is > > > > DW_AT_data_bit_offset (this is actually a DWARF4 thing, but gcc only > > > > emits it for -gdwarf-5). > > <SNIP> > > > > > $ gcc -gdwarf-5 -c bf.c > > > > $ ./pahole ./bf.o > > > > DW_AT_<0xd>=0x21 > > > > DW_AT_<0xd>=0x21 > > > > DW_AT_<0xd>=0x21 > > > > struct pea { > > > > int type; /* 0 4 */ > > > > static long int a; /* 0 0 */ > > > > static long int b; /* 0 0 */ > > > > static long int c; /* 0 0 */ > > > > > > > > /* size: 8, cachelines: 1, members: 1, static members: 3 */ > > > > /* padding: 4 */ > > > > /* last cacheline: 8 bytes */ > > > > }; > > > > > Note that GCC11 might default to DWARF5. > > > > Thanks for the detailed report, I'm releasing v1.18 right now, will look > > > into that for v1.19. > > > Note that GCC11 indeed just switched to producing DWARF5 by default. > > It is not released yet, but already in stage4 and Fedora will start > > doing a mass-rebuild with it soon to shake out the last remaining bugs. > > So, 1.20 will have the fix below, please check if what is in: > > https://git.kernel.org/pub/scm/devel/pahole/pahole.git/log/?h=DW_AT_data_bit_offset > > Fixes it for you, the cset with all the tests performed is this one: > > https://git.kernel.org/pub/scm/devel/pahole/pahole.git/commit/?h=DW_AT_data_bit_offset&id=a77f039bb49bc97badf938049245f013fe3de4aa > > Now looking at https://bugzilla.redhat.com/show_bug.cgi?id=1919965 ... The XDR generated code example I give in that bug *does* appear to be fixed when using your DW_AT_data_bit_offset branch. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH/RFC] Re: DWARF5 DW_AT_data_bit_offset 2021-01-28 12:54 ` Daniel P. Berrangé @ 2021-01-28 13:48 ` Arnaldo Carvalho de Melo 2021-01-28 13:54 ` Arnaldo Carvalho de Melo 1 sibling, 0 replies; 7+ messages in thread From: Arnaldo Carvalho de Melo @ 2021-01-28 13:48 UTC (permalink / raw) To: Daniel P. Berrangé; +Cc: Mark Wielaard, dwarves Em Thu, Jan 28, 2021 at 12:54:43PM +0000, Daniel P. Berrangé escreveu: > On Thu, Jan 28, 2021 at 09:11:22AM -0300, Arnaldo Carvalho de Melo wrote: > > Em Thu, Jan 21, 2021 at 12:35:16PM +0100, Mark Wielaard escreveu: > > > On Fri, Oct 02, 2020 at 06:18:19PM -0300, Arnaldo Carvalho de Melo wrote: > > > > Em Fri, Oct 02, 2020 at 06:11:06PM +0200, Mark Wielaard escreveu: > > > > > Seems pahole with a recent version of elfutils libdw already handles > > > > > most DWARF5 encodings. One thing it doesn't handle yet is > > > > > DW_AT_data_bit_offset (this is actually a DWARF4 thing, but gcc only > > > > > emits it for -gdwarf-5). > > > > <SNIP> > > > > > > > $ gcc -gdwarf-5 -c bf.c > > > > > $ ./pahole ./bf.o > > > > > DW_AT_<0xd>=0x21 > > > > > DW_AT_<0xd>=0x21 > > > > > DW_AT_<0xd>=0x21 > > > > > struct pea { > > > > > int type; /* 0 4 */ > > > > > static long int a; /* 0 0 */ > > > > > static long int b; /* 0 0 */ > > > > > static long int c; /* 0 0 */ > > > > > > > > > > /* size: 8, cachelines: 1, members: 1, static members: 3 */ > > > > > /* padding: 4 */ > > > > > /* last cacheline: 8 bytes */ > > > > > }; > > > > > > > Note that GCC11 might default to DWARF5. > > > > > > Thanks for the detailed report, I'm releasing v1.18 right now, will look > > > > into that for v1.19. > > > > > Note that GCC11 indeed just switched to producing DWARF5 by default. > > > It is not released yet, but already in stage4 and Fedora will start > > > doing a mass-rebuild with it soon to shake out the last remaining bugs. > > > > So, 1.20 will have the fix below, please check if what is in: > > > > https://git.kernel.org/pub/scm/devel/pahole/pahole.git/log/?h=DW_AT_data_bit_offset > > > > Fixes it for you, the cset with all the tests performed is this one: > > > > https://git.kernel.org/pub/scm/devel/pahole/pahole.git/commit/?h=DW_AT_data_bit_offset&id=a77f039bb49bc97badf938049245f013fe3de4aa > > > > Now looking at https://bugzilla.redhat.com/show_bug.cgi?id=1919965 ... > > The XDR generated code example I give in that bug *does* appear > to be fixed when using your DW_AT_data_bit_offset branch. Thanks for checking, I'll double check on my side now, got sidetracked in the last hour with perf patch processing :-) - Arnaldo ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH/RFC] Re: DWARF5 DW_AT_data_bit_offset 2021-01-28 12:54 ` Daniel P. Berrangé 2021-01-28 13:48 ` Arnaldo Carvalho de Melo @ 2021-01-28 13:54 ` Arnaldo Carvalho de Melo 1 sibling, 0 replies; 7+ messages in thread From: Arnaldo Carvalho de Melo @ 2021-01-28 13:54 UTC (permalink / raw) To: Daniel P. Berrangé; +Cc: Mark Wielaard, dwarves Em Thu, Jan 28, 2021 at 12:54:43PM +0000, Daniel P. Berrangé escreveu: > On Thu, Jan 28, 2021 at 09:11:22AM -0300, Arnaldo Carvalho de Melo wrote: > > Em Thu, Jan 21, 2021 at 12:35:16PM +0100, Mark Wielaard escreveu: > > > On Fri, Oct 02, 2020 at 06:18:19PM -0300, Arnaldo Carvalho de Melo wrote: > > > > Em Fri, Oct 02, 2020 at 06:11:06PM +0200, Mark Wielaard escreveu: > > > > > Seems pahole with a recent version of elfutils libdw already handles > > > > > most DWARF5 encodings. One thing it doesn't handle yet is > > > > > DW_AT_data_bit_offset (this is actually a DWARF4 thing, but gcc only > > > > > emits it for -gdwarf-5). > > > > <SNIP> > > > > > > > $ gcc -gdwarf-5 -c bf.c > > > > > $ ./pahole ./bf.o > > > > > DW_AT_<0xd>=0x21 > > > > > DW_AT_<0xd>=0x21 > > > > > DW_AT_<0xd>=0x21 > > > > > struct pea { > > > > > int type; /* 0 4 */ > > > > > static long int a; /* 0 0 */ > > > > > static long int b; /* 0 0 */ > > > > > static long int c; /* 0 0 */ > > > > > > > > > > /* size: 8, cachelines: 1, members: 1, static members: 3 */ > > > > > /* padding: 4 */ > > > > > /* last cacheline: 8 bytes */ > > > > > }; > > > > > > > Note that GCC11 might default to DWARF5. > > > > > > Thanks for the detailed report, I'm releasing v1.18 right now, will look > > > > into that for v1.19. > > > > > Note that GCC11 indeed just switched to producing DWARF5 by default. > > > It is not released yet, but already in stage4 and Fedora will start > > > doing a mass-rebuild with it soon to shake out the last remaining bugs. > > > > So, 1.20 will have the fix below, please check if what is in: > > > > https://git.kernel.org/pub/scm/devel/pahole/pahole.git/log/?h=DW_AT_data_bit_offset > > > > Fixes it for you, the cset with all the tests performed is this one: > > > > https://git.kernel.org/pub/scm/devel/pahole/pahole.git/commit/?h=DW_AT_data_bit_offset&id=a77f039bb49bc97badf938049245f013fe3de4aa > > > > Now looking at https://bugzilla.redhat.com/show_bug.cgi?id=1919965 ... > > The XDR generated code example I give in that bug *does* appear > to be fixed when using your DW_AT_data_bit_offset branch. [acme@five berrange]$ rpcgen -c admin.x > admin.c [acme@five berrange]$ rpcgen -h admin.x > admin.h [acme@five berrange]$ gcc -gdwarf-4 -c `pkg-config --cflags --libs libtirpc` -o admin.o admin.c [acme@five berrange]$ pdwtags --verbose admin.o > pdwtags.dwarf-4.txt [acme@five berrange]$ gcc -gdwarf-5 -c `pkg-config --cflags --libs libtirpc` -o admin.o admin.c [acme@five berrange]$ pdwtags --verbose admin.o > pdwtags.dwarf-5.txt [acme@five berrange]$ diff -u pdwtags.dwarf-4.txt pdwtags.dwarf-5.txt [acme@five berrange]$ I'll go ahead and add a: Acked-by: "Daniel P. Berrangé" <berrange@redhat.com> Ok? - Arnaldo ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2021-01-28 13:55 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-10-02 16:11 DWARF5 DW_AT_data_bit_offset Mark Wielaard 2020-10-02 21:18 ` Arnaldo Carvalho de Melo 2021-01-21 11:35 ` Mark Wielaard 2021-01-28 12:11 ` [PATCH/RFC] " Arnaldo Carvalho de Melo 2021-01-28 12:54 ` Daniel P. Berrangé 2021-01-28 13:48 ` Arnaldo Carvalho de Melo 2021-01-28 13:54 ` Arnaldo Carvalho de Melo
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 NNTP newsgroup(s).