[rfc] [2/6] Replace DEPRECATED_FUNCTION_START_OFFSET

[rfc] [2/6] Replace DEPRECATED_FUNCTION_START_OFFSET

[Markus Deuling]

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

Hello,

this patch replaces DEPRECATED_FUNCTION_START_OFFSET by gdbarch_deprecated_function_start_offset. 


ChangeLog:

	* gdbarch.sh (DEPRECATED_FUNCTION_START_OFFSET): Replace by
	gdbarch_deprecated_function_start_offset.
	* symtab.c (find_function_start_sal)skip_prologue_using_sal): Likewise.
	* linespec.c (minsym_found): Likewise.
	* infrun.c (handle_inferior_event): Likewise.
	* infcall.c (find_function_addr): Likewise.
	* cli/cli-cmds.c (disassemble_command): Likewise.
	* gdbarch.c, gdbarch.h: Regenerate.

Is this ok to commit ?

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






[-- Attachment #2: diff-remove-FUNCTION_START_OFFSET --]
[-- Type: text/plain, Size: 6380 bytes --]

diff -urN src/gdb/cli/cli-cmds.c dev/gdb/cli/cli-cmds.c
--- src/gdb/cli/cli-cmds.c	2007-02-27 20:46:04.000000000 +0100
+++ dev/gdb/cli/cli-cmds.c	2007-06-18 09:43:29.000000000 +0200
@@ -925,7 +925,7 @@
 	/* FIXME: cagney/2004-02-07: This should be an observer.  */
 	low = tui_get_low_disassembly_address (low, pc);
 #endif
-      low += DEPRECATED_FUNCTION_START_OFFSET;
+      low += gdbarch_deprecated_function_start_offset (current_gdbarch);
     }
   else if (!(space_index = (char *) strchr (arg, ' ')))
     {
@@ -940,7 +940,7 @@
 	/* FIXME: cagney/2004-02-07: This should be an observer.  */
 	low = tui_get_low_disassembly_address (low, pc);
 #endif
-      low += DEPRECATED_FUNCTION_START_OFFSET;
+      low += gdbarch_deprecated_function_start_offset (current_gdbarch);
     }
   else
     {
diff -urN src/gdb/gdbarch.c dev/gdb/gdbarch.c
--- src/gdb/gdbarch.c	2007-06-18 05:36:42.000000000 +0200
+++ dev/gdb/gdbarch.c	2007-06-18 09:37:47.000000000 +0200
@@ -751,11 +751,6 @@
   fprintf_unfiltered (file,
                       "gdbarch_dump: deprecated_fp_regnum = %s\n",
                       paddr_d (current_gdbarch->deprecated_fp_regnum));
-#ifdef DEPRECATED_FUNCTION_START_OFFSET
-  fprintf_unfiltered (file,
-                      "gdbarch_dump: DEPRECATED_FUNCTION_START_OFFSET # %s\n",
-                      XSTRING (DEPRECATED_FUNCTION_START_OFFSET));
-#endif
   fprintf_unfiltered (file,
                       "gdbarch_dump: deprecated_function_start_offset = 0x%s\n",
                       paddr_nz (current_gdbarch->deprecated_function_start_offset));
diff -urN src/gdb/gdbarch.h dev/gdb/gdbarch.h
--- src/gdb/gdbarch.h	2007-06-18 05:36:42.000000000 +0200
+++ dev/gdb/gdbarch.h	2007-06-18 09:37:37.000000000 +0200
@@ -526,19 +526,13 @@
 /* A function can be addressed by either it's "pointer" (possibly a
    descriptor address) or "entry point" (first executable instruction).
    The method "convert_from_func_ptr_addr" converting the former to the
-   latter.  DEPRECATED_FUNCTION_START_OFFSET is being used to implement
+   latter.  gdbarch_deprecated_function_start_offset is being used to implement
    a simplified subset of that functionality - the function's address
    corresponds to the "function pointer" and the function's start
    corresponds to the "function entry point" - and hence is redundant. */
 
 extern CORE_ADDR gdbarch_deprecated_function_start_offset (struct gdbarch *gdbarch);
 extern void set_gdbarch_deprecated_function_start_offset (struct gdbarch *gdbarch, CORE_ADDR deprecated_function_start_offset);
-#if !defined (GDB_TM_FILE) && defined (DEPRECATED_FUNCTION_START_OFFSET)
-#error "Non multi-arch definition of DEPRECATED_FUNCTION_START_OFFSET"
-#endif
-#if !defined (DEPRECATED_FUNCTION_START_OFFSET)
-#define DEPRECATED_FUNCTION_START_OFFSET (gdbarch_deprecated_function_start_offset (current_gdbarch))
-#endif
 
 /* Return the remote protocol register number associated with this
    register.  Normally the identity mapping. */
diff -urN src/gdb/gdbarch.sh dev/gdb/gdbarch.sh
--- src/gdb/gdbarch.sh	2007-06-18 05:36:42.000000000 +0200
+++ dev/gdb/gdbarch.sh	2007-06-18 09:37:25.000000000 +0200
@@ -550,12 +550,12 @@
 # A function can be addressed by either it's "pointer" (possibly a
 # descriptor address) or "entry point" (first executable instruction).
 # The method "convert_from_func_ptr_addr" converting the former to the
-# latter.  DEPRECATED_FUNCTION_START_OFFSET is being used to implement
+# latter.  gdbarch_deprecated_function_start_offset is being used to implement
 # a simplified subset of that functionality - the function's address
 # corresponds to the "function pointer" and the function's start
 # corresponds to the "function entry point" - and hence is redundant.
 
-v:=:CORE_ADDR:deprecated_function_start_offset:::0:::0
+v::CORE_ADDR:deprecated_function_start_offset:::0:::0
 
 # Return the remote protocol register number associated with this
 # register.  Normally the identity mapping.
diff -urN src/gdb/infcall.c dev/gdb/infcall.c
--- src/gdb/infcall.c	2007-06-18 05:36:42.000000000 +0200
+++ dev/gdb/infcall.c	2007-06-18 09:41:58.000000000 +0200
@@ -232,7 +232,7 @@
 
   if (retval_type != NULL)
     *retval_type = value_type;
-  return funaddr + DEPRECATED_FUNCTION_START_OFFSET;
+  return funaddr + gdbarch_deprecated_function_start_offset (current_gdbarch);
 }
 
 /* Call breakpoint_auto_delete on the current contents of the bpstat
diff -urN src/gdb/infrun.c dev/gdb/infrun.c
--- src/gdb/infrun.c	2007-06-18 05:36:42.000000000 +0200
+++ dev/gdb/infrun.c	2007-06-18 09:41:00.000000000 +0200
@@ -1807,7 +1807,8 @@
      will both be 0 if it doesn't work.  */
   find_pc_partial_function (stop_pc, &ecs->stop_func_name,
 			    &ecs->stop_func_start, &ecs->stop_func_end);
