All of lore.kernel.org
 help / color / mirror / Atom feed
* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.