espressif/binutils-gdb
1
0
Fork 0
mirror of https://github.com/espressif/binutils-gdb.git synced 2025-06-24 12:23:31 +08:00
Code Issues Packages Projects Releases Wiki Activity

* gdbarch.texi (Compiler Characteristics): Move documentation

Browse Source 
of set_gdbarch_sofun_address_maybe_missing back to ...
	(Target Conditionals): ... here to fix build break.
This commit is contained in:
Ulrich Weigand
2007-10-22 14:25:13 +00:00
parent e9a4730f82
commit e35879dbf0
2 changed files with 38 additions and 32 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
gdb/doc/ChangeLog
View File

@ -1,3 +1,9 @@
2007-10-22 Ulrich Weigand <uweigand@de.ibm.com>
* gdbarch.texi (Compiler Characteristics): Move documentation
of set_gdbarch_sofun_address_maybe_missing back to ...
(Target Conditionals): ... here to fix build break.
2007-10-19 Ulrich Weigand <uweigand@de.ibm.com> 2007-10-19 Ulrich Weigand <uweigand@de.ibm.com>
* gdbarch.texi (Target Conditionals): Remove documentation of * gdbarch.texi (Target Conditionals): Remove documentation of

64
gdb/doc/gdbint.texinfo
View File

@ -3264,38 +3264,6 @@ See @file{mips-tdep.c}. It does not do what you want.
@node Compiler Characteristics @node Compiler Characteristics
@section 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 of using those
addresses, you should find the address 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 @node Target Conditionals
@section Target Conditionals @section Target Conditionals
@ -3857,6 +3825,38 @@ A function that inserts or removes (depending on
the next instruction. See @file{sparc-tdep.c} and @file{rs6000-tdep.c} the next instruction. See @file{sparc-tdep.c} and @file{rs6000-tdep.c}
for examples. for examples.
@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 of using those
addresses, you should find the address 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}) @item int gdbarch_pc_regnum (@var{gdbarch})
@findex gdbarch_pc_regnum @findex gdbarch_pc_regnum
If the program counter is kept in a register, then let this function return If the program counter is kept in a register, then let this function return