Date:	Sun, 25 Jul 1999 11:00:26 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: Bizarre debugging format problem
In-Reply-To:	<Pine.LNX.3.93.990722131046.1414D-101000@acp3bf>
Message-ID:	<Pine.SUN.3.91.990725105857.27488D-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Thu, 22 Jul 1999, Hans-Bernhard Broeker wrote:

> Eli: the enclosed patch fixes coff_find_nearest_line quite nicely.

Now I understand why we were talking about different things: you were
working with Binutils 2.8.1, while I was looking at the BFD library
that's part of GDB 4.18, which seems to be from Binutils 2.9.1 and
has some changes beyond that.  The bug with section-relative offsets
is already solved in stock Binutils 2.9.1 and in the version GDB uses.

FWIW, your patches to v2.8.1 don't solve all of the problem, because
"coff->symbol.value" is also relative to the section, so adjusting
offset by section->vma causes the function to look too far for the
function name that corresponds to the line number info.  Try objdump
with --line-numbers, and you will see that function names are printed
one notch too early, and with a wrong file name.  The diffs, against
your version, that correct this are below.  As I've said, the code
from Binutils 2.9.1 has this problem solved.

There's still one thing that I don't understand: for some addresses,
usually at the closing brace of a function, "objudmp --line-numbers"
prints strange symbol names like <.ef> or <.bb>.  Is this a bug, or am
I missing something?

Btw, is coff-go32 the only BFD target that only records the basename
of the source file in the COFF debug info?  It breaks "objdump --source"
when the sources are in a different directory, so I'm inclined to add a
--include option to objdump, but I wonder what other targets do.


*** bfd/coffgen.c~1	Sat Jul 24 14:01:00 1999
--- bfd/coffgen.c	Sat Jul 24 14:54:32 1999
*************** coff_find_nearest_line (abfd, section, s
*** 2202,2218 ****
      }
  #endif /* HBB 990305 exp. */
  
- #ifdef __DJGPP__ /* HBB 19990721: a kludgy try, for now */
-   offset += section->vma;
- #endif
- 
    /* Now wander though the raw linenumbers of the section */
    /* If we have been called on this section before, and the offset we
       want is further down then we can prime the lookup loop.  */
    sec_data = coff_section_data (abfd, section);
    if (sec_data != NULL
        && sec_data->i > 0
!       && offset >= sec_data->offset)
      {
        i = sec_data->i;
        *functionname_ptr = sec_data->function;
--- 2202,2214 ----
      }
  #endif /* HBB 990305 exp. */
  
    /* Now wander though the raw linenumbers of the section */
    /* If we have been called on this section before, and the offset we
       want is further down then we can prime the lookup loop.  */
    sec_data = coff_section_data (abfd, section);
    if (sec_data != NULL
        && sec_data->i > 0
!       && offset + section->vma >= sec_data->offset)
      {
        i = sec_data->i;
        *functionname_ptr = sec_data->function;
*************** coff_find_nearest_line (abfd, section, s
*** 2259,2265 ****
  	    }
  	  else
  	    {
! 	      if (l->u.offset + bfd_get_section_vma (abfd, section) > offset)
  		break;
  	      *line_ptr = l->line_number + line_base - 1;
  	    }
--- 2255,2261 ----
  	    }
  	  else
  	    {
! 	      if (l->u.offset > offset)
  		break;
  	      *line_ptr = l->line_number + line_base - 1;
  	    }
*************** coff_find_nearest_line (abfd, section, s
*** 2267,2272 ****
--- 2263,2272 ----
  	}
      }
  
+ #ifdef __DJGPP__ /* HBB 19990721: a kludgy try, for now */
+   offset += section->vma;
+ #endif
+ 
    /* Cache the results for the next call.  */
    if (sec_data == NULL && section->owner == abfd)
      {

- Raw text -