Re: [patch]: Remove current_gdbarch from target.c

Ulrich Weigand
2008-05-20T16:43:03Z

Daniel Jacobowitz wrote:
> On Tue, May 20, 2008 at 05:16:24PM +0200, Ulrich Weigand wrote:
> > Markus Deuling wrote:
> >
> >
> > > * target.c (target_translate_tls_address): Replace current_gdbarch by
> > > objfile arch.
> >
> > This is OK.
>
> Is it really? What are the guarantees for the objfile architecture?

Well, the general idea is that objfile archiecture can / should be
used for properties that depend solely on the objfile, and not on
properties of a running target. This currently includes mostly
things like builtin types and basic ABI properties, but also e.g.
convert_from_func_ptr_addr.

I would have considered fetch_tls_load_module_address to be of
the same type. But on second thought, that may not really be true
-- the svr4_fetch_objfile_link_map implementation of it does hook
into the overall shared library code, which is dependent on the
target ...

Markus, please do not apply this patch for now; we'll need to
think of another solution (probably together with the question
what gdbarch the shared library subsystem should be using).

> If an object is not sniffed as belonging to a particular os/abi, I
> believe we won't get its tls address routine now, even when connected
> to a target reporting the appropriate OS/ABI some other way or using
> set arch.

That would be true.

> This is not a big deal for Linux, since every linked object is
> generally sniffable. But I've been working with two other OS's
> recently where our dependence on sniffers is a problem; neither
> Symbian OS nor DICOS has clear markings.

Hmm. Non-sniffable objects are somewhat of a problem anyway.
Maybe we need a way to at least override (manually?) the OSABI
that is used for non-sniffable objects ...

Bye,
Ulrich

--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com

--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com