-  ecs->stop_func_start += DEPRECATED_FUNCTION_START_OFFSET;
+  ecs->stop_func_start
+    += gdbarch_deprecated_function_start_offset (current_gdbarch);
   ecs->another_trap = 0;
   bpstat_clear (&stop_bpstat);
   stop_step = 0;
diff -urN src/gdb/linespec.c dev/gdb/linespec.c
--- src/gdb/linespec.c	2007-06-11 11:31:57.000000000 +0200
+++ dev/gdb/linespec.c	2007-06-18 09:40:22.000000000 +0200
@@ -1833,7 +1833,8 @@
   values.sals[0].section = SYMBOL_BFD_SECTION (msymbol);
   if (funfirstline)
     {
-      values.sals[0].pc += DEPRECATED_FUNCTION_START_OFFSET;
+      values.sals[0].pc
+	+= gdbarch_deprecated_function_start_offset (current_gdbarch);
       values.sals[0].pc = gdbarch_skip_prologue
 			    (current_gdbarch, values.sals[0].pc);
     }
diff -urN src/gdb/symtab.c dev/gdb/symtab.c
--- src/gdb/symtab.c	2007-06-13 20:02:39.000000000 +0200
+++ dev/gdb/symtab.c	2007-06-18 09:39:58.000000000 +0200
@@ -2527,7 +2527,7 @@
 	  !section_is_mapped (section))
 	pc = overlay_unmapped_address (pc, section);
 
-      pc += DEPRECATED_FUNCTION_START_OFFSET;
+      pc += gdbarch_deprecated_function_start_offset (current_gdbarch);
       pc = gdbarch_skip_prologue (current_gdbarch, pc);
 
       /* For overlays, map pc back into its mapped VMA range */
@@ -4101,7 +4101,7 @@
 
   /* Get an initial range for the function.  */
   find_pc_partial_function (func_addr, NULL, &start_pc, &end_pc);
-  start_pc += DEPRECATED_FUNCTION_START_OFFSET;
+  start_pc += gdbarch_deprecated_function_start_offset (current_gdbarch);
 
   prologue_sal = find_pc_line (start_pc, 0);
   if (prologue_sal.line != 0)

Re: [rfc] [2/6] Replace DEPRECATED_FUNCTION_START_OFFSET

[Eli Zaretskii]

