This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [rfc/rft] [3/3] Remove stabs target macros: SOFUN_ADDRESS_MAYBE_MISSING


> Date: Tue, 9 Oct 2007 21:50:36 +0200 (CEST)
> From: "Ulrich Weigand" <uweigand@de.ibm.com>
> Cc: gdb-patches@sourceware.org
> 
> That means for the writer of the target-dependent code, instead of defining
> a macro in a tm-*.h header file, they need to call the appropriate 
> set_gdbarch_... routine in their target's gdbarch_init routine.  If they
> want to *use* the architecture-specific setting, instead of just refering
> to the macro, they'll have to call the appropriate gdbarch_... accessor.
> 
> In the current example, instead of placing
> #define SOFUN_ADDRESS_MAYBE_MISSING
> in a tm-*.h header file, you'd have to call
> set_gdbarch_sofun_address_maybe_missing (gdbarch, 1);
> in your gdbarch_init routine.
> 
> Instead of checking for
> #ifdef SOFUN_ADDRESS_MAYBE_MISSING
> you'd have to use something along the lines of
>   if (gdbarch_sofun_address_maybe_missing (gdbarch))

In this case, the manual should say something like this:

  @item set_gdbarch_sofun_address_maybe_missing (@var{arch}, @var{set})
  Calling this with a non-zero argument @var{set} in @code{gdbarch_init}
  tells @value{GDBN} that the architecture @var{arch} uses a particular
  set of hacks of this sort ...

That is, we need to tell the reader what to put in the code she
writes, not how will the GDB code test for that feature.  (It is
possible to _also_ describe the latter for completeness, but the
former _must_ be described.)

> For a typical case of a function-like gdbarch parameter, e.g. register_name,
> you used to have a target macro
> #define REGISTER_NAME(regnr) ...
> 
> This was replaced by defining a local function, e.g.
> 
>  static const char *
>  my_register_name (int regnr) { ... }
> 
> and registering it in the gdbarch_init routine:
> 
>  set_gdbarch_register_name (gdbarch, my_register_name);
> 
> To *use* that gdbarch parameter, you'd have to call the accessor routine
> 
>  const char *gdbarch_register_name (struct gdbarch *gdbarch, int regnr);

Again, the manual should first and foremost describe what the
architecture maintainer needs to do to get support for register names.
Something like this:

  @item set_gdbarch_register_name (@var{arch}, @var{func})
  Call this function to register @var{func} as the callback that
  returns the name of a register for the architecture @var{arch}.
  @var{func} should be written according to the following prototype:

  @smallexample
  static const char *@var{func} (int @var{regno});
  @end smallexample

  @noindent
  It will be called with the argument @var{regno} set to the number of
  the register whose name is required.

Optionally, you can also say

  To retrieve the register name, call @code{gdbarch_register_name} and
  pass it the register number as its second argument.
  @code{gdbarch_register_name} will call your registered @var{func}
  internally.

> Overall, the one entity (macro) has been replaced by really *three*
> entities: the gdbarch parameter as stored in the gdbarch structure
> (which may be either a variable or a function, but is never directly
> visible to the programmer)

I think the second example above demonstrates that for the function
case, the parameter _is_ visible to the programmer, since the
programmer needs to implement that function and register it, right?

> >From looking at other the documentation of other entries, most appear
> to refer to the accessor function.  The analogous doc for the
> sofun_address_maybe_missing case could read something like:
> 
> --- gdb-orig/gdb/doc/gdbint.texinfo	2007-10-05 18:19:25.000000000 +0200
> +++ gdb-head/gdb/doc/gdbint.texinfo	2007-10-09 21:45:12.795269867 +0200
> @@ -3847,21 +3847,22 @@
>  the next instruction. See @file{sparc-tdep.c} and @file{rs6000-tdep.c}
>  for examples.
>  
> -@item SOFUN_ADDRESS_MAYBE_MISSING
> -@findex SOFUN_ADDRESS_MAYBE_MISSING
> +@item int gdbarch_sofun_address_maybe_missing (@var{gdbarch})
> +@findex gdbarch_sofun_address_maybe_missing
>  Somebody clever observed that, the more actual addresses you have in the
>  debug information, the more time the linker has to spend relocating
>  them.  So whenever there's some other way the debugger could find the
>  address it needs, you should omit it from the debug info, to make
>  linking faster.
>  
> -@code{SOFUN_ADDRESS_MAYBE_MISSING} indicates that a particular set of
> -hacks of this sort are in use, affecting @code{N_SO} and @code{N_FUN}
> -entries in stabs-format debugging information.  @code{N_SO} stabs mark
> -the beginning and ending addresses of compilation units in the text
> -segment.  @code{N_FUN} stabs mark the starts and ends of functions.
> +@code{gdbarch_sofun_address_maybe_missing} returns a non-zero value
> +to indicate that a particular set of hacks of this sort are in use,
> +affecting @code{N_SO} and @code{N_FUN} entries in stabs-format
> +debugging information.  @code{N_SO} stabs mark the beginning and
> +ending addresses of compilation units in the text segment.
> +@code{N_FUN} stabs mark the starts and ends of functions.

You see, this is backwards: this section of the manual intends to
explain how to write target-specific back-end, but the text you
suggested actually ends up saying nothing at all about that.  Instead,
it says how GDB would use the definition to figure out what the target
needs or does.  That's not what we want.

> What I find a litte bit odd about documenting gdbarch routines this
> way is that the typical writer of platform-specific GDB code will
> never actually use this accessor function.  For them, the important
> question is whether or not to *set* that parameter in their gdbarch
> init function ...

Exactly.

So you see that converting the old macro-oriented docs to the new one
is hardly a trivial mechanical job.  It needs much more thinking and
creative rewriting.  Let's try to make this right this time, even if
the other places where macros were replaced by gdbarch functions do it
wrong.  (I will add to my TODO an item to review the other places and
correct whatever needs correction.)

Thanks for taking time to explain this!


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]