Crash triggered by DWARF debug info: Any ideas ?

Crash triggered by DWARF debug info: Any ideas ?

[Kai Schuetz]

Hi,

I'm looking into some crash in gdb 7.5.1 in the DWARF reader.
The DWARF (v3) debug info in the case is pretty basic (it was generated by the "ARM Assembler", version 4.0).
The .debug_info section just consists of a single debug info entry for each compilation unit, consisting of name, producer, comp_dir, low_pc, high_pc and stmt_list. The .debug_line section contains line statements for the compilation units.

When symbol loading is triggered in gdb it crashes inside of record_block_range due to "block" being 0.
This is due to end_symtab_get_static_block() returning 0 when called in process_full_comp_unit().
Highpc and lowpc look reasonable at this point.

(I also tried skipping the call of dwarf2_record_block_ranges() if "static_block" is 0, however this lead to lots of warnings about psymtabs and symtabs being inconsistent (warning: (Internal error: pc 0x178 in read in psymtab, but not in symtab.)), and the source line mapping not working).

Any idea what to hunt for ?

Thanks,
Kai

Re: Crash triggered by DWARF debug info: Any ideas ?

[Tom Tromey]

>>>>> "Kai" == Kai Schuetz <Kai.Schuetz@synopsys.com> writes:

Kai> I'm looking into some crash in gdb 7.5.1 in the DWARF reader.
Kai> The DWARF (v3) debug info in the case is pretty basic (it was
Kai> generated by the "ARM Assembler", version 4.0).
Kai> The .debug_info section just consists of a single debug info entry for
Kai> each compilation unit, consisting of name, producer, comp_dir, low_pc,
Kai> high_pc and stmt_list. The .debug_line section contains line
Kai> statements for the compilation units.
[...]
Kai> Any idea what to hunt for ?

I don't think there's an easy way to debug it.  Offhand I don't know
what is wrong.  You might try having end_symtab_get_static_block always
return a block.  It's easier to do this with a newer gdb, this area
changed a bit.

Tom

RE: Crash triggered by DWARF debug info: Any ideas ?

[Kai Schuetz]

Hi Tom,

> -----Original Message-----
> From: Tom Tromey [mailto:tromey@redhat.com]
> Sent: Tuesday, February 12, 2013 20:25
> To: Kai Schuetz
> Cc: gdb@sourceware.org
> Subject: Re: Crash triggered by DWARF debug info: Any ideas ?
> 
> >>>>> "Kai" == Kai Schuetz <Kai.Schuetz@synopsys.com> writes:
> 
> Kai> I'm looking into some crash in gdb 7.5.1 in the DWARF reader.
> Kai> The DWARF (v3) debug info in the case is pretty basic (it was
> Kai> generated by the "ARM Assembler", version 4.0).
> Kai> The .debug_info section just consists of a single debug info entry
> Kai> for each compilation unit, consisting of name, producer, comp_dir,
> Kai> low_pc, high_pc and stmt_list. The .debug_line section contains
> Kai> line statements for the compilation units.
> [...]
> Kai> Any idea what to hunt for ?
> 
> I don't think there's an easy way to debug it.  Offhand I don't know what is
> wrong.  You might try having end_symtab_get_static_block always return a
> block.  It's easier to do this with a newer gdb, this area changed a bit.

What is the relation of DWARF info and (static?) blocks ?
I assume there should be one static block per compilation unit ?

With "newer gdb" I assume you refer to one checked out CVS since 7.5.1 is the latest release ?

Thanks,
Kai

Re: Crash triggered by DWARF debug info: Any ideas ?

[Tom Tromey]

>>>>> "Kai" == Kai Schuetz <Kai.Schuetz@synopsys.com> writes:

Kai> What is the relation of DWARF info and (static?) blocks ?
Kai> I assume there should be one static block per compilation unit ?

Yeah.  There is a comment in block.h that explains it.
Basically each CU has a global block and a static block,
and then various sub-blocks representing scopes in the program.

Kai> With "newer gdb" I assume you refer to one checked out CVS since 7.5.1
Kai> is the latest release ?

Yes, or git.

Tom