This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: _bfd_dwarf2_find_nearest_line returns wrong filename
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Andreas Schwab <schwab at suse dot de>
- Cc: binutils at sources dot redhat dot com
- Date: Wed, 1 Jan 2003 14:37:22 -0500
- Subject: Re: _bfd_dwarf2_find_nearest_line returns wrong filename
- References: <m3smwoe46q.fsf@whitebox.local> <m3lm27rbpl.fsf@north-pole.nickc.cambridge.redhat.com> <m3r8bzp0s8.fsf@whitebox.local> <20021230231439.GA16750@nevyn.them.org> <20021230231641.GA16906@nevyn.them.org> <m3isx8aehk.fsf@whitebox.local>
On Wed, Jan 01, 2003 at 07:53:27PM +0100, Andreas Schwab wrote:
> Daniel Jacobowitz <drow@false.org> writes:
>
> > It seems that the easiest way to avoid all this hassle would be to fix
> > bfd_simple_get_relocated_section_contents to work while linking. This
> > was one of the uses it's intended for, I just hadn't figured out how to
> > make it work yet. Probably you can solve most of the problem by saving
> > and restoring the section output offsets, output sections, and
> > reloc_done value within that function.
>
> Do you have a testcase where this does not work? The patch below is
> tested on ppc-linux (native) and m68k-linux (cross), I haven't noticed
> something wrong yet, apart from a problem with the symbol table which
> I have solved by passing it down to
> bfd_simple_get_relocated_section_contents.
>
> Andreas.
Well, I don't like it as-is; at the least I'd want simple to handle
symbol_table == NULL. I'm also worried about the clobbering of
reloc_done, and the fact that the link_info passed to
bfd_get_relocated_section_contents will have an empty hash table
instead of a populated one, since you don't add symbols to it.
Let me investigate this afternoon and see what I can figure out. These
might not be real problems; if they are I should make them into
testcases :)
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer