Re: [PATCH] Debug info read problem

[Daniel Jacobowitz <drow@false.org>]

On Thu, Mar 12, 2009 at 02:25:35PM +0000, Andrew Stubbs wrote:
> I have been investigating a problem in which I see this message, in  
> addition to "undefined reference to" messages:
>
>> arm-none-eabi-ld: Dwarf Error: Offset (273) greater than or equal to .debug_str size (268).
>
> The problem is that it mis-reads the size of the .debug_str section. This 
> leads to valid offsets appearing out-of-range.
>
> Debugging shows that the section "rawsize" field contains the correct  
> size, but the code prefers the "size" field, which does not.
>
> It's not entirely clear to me why there would be two different sizes for  
> this section - the comments on the fields talk about relaxation and such, 
> but I don't understand how this related to debug info. It does say that, 
> if set, the field contains the original size of the input section on disk. 
> This would appear to be the right thing, in this case.
>
> The attached patch fixes the problem for the test case, but I don't if  
> I'm fixing the symptom, or the root cause.
>
> Note that this code is usually only called for building diagnostic  
> messages from debug info.
>
> OK?

I took a look at bfd_simple_get_relocated_section_contents, which is
providing the buffer.  If the section does not have relocations, it
uses rawsize if set and otherwise size.  If it does have relocations,
it uses just sec->size.  So this patch could lead to us allocating
and relocating only size, but returning rawsize as the buffer size.
This doesn't happen in practice only because .debug_str won't contain
relocated contents.

The description of rawsize does apply - this is an input section with
SEC_MERGE set.  I suspect size is how much this section contributes to
the final executable after discarding duplicate strings.

I chased up a few implementations of
bfd_get_relocated_section_contents, which is how the buffer is filled
in for sections with the SEC_RELOC flag.  It uses rawsize if set too.
So I think your patch is right, but simple.c needs an equivalent fix.

-- 
Daniel Jacobowitz
CodeSourcery