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: binutils at sources dot redhat dot com
- Date: Fri, 3 Jan 2003 10:30:48 -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> <20030103060814.GA10818@nevyn.them.org> <jey96270wj.fsf@sykes.suse.de>
On Fri, Jan 03, 2003 at 03:39:40PM +0100, Andreas Schwab wrote:
> Daniel Jacobowitz <drow@mvista.com> writes:
>
> |> No regressions, but some pertinent facts:
> |>
> |> - Examine the ld.log with this patch applied. Grep for BFD. You'll
> |> find several assertion failures indicating that the DWARF-2 data
> |> is incorrect. It's kind of sad that the testsuite doesn't notice any
> |> of these.
>
> I have now tried it on ia64, and it is getting worse. They are using
> R_IA64_SECREL32LS relocations in .debug_info, which is causing
> bfd_perform_relocation to return bfd_reloc_outofrange, and
> bfd_generic_get_relocated_section_contents is aborting on that.
Hmm. This suggests that we need to save/restore output offsets, but
that's just a guess. Is that reproducible with cross tools? I don't
have an ia64 here.
> |> I'm OK with this if you'll add back code to hangle a NULL symbol table
> |> argument.
>
> I'll do that.
>
> |> That's more useful for GDB's purposes, and maybe readelf's.
>
> readelf does not use BFD at all, so it would have to reinvent the wheel
> anyway.
Blech, you're right; it uses "bfd.h" but not -lbfd...
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer