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


Eli Zaretskii wrote:

> 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.)

Would the following wording for the SOFUN_ADDRESS_MAYBE_MISSING change
be OK?  I've moved the new text from the generic "Target Conditionals"
section to the "Compiler Characteristics" section, both to indicate that
the new style of documentation doesn't match the rest of the Target
Conditionals section any more, and because it seems to fit there better
anyway ...

Bye,
Ulrich

ChangeLog:

	* gdbarch.texi (Target Conditionals): Remove documentation of
	SOFUN_ADDRESS_MAYBE_MISSING, replaced by ...
	(Compiler Characteristics): ... documentation of
	set_gdbarch_sofun_address_maybe_missing.

diff -urNp gdb-orig/gdb/doc/gdbint.texinfo gdb-head/gdb/doc/gdbint.texinfo
--- gdb-orig/gdb/doc/gdbint.texinfo	2007-10-13 02:05:34.000000000 +0200
+++ gdb-head/gdb/doc/gdbint.texinfo	2007-10-14 22:07:50.003214603 +0200
@@ -3264,6 +3264,37 @@ See @file{mips-tdep.c}.  It does not do 
 @node Compiler Characteristics
 @section Compiler Characteristics
 
+@item set_gdbarch_sofun_address_maybe_missing (@var{gdbarch}, @var{set})
+@findex set_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.
+
+Calling @code{set_gdbarch_sofun_address_maybe_missing} with a non-zero
+argument @var{set} 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.
+
+In this case, @value{GDBN} assumes two things:
+
+@itemize @bullet
+@item
+@code{N_FUN} stabs have an address of zero.  Instead, you should find the
+addresses where the function starts by taking the function name from the
+stab, and then looking that up in the minsyms (the linker/assembler symbol
+table).  In other words, the stab has the name, and the linker/assembler
+symbol table is the only place that carries the address.
+
+@item
+@code{N_SO} stabs have an address of zero, too.  You just look at the
+@code{N_FUN} stabs that appear before and after the @code{N_SO} stab, and
+guess the starting and ending addresses of the compilation unit from them.
+@end itemize
+
 @node Target Conditionals
 @section Target Conditionals
 
@@ -3825,38 +3856,6 @@ A function that inserts or removes (depe
 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
-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{SOFUN_ADDRESS_MAYBE_MISSING} means two things:
-
-@itemize @bullet
-@item
-@code{N_FUN} stabs have an address of zero.  Instead, you should find the
-addresses where the function starts by taking the function name from
-the stab, and then looking that up in the minsyms (the
-linker/assembler symbol table).  In other words, the stab has the
-name, and the linker/assembler symbol table is the only place that carries
-the address.
-
-@item
-@code{N_SO} stabs have an address of zero, too.  You just look at the
-@code{N_FUN} stabs that appear before and after the @code{N_SO} stab,
-and guess the starting and ending addresses of the compilation unit from
-them.
-@end itemize
-
 @item int gdbarch_pc_regnum (@var{gdbarch})
 @findex gdbarch_pc_regnum
 If the program counter is kept in a register, then let this function return


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


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