This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] Re: Advice on fixing gdb/12528
On Tue, 15 Mar 2011 22:45:02 +0100, Paul Pluzhnikov wrote:
> On Tue, Mar 15, 2011 at 2:24 PM, Jan Kratochvil <jan.kratochvil@redhat.com> wrote:
> > Â Â Â Â Â Â Â Â Â Â Âcomplaint (&symfile_complaints,
> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â _(".debug_line offset 0x%lx uses address 0 "
> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â "[in module %s]"),
> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â (long) (line_ptr
> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â - dwarf2_per_objfile->line.buffer),
> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â cu->objfile->name);
> >
> > (the offset is not right but better than nothing)
>
> Maybe like this:
>
> if (address == 0 && !dwarf2_per_objfile->has_section_at_zero)
> {
> /* This line table is for a function which has been
> GCd by the linker. Ignore it. PR gdb/12528 */
>
> long line_offset
> = line_ptr - bytes_read - dwarf2_per_objfile->line.buffer;
>
> complaint (&symfile_complaints,
> _(".debug_line offset 0x%lx uses address 0 "
> "[in module %s]"),
> line_offset, cu->objfile->name);
> p_record_line = noop_record_line;
> }
BYTES_READ is here just for the ADDRESS size. One can also subtract 1 for
EXTENDED_OP read in, subtract already overwritten BYTES_READ for EXTENDED_LEN
read in and subtract 1 for OP_CODE read in. This way we get the offset where
this operation starts.
But neither binutils nor elfutils readelf display offsets of the .debug_line
operations so one cannot debug the resulting offset so much which is why
I thought some approx. offset is good enough.
I do not think the displayed offset is so importatnt but at least the module
gets shown.
Thanks,
Jan