From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: Tom Tromey <tromey@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: RFC: implement DW_OP_bit_piece
Date: Thu, 20 May 2010 21:07:00 -0000 [thread overview]
Message-ID: <20100520210135.GA31238@host0.dyn.jankratochvil.net> (raw)
In-Reply-To: <m3ljbgdc4a.fsf@fleche.redhat.com>
On Wed, 19 May 2010 01:27:33 +0200, Tom Tromey wrote:
> We do take care to optimize for the byte-aligned case.
FYI I am strongly against this decision. This creates (a) more complicated
code to maintain (b) less used and more dense to debug codepath (the bits one)
and (c) I doubt current hardware and current `gcc -O2' code will ever notice
a difference - GDB has much more serious performance issues (symbols reading,
lookup) than evaluation of any specific values.
> --- a/gdb/dwarf2expr.c
> +++ b/gdb/dwarf2expr.c
> +/* The lowest-level function to extract bits from a byte buffer.
> + SOURCE is the buffer. It is updated if we read to the end of a
> + byte.
> + SOURCE_OFFSET_BITS is the offset of the first bit to read. It is
> + updated to reflect the number of bits actually read.
> + NBITS is the number of bits we want to read. This function may
> + read fewer bits.
> + BITS_BIG_ENDIAN is taken directly from gdbarch.
> + RESULT is set to the extracted bits.
> + The function returns the number of bits actually read. */
> +
> +static int
> +extract_bits_primitive (const gdb_byte **source,
> + unsigned int *source_offset_bits,
> + int nbits, int bits_big_endian,
> + unsigned int *result)
IMHO either NBITS should be also updated by the number of bits read or SOURCE
and SOURCE_OFFSET_BITS should be updated togetierh with NBITS by the caller.
This is a bit mix of both styles. But this function is not used much so it
does not matter much.
> +{
> + unsigned int avail, mask, datum;
> +
> + gdb_assert (*source_offset_bits < 8);
> +
> + avail = 8 - *source_offset_bits;
> + if (avail > nbits)
> + avail = nbits;
NBITS is no longer used anywhere, AVAIL is used instead. Therefore this
function ignores the caller's wish of NBITS. I would see here more:
if (avail < nbits)
nbits = avail;
And use NBITS instead of AVAIL everywhere later...
> + mask = (1 << avail) - 1;
> +
> + datum = **source;
> + if (bits_big_endian)
> + datum >>= 8 - *source_offset_bits;
Assuming NBITS contains here the caller's wished read width (possible lowered
by the remaining bits available in current byte):
It should be rather:
datum >>= 8 - (*source_offset_bits + nbits);
source_offset_bits = 2
nbits = 3
mask = 7
b0 b1 b2 b3 b4 b5 b6 b7 = big endian bits numbering
128 64 32 16 8 4 2 1 = value represented by this bit
drop drop WANT WANT WANT drop drop drop
Your expression
datum >>= 6;
datum &= 7;
?? b0 b1
?? 128 64
zero drop drop
Suggested expression
datum >>= 3;
datum &= 7;
b2 b3 b4
32 16 8
WANT WANT WANT
> + else
> + datum >>= *source_offset_bits;
> + datum &= mask;
> + nbits -= avail;
NBITS is updated but its value is then never used anywhere later.
> + *source_offset_bits += avail;
> + if (*source_offset_bits >= 8)
> + {
> + *source_offset_bits -= 8;
> + ++*source;
> + }
> +
> + *result = datum;
> + return avail;
> +}
> +
> +/* Extract some bits from a source buffer and move forward in the
> + buffer.
> +
> + SOURCE is the source buffer. It is updated as bytes are read.
> + SOURCE_OFFSET_BITS is the offset into SOURCE. It is updated as
> + bits are read.
> + NBITS is the number of bits to read.
> + BITS_BIG_ENDIAN is taken directly from gdbarch.
> +
> + This function returns the bits that were read. */
> +
> +static unsigned int
> +extract_bits (const gdb_byte **source, unsigned int *source_offset_bits,
> + int nbits, int bits_big_endian)
> +{
> + unsigned int datum, bits_read;
> +
> + bits_read = extract_bits_primitive (source, source_offset_bits, nbits,
> + bits_big_endian, &datum);
> + if (bits_read < nbits)
> + {
> + unsigned int more;
Missing declarations empty line separator.
> + nbits -= bits_read;
> + if (bits_big_endian)
> + datum <<= nbits;
> + extract_bits_primitive (source, source_offset_bits, nbits,
> + bits_big_endian, &more);
> + datum |= more;
For (bits_big_endian == 0) MORE needs to be <<= NBITS.
extract_bits_primitive() always returns RESULT fit in the lowest-order bits.
Two |= without any << have to mangle both RESULTs each over the other.
> + }
> +
> + return datum;
> +}
If this function is passed NBITS >= 17 it does not assert-fail and it returns
only incomplete 9..16 bits of it. Should there be some
while (bits_read < nbits)
(and associated adjustments) instead?
And this function needs to distinguish both the bits endianity and the bytes
endianity. Out of big-byte-endian machines there are both big-bits-endian and
little-bits-endian ones:
http://en.wikipedia.org/wiki/Bit_numbering#Usage
OTOH there is currently no GDB target using set_gdbarch_bits_big_endian,
therefore all the GDB targets are little-bits-endian. This seems to be wrong.
http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.pdf
does not contain any Figures so I rather used:
http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.7.pdf
where on Figure 3-11 it seems that:
ppc64 big-byte-endian is big-bits-endian
ppc64 little-byte-endian is also big-bits-endian - this seems weird to me.
It is the same for ppc32:
http://refspecs.freestandards.org/elf/elfspec_ppc.pdf
Figure 3-15 and Figure 3-16
> +
> +/* Write some bits into a buffer and move forward in the buffer.
> +
> + DATUM is the bits to write. The low-order bits of DATUM are used.
> + DEST is the destination buffer. It is updated as bytes are
> + written.
> + DEST_OFFSET_BITS is the bit offset in DEST at which writing is
> + done.
> + NBITS is the number of valid bits in DATUM.
> + BITS_BIG_ENDIAN is taken directly from gdbarch. */
> +
> +static void
> +insert_bits (unsigned int datum,
> + gdb_byte *dest, unsigned int dest_offset_bits,
> + int nbits, int bits_big_endian)
> +{
> + unsigned int mask;
> +
> + gdb_assert (dest_offset_bits > 0 && dest_offset_bits < 8);
I would rather see for the ">" part:
gdb_assert (dest_offset_bits >= 0);
as for dest_offset_bits = 0, source_offset_bits != 0 satisfying
> + if (dest_offset_bits % 8 != 0 || source_offset_bits % 8 != 0)
it can IMO happen, and in general this function can support it.
Also if the bits and bytes variants of code would be merged we would need it.
and for the "<" part:
gdb_assert (dest_offset_bits + nbits <= 8);
as this function handles only write to single byte.
> +
> + mask = (1 << nbits) - 1;
> + if (bits_big_endian)
> + {
> + datum <<= 8 - dest_offset_bits;
> + mask <<= 8 - dest_offset_bits;
Again I would rather see:
datum <<= 8 - (dest_offset_bits + nbits);
mask <<= 8 - (dest_offset_bits + nbits);
For:
bits_big_endian = 1
dest_offset_bits = 1
nbits = 3
mask = 7
b0 b1 b2 b3 b4 b5 b6 b7 = big endian bits numbering
128 64 32 16 8 4 2 1 = value represented by this bit
0 0 0 0 0 1 1 1
former expression:
mask <<= 7
mask = 128
1 0 0 0 0 0 0 0
suggested expression:
mask <= 4
0 1 1 1 0 0 0 0
> + }
> + else
> + {
> + datum <<= dest_offset_bits;
> + mask <<= dest_offset_bits;
> + }
> +
> + gdb_assert ((datum & ~mask) == 0);
> +
> + *dest = (*dest & ~mask) | datum;
> +}
> +static void
> +copy_bitwise (gdb_byte *dest, unsigned int dest_offset_bits,
> + const gdb_byte *source, unsigned int source_offset_bits,
> + unsigned int bit_count,
> + int bits_big_endian)
Seems OK to me.
> read_pieced_value (struct value *v)
+
> @@ -402,11 +627,16 @@ write_pieced_value (struct value *to, struct value *from)
Not reviewed, the patches no longer apply to HEAD and also this part may or
may not be changed a lot depending on the discussions above.
Thanks,
Jan
next prev parent reply other threads:[~2010-05-20 21:01 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-18 23:43 Tom Tromey
2010-05-19 14:16 ` Stan Shebs
2010-05-19 23:35 ` Tom Tromey
2010-05-20 3:29 ` Stan Shebs
2010-05-20 5:10 ` Tom Tromey
2010-05-20 7:12 ` Tom Tromey
2010-05-26 22:41 ` Tom Tromey
2010-06-03 20:12 ` RFA: rewrite dwarf->ax translator (Was: RFC: implement DW_OP_bit_piece) Tom Tromey
2010-06-08 20:45 ` RFA: rewrite dwarf->ax translator Tom Tromey
2010-06-11 15:20 ` Tom Tromey
2010-06-08 20:52 ` RFA: rewrite dwarf->ax translator (Was: RFC: implement DW_OP_bit_piece) Pedro Alves
2010-06-08 21:21 ` RFA: rewrite dwarf->ax translator Tom Tromey
2010-06-08 22:48 ` Tom Tromey
2010-06-09 14:04 ` Pedro Alves
2010-07-01 12:43 ` collecting optimized out variables regression (Re: RFA: rewrite dwarf->ax translator (Was: RFC: implement DW_OP_bit_piece)) Pedro Alves
2010-07-01 15:25 ` collecting optimized out variables regression (Re: RFA: rewrite dwarf->ax translator Tom Tromey
2010-07-01 15:57 ` Pedro Alves
2010-07-01 15:34 ` collecting optimized out variables regression (Re: RFA: rewrite dwarf->ax translator (Was: RFC: implement DW_OP_bit_piece)) Jan Kratochvil
2010-05-20 19:53 ` RFC: implement DW_OP_bit_piece Tom Tromey
2010-05-20 20:30 ` Jan Kratochvil
2010-05-21 20:16 ` Tom Tromey
2010-05-21 21:16 ` Stan Shebs
2010-05-21 21:18 ` Tom Tromey
2010-05-25 19:22 ` RFC: DWARF expression disassembly (Was: RFC: implement DW_OP_bit_piece) Tom Tromey
2010-05-25 19:27 ` Jan Kratochvil
2010-05-25 20:25 ` RFC: DWARF expression disassembly Tom Tromey
2010-05-25 20:52 ` Jan Kratochvil
2010-05-25 22:03 ` Tom Tromey
2010-05-26 17:21 ` Eli Zaretskii
2010-06-01 18:36 ` Tom Tromey
2010-06-01 18:40 ` Eli Zaretskii
2010-06-02 19:32 ` Tom Tromey
2010-05-20 21:07 ` Jan Kratochvil [this message]
2010-05-21 17:57 ` RFC: implement DW_OP_bit_piece Tom Tromey
2010-05-25 18:19 ` performance talk [Re: RFC: implement DW_OP_bit_piece] Jan Kratochvil
2010-05-25 22:23 ` Tom Tromey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100520210135.GA31238@host0.dyn.jankratochvil.net \
--to=jan.kratochvil@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=tromey@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox