Re: stop bogus dwarf killing objdump

[Nathan Sidwell <nathan at codesourcery dot com>]

Nick Clifton wrote:
> Hi Nathan,
>
> > I had the misfortune to have an executable with bogus dwarf information. 
>
> Just to check - how did readelf cope with this corrupt binary ?

readelf didn't complain about an unknown dwarf type, but did complain about an 
unfindable abbrev region.  It also didn't blow up.  The test case was *huge* 
with about 1GB of debug_info section. it was a pain to investigate :)


> > !   while (stash->info_ptr != stash->info_ptr_end)
> >       {
> >         bfd_vma length;
> >         unsigned int offset_size = addr_size;
>
> I do not like this change.  A corrupt value in the length field of a 
> comp unit could cause stash->info_ptr to be set beyond 
> stash->info_ptr_end which could lead to all kinds of problems.  Besides 
> it is not needed because...

ok.  I was wondering about systems with signed pointers and straddling the bit31 
boundary, but I'm probably just being paranoid.

> >         each = parse_comp_unit (stash, length, info_ptr_unit,
> >                     offset_size);
> > +       if (!each)
> > +         {
> > +           /* The dwarf information is damaged, don't trust it any
> > +          more.  */
> > +           stash->info_ptr = stash->info_ptr_end;
> > +           break;
> > +         }
>
> The break here will exit the while loop without ever testing 
> stash->info_ptr (and so setting it to stash->info_ptr_end is redundant).

I was considering the _next_ call.  Adjusting info_ptr avoids us repeatedly 
trying to decode the bogus comp_unit.  But it's a minor point.

> Please could you modify your patch to just check the return value from 
> parse_comp_unit and break the loop if it is NULL ?

ok, I'll check in a patch with the changes you suggest.

nathan

--
Nathan Sidwell    ::   http://www.codesourcery.com   ::         CodeSourcery