Re: [patch] Re: Advice on fixing gdb/12528

[Jan Kratochvil <jan.kratochvil@redhat.com>]

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