From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8247 invoked by alias); 9 Oct 2007 19:50:45 -0000 Received: (qmail 8145 invoked by uid 22791); 9 Oct 2007 19:50:43 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate6.de.ibm.com (HELO mtagate6.de.ibm.com) (195.212.29.155) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 09 Oct 2007 19:50:39 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate6.de.ibm.com (8.13.8/8.13.8) with ESMTP id l99JoaI2484024 for ; Tue, 9 Oct 2007 19:50:36 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l99Joaru2056396 for ; Tue, 9 Oct 2007 21:50:36 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l99Joao4008843 for ; Tue, 9 Oct 2007 21:50:36 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id l99Joa3U008840; Tue, 9 Oct 2007 21:50:36 +0200 Message-Id: <200710091950.l99Joa3U008840@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Tue, 9 Oct 2007 21:50:36 +0200 Subject: Re: [rfc/rft] [3/3] Remove stabs target macros: SOFUN_ADDRESS_MAYBE_MISSING To: eliz@gnu.org Date: Tue, 09 Oct 2007 19:55:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: from "Eli Zaretskii" at Oct 08, 2007 10:22:53 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-10/txt/msg00216.txt.bz2 Eli Zaretskii wrote: > > Well, the sofun_address_maybe_missing gdbarch entry is of type "v", > > i.e. it is a simple variable of type "int", not a function. > > Okay, that means my example was chosen wrongly (but please do state > somewhere that this is a variable). However, IIRC you have other > changes where a macro is replaced with a function, but arguments of > that function are not shown, and that's what I'd like you to fix. A > reader of the manual should not need to consult sources to understand > how to define such a function. SOFUN_ADDRESS_MAYBE_MISSING is the only doc change in this patch. (In another patch there was a function, but as far as I can see I've left the argument in there ...). > > I guess the question is, what is the entity that the documentation > > should specify for gdbarch entries: > > > > - the gdbarch_... accessor function > > or > > - the argument passed to the set_gdbarch_... routine > > Whatever replaced the old macro should be documented in its stead. I > thought you replaced macros with functions, but maybe I misunderstood. This is not quite how the gdbarch mechanism works. In the old style, you have a macro (function-like or not) that is defined in a header file, and used -under the same name- in GDB source code. The new gdbarch mechanism replaces those global macros with entries in a data structure; and provides accessor functions to set and query those values. These also come in different variants for function-like and variable-like entities. For a function-like gdbarch parameter, there is a set_gdbarch_... routine that the architecture-specific part calls, passing in a funtion pointer to the actual implementation of that routine. There is also an gdbarch_... accessor routine that calls the appropriate implementation. (Both of these are automatically generated by the gdbarch script.) For a variable-like gdbarch parameter, the set_gdbarch_... routine is called simply with the value of the parameter for this platform. The gdbarch_... accessor routine just returns that value. 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)) 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); 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), and the set_gdbarch_... and gdbarch_... accessor functions (which themselves are always functions, but may take different arguments depending on the type of the underlying gdbarch parameter). Now, all of this isn't really anything new, that's how gdbarch has been working for many years now. But the associated documentation looks like it doesn't quite reflect that change in a really consistent manner, that's why I was asking how it *should* be ... >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. -@code{SOFUN_ADDRESS_MAYBE_MISSING} means two things: +If @code{gdbarch_sofun_address_maybe_missing} returns non-zero: @itemize @bullet @item 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 ... Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com