Re: Dwarf2-related Internal error

Michal Ludvig
2003-08-14T13:17:39Z

Elena Zannoni told me that:
> Michal Ludvig writes:
> > Hi Daniel, Elena and others,
> > this problem is still present in recent HEAD - could anyone who knows
> > the internals of symbols handling and .debug_info please help me with
> > fixing it, please? I tried to debug it myself but got quickly lost in
> > all those symbols<->types<->other_types references and couldn't find
> > where the problem originates.
> >
> > Also pointing out the right direction where to look for the bug would
> > help me a lot :-)
> >
> > BTW I also filled a PR with a very nice number 1333 for this issue.
> >
> > Thanks in advance!
> >
> > Michal Ludvig
>
> I don't have much time to devote to this, but usually that kind of
> error is generated by some infinite loop that gdb got itself into.

Unlikely. The immediate problem is that the size of function's parameter
'xx' is too big:

(top-gdb) f
#0 read_var_value (var=0x8b35c0, frame=0x85ad98)
at ../../gdb-head/gdb/findvar.c:397
397 struct type *type = SYMBOL_TYPE (var);
(top-gdb) p *var->type
$2 = {pointer_type = 0x0, reference_type = 0x0, chain = 0x89fc00,
instance_flags = 0, length = 4294967292, main_type = 0x89fc28}
(top-gdb) p (int)4294967292
$3 = -4
(top-gdb)

Very likely it was ment to be -4 because something somewhere in the
debug info was wrongly interpreted.

From what is this length computed and where? Somewhere in dwarf2read.c?

> Does the same happen for 386? Maybe comparing the two would help.

Unfortunately i386 generates completely different code and debug info
(it apparently doesn't use dwarf2 - maybe dwarf1? Sections .debug,
.lines, ...) that couldn't be reasonably compared. I wasn't able to
convince it to produce dwarf2 :-(

Thanks for the reply anyway :-)