This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [rfa] Shared object matching for solib-som.c
- From: Daniel Jacobowitz <drow at false dot org>
- To: Randolph Chung <randolph at tausq dot org>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Wed, 19 Apr 2006 08:33:32 -0400
- Subject: Re: [rfa] Shared object matching for solib-som.c
- References: <44458D3D.4030506@tausq.org>
On Wed, Apr 19, 2006 at 09:07:09AM +0800, Randolph Chung wrote:
> I notice that most of the solib variants do not need to do this type of
> processing; unfortunately I haven't figured out a better way to handle
> the SOM case. Perhaps somebody more familiar with the solib code/SOM can
> comment?
No one else needs to do this, in fact. This is from the symfile
section_offsets callback; but why can't you do this in the
solib relocate_section_addresses callback instead? In fact, you
already do, so it is not at all clear to me why you need to adjust the
offsets here. Other targets only need to adjust the one copy in the
section table.
Ah, I think this normally works via
build_section_addr_info_from_section_table. Which produces the second
parameter for som_symfile_offsets. Which is now valid for shared
libraries. It's just that the way that function _uses_ it is bogus for
shared libraries. Instead of finding the .text offset you'd have to
honor the section indexes. See default_symfile_offsets.
Also the two solib-som.c functions setting offsets use different data
offsets, so beware that.
--
Daniel Jacobowitz
CodeSourcery