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

["Ulrich Weigand" <uweigand@de.ibm.com>]

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