PATCH: binutils/2096: addr2line fails on linux-kernel

[Nick Clifton]

Hi H.J.

> Could someone comment on this patch
> 
> http://sourceware.org/ml/binutils/2005-12/msg00290.html

Sorry - it was in my queue, but I am behind in my replies.  Anyway:


 > 2005-12-31  H.J. Lu  <hongjiu.lu@intel.com>
 >
 >	PR binutils/2096
 >	* dwarf2.c (comp_unit_contains_address): Update comment.
 >	(_bfd_dwarf2_find_nearest_line): Return TRUE only if both
 >	comp_unit_contains_address and comp_unit_find_nearest_line
 >	return TRUE.


This patch is OK, but please could you extend the comment at the start 
of the comp_unit_contains_address() function - as I understand it the 
reason that we need to consult the line info table is that we cannot 
always trust the compilation unit header information.  In particular 
compilation units which contain hand coded assembler may be unreliable. 
  Yes ?  If so, please could you add a sentence to this effect into the 
comment ?


 > 2005-12-31  H.J. Lu  <hongjiu.lu@intel.com>
 >
 >	PR binutils/2096
 >	* dwarf2.c (_bfd_dwarf2_find_nearest_line): Use section's vma,
 >	instead of lvm for ELF.

This patch I am not so sure about.  Why would we want to use the LMA (or 
LVM) values for non-ELF formats ?  Shouldn't we always be using the VMA 
values ?  I am assuming here that the debug info is always going to 
relate to the run-time addresses of the executable, not the load-time 
addresses.  Can you think of a situation where the load-time addresses 
might be used.

Assuming that you agree with me, please could you submit a revised patch 
which changes this function over to using VMAs instead of LMAs for all 
targets, not just ELF based ones.

Cheers
   Nick