This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: gdb-5.2-dwarfread_patch
- From: Elena Zannoni <ezannoni at redhat dot com>
- To: "WARREN, Stuart (Gillingham)" <Stuart dot WARREN at dds dot delphiauto dot com>
- Cc: "'gdb-patches at sources dot redhat dot com'" <gdb-patches at sources dot redhat dot com>
- Date: Mon, 29 Jul 2002 17:04:32 -0400
- Subject: Re: gdb-5.2-dwarfread_patch
- References: <69FD86957824D511978B00508BCA15749217A2@gillinx2.gill.uk.delphiauto.com>
WARREN, Stuart (Gillingham) writes:
> Hi,
>
> I've fixed a bug in dwarfread.c that made it incompatible with the diab
> compiler. It concerns the way GDB deals with TAG_typedefs. This is my first
> submission to gdb, so please excuse me if there's information missing...
> Sorry the patch isn't against what's in cvs, but it seems like dwarfread.c
> hasn't changed for a while, so I'm hoping it applies okay.
>
Hi, Usually, in order to contribute a patch to GDB one should have an
assignment on file with the FSF. See:
http://sources.redhat.com/gdb/contribute/
Would you be willing to do that?
However, a few things I noticed first off. The ChangeLog entry should
have complete sentences, starting with a capitalized word and ending
with a period. In the patch, you should follow the GNU coding
conventions, (leaving one space before '(' for instance). Indentation
should be consistent with the rest of the file too.
Also, have you tried (or have plans) to use dwarf2, instead of
dwarf1? Dwarf2 is much more complete and powerful.
Anyway, I don't understand your examples. In the gcc example the
structures have a typedef, while in the diab code, they don't. What
debug info does gcc produce in case you compile the same code as the
main.c you sent?
If you can it is usually better to include the diffs and examples as
text, in your mail, since it's easier to read.
I include here main.c:
typedef unsigned short U16;
typedef signed short S16;
#define U16_CAL volatile const U16
#define S16_CAL volatile const S16
struct F_M_FAULT_RECORD_TYPE {
S16 flags;
U16 stuflags;
S16 counter;
S16 stu;
} F_M_FAULT_RECORD_TYPE;
struct F_M_FAULT_RECORD_APV_TYPE {
struct F_M_FAULT_RECORD_TYPE * fault_record;
S16_CAL increment;
S16_CAL decrement;
S16_CAL bucket_depth;
S16_CAL latch;
U16_CAL main_fault_code;
} F_M_FAULT_RECORD_APV_TYPE;
struct F_M_FAULT_RECORD_TYPE fm;
struct F_M_FAULT_RECORD_APV_TYPE fma;
int main()
{
fma.fault_record = &fm;
fma.fault_record->flags = 0xaaaa;
return 0;
}
Elena
> Thanks
> Stuart
>
> Bug description:
> dwarfread does not fill in user types for typedefs. This isn't a problem
> when using gcc because the it generates at_user_def_types that point
> directly to the data structure type. Other compilers generate dwarf
> information that point to typedefs that then point to structures. For
> example, given the structure declarations:
>
> typedef struct{
> S16 flags;
> U16 stuflags;
> S16 counter;
> S16 stu;
> } F_M_FAULT_RECORD_TYPE;
>
> typedef struct{
> F_M_FAULT_RECORD_TYPE * fault_record;
> S16_CAL increment;
> S16_CAL decrement;
> S16_CAL bucket_depth;
> S16_CAL latch;
> U16_CAL main_fault_code;
> } F_M_FAULT_RECORD_APV_TYPE;
>
>
> gcc generates the following dwarf information:
>
> 000000C1: TAG_structure_type
> | AT_sibling ref(0x0000017A)
> | AT_byte_size 8
> 000000D3: TAG_member
> | AT_sibling ref(0x000000FB)
> | AT_name "flags"
> | AT_member ref(0x000000C1)
> | AT_fund_type FT_short
> | AT_location <6> OP_CONST(0) OP_ADD
> 000000FB: TAG_member
> | AT_sibling ref(0x00000126)
> | AT_name "stuflags"
> | AT_member ref(0x000000C1)
> | AT_fund_type FT_unsigned_short
> | AT_location <6> OP_CONST(2) OP_ADD
> 00000126: TAG_member
> | AT_sibling ref(0x00000150)
> | AT_name "counter"
> | AT_member ref(0x000000C1)
> | AT_fund_type FT_short
> | AT_location <6> OP_CONST(4) OP_ADD
> 00000150: TAG_member
> | AT_sibling ref(0x00000176)
> | AT_name "stu"
> | AT_member ref(0x000000C1)
> | AT_fund_type FT_short
> | AT_location <6> OP_CONST(6) OP_ADD
> 00000176: null entry
> 0000017A: TAG_typedef
> | AT_sibling ref(0x000001A4)
> | AT_name "F_M_FAULT_RECORD_TYPE"
> | AT_user_def_type ref(0x000000C1)
> 000001A4: TAG_structure_type
> | AT_sibling ref(0x000002E3)
> | AT_byte_size 16
> 000001B6: TAG_member
> | AT_sibling ref(0x000001EA)
> | AT_name "fault_record"
> | AT_member ref(0x000001A4)
> | AT_mod_u_d_type MOD_pointer_to ref(0x000000C1)
> | AT_location <6> OP_CONST(0) OP_ADD
> 000001EA: TAG_member
> | AT_sibling ref(0x0000021A)
> | AT_name "increment"
> | AT_member ref(0x000001A4)
> | AT_mod_fund_type MOD_const MOD_volatile FT_short
> | AT_location <6> OP_CONST(4) OP_ADD
> 0000021A: TAG_member
> | AT_sibling ref(0x0000024A)
> | AT_name "decrement"
> | AT_member ref(0x000001A4)
> | AT_mod_fund_type MOD_const MOD_volatile FT_short
> | AT_location <6> OP_CONST(6) OP_ADD
> 0000024A: TAG_member
> | AT_sibling ref(0x0000027D)
> | AT_name "bucket_depth"
> | AT_member ref(0x000001A4)
> | AT_mod_fund_type MOD_const MOD_volatile FT_short
> | AT_location <6> OP_CONST(8) OP_ADD
> 0000027D: TAG_member
> | AT_sibling ref(0x000002A9)
> | AT_name "latch"
> | AT_member ref(0x000001A4)
> | AT_mod_fund_type MOD_const MOD_volatile FT_short
> | AT_location <6> OP_CONST(10) OP_ADD
> 000002A9: TAG_member
> | AT_sibling ref(0x000002DF)
> | AT_name "main_fault_code"
> | AT_member ref(0x000001A4)
> | AT_mod_fund_type MOD_const MOD_volatile FT_unsigned_short
> | AT_location <6> OP_CONST(12) OP_ADD
> 000002DF: null entry
> 000002E3: TAG_typedef
> | AT_sibling ref(0x00000311)
> | AT_name "F_M_FAULT_RECORD_APV_TYPE"
> | AT_user_def_type ref(0x000001A4)
>
> Note that die 01b6 has a mod_u_d_type to 00c1, which is the structure
> declaration. Other compilers such as diab, generate the dwarf information
> differently (see attached diabgdb.dmp), instead using a mod_u_d_type to
> point to the typedef. GDB doesn't fill out the user types allocated to
> typedefs, meaning that gdb will report an uncomplete type if mod_u_d_types
> point to typedefs. This is illustrated in the attached elf file by doing a
> 'ptype F_M_FAULT_RECORD_APV_TYPE'. The unpatched version gives:
>
> (gdb) ptype F_M_FAULT_RECORD_APV_TYPE
> type = struct {
> struct <unknown> *fault_record;
> short increment;
> short decrement;
> short bucket_depth;
> short latch;
> struct <unknown> main_fault_code;
> }
>
> The attached patch adds processing of typedefs, fixing the problem,
> producing:
>
> (gdb) ptype F_M_FAULT_RECORD_APV_TYPE
> During symbol reading, DIE @ 0x14e "increment", type modifier 'volatile'
> ignored.
> During symbol reading, DIE @ 0x14e "increment", type modifier 'const'
> ignored.
> type = struct {
> struct {
> short flags;
> unsigned short stuflags;
> short counter;
> short stu;
> } *fault_record;
> short increment;
> short decrement;
> short bucket_depth;
> short latch;
> unsigned short main_fault_code;
> }
>
>
> 2002-07-25 Stuart Warren <stuart@rachandstu.com>
>
> * dwarfread.c
> (read_tag_typedef): new function.
> (process_dies): typedefs processed by read_tag_typedef
>
>
> <<gdb-5.2-dwarfread_patch>>
> <<main.c>> <<diabgdb.elf>> <<diabgdb.dmp>>