Re: [rfc] Detect dwarf address size mismatch

[Daniel Jacobowitz <drow@false.org>]

On Tue, Jul 17, 2007 at 03:01:04PM +0200, Mark Kettenis wrote:
> 
> > @@ -6792,6 +6793,15 @@ dwarf_decode_lines (struct line_header *
> >  			     _("mangled .debug_line section"));
> >  		  return;
> >  		}
> > +	      /* Make sure that we parsed the extended op correctly.  If e.g.
> > +		 we expected a different address size than the producer used,
> > +		 we may have read the wrong number of bytes.  */
> > +	      if (line_ptr != extended_end)
> > +		{
> > +		  complaint (&symfile_complaints,
> > +			     _("mangled .debug_line section"));
> > +		  return;
> > +		}
> >  	      break;
> >  	    case DW_LNS_copy:
> >  	      if (lh->num_file_names < file)
> 
> The complaint "mangled .debug_line section" seems a bit unhelpful to
> me, especially since there are now two identical messages for what
> appears to be somewhat different conditions.  Any chance of changing
> it something more distinguishable?

It was my mistake, not yours, that you didn't notice it before.  It
used to say "bad address size", but Jim suggested I check all extended
ops instead of just DW_LNE_set_address.  So the more specific complaint
is no longer accurate.

How about changing the first one to "unrecognized extended opcode in
.debug_line", and the second one to "mangled extended opcode in
.debug_line"?

I thought about making the unrecognized opcode case more lenient, and
using break instead of return, since we can advance line_ptr the right
amount.  But I think we can't skip unrecognized line opcodes the way
we can skip unrecognized attributes; if the opcode changes the PC,
then the next advance_pc opcode will start from the wrong place, et cetera.

-- 
Daniel Jacobowitz
CodeSourcery