> Date: Mon, 18 Jun 2007 11:02:19 +0200
> From: Markus Deuling <deuling@de.ibm.com>
> CC: Ulrich Weigand <uweigand@de.ibm.com>
> 
> this patch replaces DEPRECATED_FUNCTION_START_OFFSET by gdbarch_deprecated_function_start_offset. 

Sorry if I'm missing something obvious (I didn't track this series of
patches too closely), but what is the purpose and the advantages of
replacing a deprecated macro with a deprecated function?

Re: [rfc] [2/6] Replace DEPRECATED_FUNCTION_START_OFFSET

[Ulrich Weigand]

Eli Zaretskii wrote:
> > this patch replaces DEPRECATED_FUNCTION_START_OFFSET by gdbarch_deprecated_function_start_offset. 
> 
> Sorry if I'm missing something obvious (I didn't track this series of
> patches too closely), but what is the purpose and the advantages of
> replacing a deprecated macro with a deprecated function?

The purpose of this patch series is to make the "current_gdbarch" that is
implicit in those macros *explicit* at the call site, so that we can
subsequently replace it with the appropriate local "gdbarch" architecture.
This is all part of supporting multiple architectures at the same time.

Now, for those particular cases where the macro is already deprecated,
we might alternatively just eliminate its use.  However, for this specific
macro some thought is required how that can be done (if at all).  I thought
it made sense to follow through with eliminating all the gdbarch macros
now, even the deprecated ones.  They actual elimination of the deprecated
routines can happen later on just the same.

Bye,
Ulrich

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

Re: [rfc] [2/6] Replace DEPRECATED_FUNCTION_START_OFFSET

[Eli Zaretskii]

> Date: Mon, 18 Jun 2007 22:38:50 +0200 (CEST)
> From: "Ulrich Weigand" <uweigand@de.ibm.com>
> Cc: deuling@de.ibm.com (Markus Deuling), gdb-patches@sourceware.org
> 
> The purpose of this patch series is to make the "current_gdbarch" that is
> implicit in those macros *explicit* at the call site, so that we can
> subsequently replace it with the appropriate local "gdbarch" architecture.
> This is all part of supporting multiple architectures at the same time.
> 
> Now, for those particular cases where the macro is already deprecated,
> we might alternatively just eliminate its use.  However, for this specific
> macro some thought is required how that can be done (if at all).  I thought
> it made sense to follow through with eliminating all the gdbarch macros
> now, even the deprecated ones.  They actual elimination of the deprecated
> routines can happen later on just the same.

Sorry, but if this is the only reason, it doesn't make sense to me.  I
think if we touch deprecated code, we should not replace it with
another deprecated code.  If there's a way to eliminate deprecated
features, let's eliminate them, even if it takes more work.

That is my opinion; if others don't mind, I won't make a fuss out of
it, but I surely feel like we are doing haphazard job here.

Re: [rfc] [2/6] Replace DEPRECATED_FUNCTION_START_OFFSET

[Jim Blandy]

Eli Zaretskii <eliz@gnu.org> writes:
>> Date: Mon, 18 Jun 2007 22:38:50 +0200 (CEST)
>> From: "Ulrich Weigand" <uweigand@de.ibm.com>
>> Cc: deuling@de.ibm.com (Markus Deuling), gdb-patches@sourceware.org
>> 
>> The purpose of this patch series is to make the "current_gdbarch" that is
>> implicit in those macros *explicit* at the call site, so that we can
>> subsequently replace it with the appropriate local "gdbarch" architecture.
>> This is all part of supporting multiple architectures at the same time.
>> 
>> Now, for those particular cases where the macro is already deprecated,
>> we might alternatively just eliminate its use.  However, for this specific
>> macro some thought is required how that can be done (if at all).  I thought
>> it made sense to follow through with eliminating all the gdbarch macros
>> now, even the deprecated ones.  They actual elimination of the deprecated
>> routines can happen later on just the same.
>
> Sorry, but if this is the only reason, it doesn't make sense to me.  I
> think if we touch deprecated code, we should not replace it with
> another deprecated code.  If there's a way to eliminate deprecated
> features, let's eliminate them, even if it takes more work.
>
> That is my opinion; if others don't mind, I won't make a fuss out of
> it, but I surely feel like we are doing haphazard job here.

My opinion is that the change is fine.

Ulrich and Markus have already posted a substantial body of patches
working towards making GDB support multiple architectures
simultaneously.  By all indications, the Cell is a priority at IBM,
and multi-arch support would be helpful to Cell debugging, so I
believe they will carry through.  If they do, that would be a major
step forward for GDB.  If, in the process of making a valuable change,
code with an unrelated problem is left still having that unrelated
problem, I think that's fine.

If the patch introduced new uses of a deprecated facility, then I
would not be comfortable with that.