Re: Bitfields

[Doug Evans <dje at google dot com>]

On Thu, Jan 7, 2010 at 11:33 PM, Leutwein Tobias (BEG-PG/EES)
<Tobias.Leutwein@de.bosch.com> wrote:
> Hello,
>
> I wrote a program that uses the gdb to get the address and type of global values. I use the gdb therefore because so I mustn't care about the debug format. This works quiet well, accept for single bits and bitfields. Single bits aren't standard at C/C++, so I tried to solve the issue with bitfields first.
>
> If I want to determine the address an type from the global values
> flags.uc and flags.s9 from the program build from ./gdb/testsuite/gdb.base/bitfields.c.
>
> gcc -g ./gdb/testsuite/gdb.base/bitfields.c -o ./zzz
> gdb zzz
>
> First I check if the variable flags exists through
> (gdb) ptype flags
> type = struct fields {
> ? ?unsigned char uc;
> ? ?int s1 : 1;
> ? ?unsigned int u1 : 1;
> ? ?int s2 : 2;
> ? ?unsigned int u2 : 2;
> ? ?int s3 : 3;
> ? ?unsigned int u3 : 3;
> ? ?int s9 : 9;
> ? ?unsigned int u9 : 9;
> ? ?signed char sc;
> }
>
> Next determine the type of flags.uc
> (gdb) ptype flags.uc
> type = unsigned char
>
> Then the address of the value
> (gdb) interpreter-exec mi2 "-data-evaluate-expression &flags.uc"
> ^done,value="0x402040 \"\""
>
> The same for flags.s9:
> (gdb) ptype flags.s9
> type = int
> -> No difference to a normal integer value. Also
> (gdb) interpreter-exec mi2 "-data-evaluate-expression &flags.s9"
> ^done,value="0x402042"
> shows no difference to a normal value.
>
>
> At attachment ptype.diff is a source code patch for gdb7.0.1, which shows the bitpos and bitsize of values if they are not equal to 0. This patch changes only the behaviour at c/c++ language.
>
> tar -xf gdb-7.0.1.tar.bz2
> cd gdb-7.0.1
> patch -u ?-i ../gdb.diff -p1
> ./configure
> make
>
> gcc -g ./gdb/testsuite/gdb.base/bitfields.c -o ./zzz
>
> gdb/gdb zzz
>
> (gdb) ptype flags
> type = struct fields {
> ? ?unsigned char uc;
> ? ?int s1 : 1;
> ? ?unsigned int u1 : 1;
> ? ?int s2 : 2;
> ? ?unsigned int u2 : 2;
> ? ?int s3 : 3;
> ? ?unsigned int u3 : 3;
> ? ?int s9 : 9;
> ? ?unsigned int u9 : 9;
> ? ?signed char sc;
> }
>
> (gdb) ptype flags.s9
> type = int, bitpos = 20, bitsize = 9
> (gdb) interpreter-exec mi2 "-data-evaluate-expression &flags.s9"
> ^done,value="0x402040"
>
> (gdb) ptype flags.u9
> type = unsigned int, bitsize = 9
> (gdb) interpreter-exec mi2 "-data-evaluate-expression &flags.u9"
> ^done,value="0x402044"
>
> (gdb) ptype flags.uc
> type = unsigned char
> (gdb) interpreter-exec mi2 "-data-evaluate-expression &flags.uc"
> ^done,value="0x402040 \"\""
>
>
> I use the ptype command, because I didn't find a gdb/mi command through which I can get such informative results.
>
> Would it be possible to extend the ptype command like I did?
> Would it be better to make a new command?
> Or is there a other way to get this information's.

Hi.
I've wanted to extend ptype like this myself - it'll be useful for
flags registers if/when TYPE_CODE_FLAGS goes away (an internal-use
type for representing h/w registers that contain flags, like eflags on
x86).  I can never remember which bits of a h/w flag register
represent which fields.

One issue is that there's one school of thought that says that for h/w
registers "bitpos" must be printed according to the architecture's
specification: some architectures number the most significant bit as
bit 0, others number the least significant bit as bit 0.  When used in
the context of printing h/w register bits, I do think gdb's output
should match ISA docs.
But imposing such numbering schemes on the user for structs in general
would be bad I think.
I guess we could add a flag to TYPE_CODE_STRUCT that says whether to
print bitpos according to the ISA or not.

On a different topic,
Having to do "ptype flags.member" in order to get the offset and size
printed (as opposed to doing it some other way, e.g. with a new
command or with a new option to ptype to include the info when
printing the entire struct) seems as reasonable as any I guess.

I realize the submitted patch is just an experiment.
If you want to submit a patch for formal review you'll need to remove
all the whitespace fixes (do them in a separate patch), and remove the
debugging prints.