[patch]: Remove current_gdbarch from target.c

[patch]: Remove current_gdbarch from target.c

[Markus Deuling]

[-- Attachment #1: Type: text/plain, Size: 326 bytes --]

Hi,

this patch removes the last occurence of current_gdbarch from target.c Tested on x86_64 without
regression.

Ok to commit?


ChangeLog:

	* target.c (target_translate_tls_address): Replace current_gdbarch by
	objfile arch.

Regards,
Markus

-- 
  Markus Deuling
  GNU Toolchain for Linux on Cell BE
  deuling@de.ibm.com


[-- Attachment #2: diff-target --]
[-- Type: text/plain, Size: 1098 bytes --]

diff -urpN src/gdb/target.c dev/gdb/target.c
--- src/gdb/target.c	2008-05-13 13:42:06.000000000 +0200
+++ dev/gdb/target.c	2008-05-16 08:31:42.000000000 +0200
@@ -825,9 +825,10 @@ CORE_ADDR
 target_translate_tls_address (struct objfile *objfile, CORE_ADDR offset)
 {
   volatile CORE_ADDR addr = 0;
+  struct gdbarch *gdbarch = get_objfile_arch (objfile);
 
   if (target_get_thread_local_address_p ()
-      && gdbarch_fetch_tls_load_module_address_p (current_gdbarch))
+      && gdbarch_fetch_tls_load_module_address_p (gdbarch))
     {
       ptid_t ptid = inferior_ptid;
       volatile struct gdb_exception ex;
@@ -837,8 +838,7 @@ target_translate_tls_address (struct obj
 	  CORE_ADDR lm_addr;
 	  
 	  /* Fetch the load module address for this objfile.  */
-	  lm_addr = gdbarch_fetch_tls_load_module_address (current_gdbarch,
-	                                                   objfile);
+	  lm_addr = gdbarch_fetch_tls_load_module_address (gdbarch, objfile);
 	  /* If it's 0, throw the appropriate exception.  */
 	  if (lm_addr == 0)
 	    throw_error (TLS_LOAD_MODULE_NOT_FOUND_ERROR,

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

[Ulrich Weigand]

Markus Deuling wrote:


> 	* target.c (target_translate_tls_address): Replace current_gdbarch by
> 	objfile arch.

This is OK.

Thanks,
Ulrich

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

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

[Daniel Jacobowitz]

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?

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.

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.

-- 
Daniel Jacobowitz
CodeSourcery

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

[Ulrich Weigand]

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

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

[Daniel Jacobowitz]

On Tue, May 20, 2008 at 06:42:03PM +0200, Ulrich Weigand wrote:
> 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 ...

Yes, perhaps.  Right now we use a somewhat unsatisfactory solution:
the list of defaults in configure.tgt.

-- 
Daniel Jacobowitz
CodeSourcery