public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
* [PATCH] Debug info read problem
@ 2009-03-12 14:25 Andrew Stubbs
  2009-03-12 16:58 ` Daniel Jacobowitz
  2009-03-16  1:15 ` Alan Modra
  0 siblings, 2 replies; 5+ messages in thread
From: Andrew Stubbs @ 2009-03-12 14:25 UTC (permalink / raw)
  To: binutils

[-- Attachment #1: Type: text/plain, Size: 1046 bytes --]

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?

Andrew

[-- Attachment #2: section-size.patch --]
[-- Type: text/x-diff, Size: 976 bytes --]

2009-03-12  Andrew Stubbs  <ams@codesourcery.com>

	bfd/
	* dwarf2.c (read_section): Always use rawsize, if available.

---
 src/binutils-mainline/bfd/dwarf2.c |    3 +--
 1 files changed, 1 insertion(+), 2 deletions(-)

Index: src/binutils-mainline/bfd/dwarf2.c
===================================================================
--- src/binutils-mainline/bfd/dwarf2.c.orig
+++ src/binutils-mainline/bfd/dwarf2.c
@@ -432,9 +432,9 @@ read_section (bfd *           abfd,
 	  return FALSE;
 	}
 
+      *section_size = msec->rawsize ? msec->rawsize : msec->size;
       if (syms)
 	{
-	  *section_size = msec->size;
 	  *section_buffer
 	      = bfd_simple_get_relocated_section_contents (abfd, msec, NULL, syms);
 	  if (! *section_buffer)
@@ -442,7 +442,6 @@ read_section (bfd *           abfd,
 	}
       else
 	{
-	  *section_size = msec->rawsize ? msec->rawsize : msec->size;
 	  *section_buffer = bfd_malloc (*section_size);
 	  if (! *section_buffer)
 	    return FALSE;

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] Debug info read problem
  2009-03-12 14:25 [PATCH] Debug info read problem Andrew Stubbs
@ 2009-03-12 16:58 ` Daniel Jacobowitz
  2009-03-16  1:04   ` Alan Modra
  2009-03-16  1:15 ` Alan Modra
  1 sibling, 1 reply; 5+ messages in thread
From: Daniel Jacobowitz @ 2009-03-12 16:58 UTC (permalink / raw)
  To: Andrew Stubbs; +Cc: binutils

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] Debug info read problem
  2009-03-12 16:58 ` Daniel Jacobowitz
@ 2009-03-16  1:04   ` Alan Modra
  0 siblings, 0 replies; 5+ messages in thread
From: Alan Modra @ 2009-03-16  1:04 UTC (permalink / raw)
  To: Andrew Stubbs, binutils

On Thu, Mar 12, 2009 at 12:57:52PM -0400, Daniel Jacobowitz wrote:
> 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.

Fixed.  Only matters of course if the target *increases* the size of a
section.  This isn't very likely with most targets that support linker
relaxation, but it is possible, eg. mmix.

	* simple.c (bfd_simple_get_relocated_section_contents): Use larger
	of rawsize and size for buffer.

Index: bfd/simple.c
===================================================================
RCS file: /cvs/src/src/bfd/simple.c,v
retrieving revision 1.30
diff -u -p -r1.30 simple.c
--- bfd/simple.c	16 Feb 2008 23:00:12 -0000	1.30
+++ bfd/simple.c	16 Mar 2009 00:38:53 -0000
@@ -210,7 +210,8 @@ bfd_simple_get_relocated_section_content
   data = NULL;
   if (outbuf == NULL)
     {
-      data = bfd_malloc (sec->size);
+      bfd_size_type amt = sec->rawsize > sec->size ? sec->rawsize : sec->size;
+      data = bfd_malloc (amt);
       if (data == NULL)
 	return NULL;
       outbuf = data;

-- 
Alan Modra
Australia Development Lab, IBM

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] Debug info read problem
  2009-03-12 14:25 [PATCH] Debug info read problem Andrew Stubbs
  2009-03-12 16:58 ` Daniel Jacobowitz
@ 2009-03-16  1:15 ` Alan Modra
  2009-03-16 12:42   ` Andrew Stubbs
  1 sibling, 1 reply; 5+ messages in thread
From: Alan Modra @ 2009-03-16  1:15 UTC (permalink / raw)
  To: Andrew Stubbs; +Cc: binutils

On Thu, Mar 12, 2009 at 02:25:35PM +0000, Andrew Stubbs wrote:
> 	* dwarf2.c (read_section): Always use rawsize, if available.

OK.

-- 
Alan Modra
Australia Development Lab, IBM

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] Debug info read problem
  2009-03-16  1:15 ` Alan Modra
@ 2009-03-16 12:42   ` Andrew Stubbs
  0 siblings, 0 replies; 5+ messages in thread
From: Andrew Stubbs @ 2009-03-16 12:42 UTC (permalink / raw)
  To: binutils

On 16/03/09 01:14, Alan Modra wrote:
> On Thu, Mar 12, 2009 at 02:25:35PM +0000, Andrew Stubbs wrote:
>> 	* dwarf2.c (read_section): Always use rawsize, if available.
>
> OK.

Thanks, committed.

Andrew

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2009-03-16 12:42 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-03-12 14:25 [PATCH] Debug info read problem Andrew Stubbs
2009-03-12 16:58 ` Daniel Jacobowitz
2009-03-16  1:04   ` Alan Modra
2009-03-16  1:15 ` Alan Modra
2009-03-16 12:42   ` Andrew Stubbs

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).