diff options
| -rw-r--r-- | gdb/doc/ChangeLog | 4 | ||||
| -rw-r--r-- | gdb/doc/stabs.texinfo | 49 |
2 files changed, 33 insertions, 20 deletions
diff --git a/gdb/doc/ChangeLog b/gdb/doc/ChangeLog index 2d5cfbe..83827dd 100644 --- a/gdb/doc/ChangeLog +++ b/gdb/doc/ChangeLog @@ -1,3 +1,7 @@ +Tue Sep 7 13:45:02 1993 Jim Kingdon (kingdon@lioth.cygnus.com) + + * stabs.texinfo (Stabs In ELF): Talk about N_FUN value. + Mon Sep 6 19:23:18 1993 Jim Kingdon (kingdon@lioth.cygnus.com) * stabs.texinfo (Local Variable Parameters): Talk about nameless diff --git a/gdb/doc/stabs.texinfo b/gdb/doc/stabs.texinfo index e2733e0..fe911a1 100644 --- a/gdb/doc/stabs.texinfo +++ b/gdb/doc/stabs.texinfo @@ -3545,9 +3545,10 @@ GNU C stabs define @emph{all} types, file or procedure scope, as @code{N_LSYM}. Sun doc talks about using @code{N_GSYM} too. @item -Sun C stabs use type number pairs in the format (@var{a},@var{b}) where -@var{a} is a number starting with 1 and incremented for each sub-source -file in the compilation. @var{b} is a number starting with 1 and +Sun C stabs use type number pairs in the format +(@var{file-number},@var{type-number}) where @var{file-number} is a +number starting with 1 and incremented for each sub-source file in the +compilation. @var{type-number} is a number starting with 1 and incremented for each new type defined in the compilation. GNU C stabs use the type number alone, with no source file number. @end itemize @@ -3565,11 +3566,7 @@ section. The byte order of the stabs binary data matches the byte order of the ELF file itself, as determined from the @code{EI_DATA} field in the @code{e_ident} member of the ELF header. -@c Is "source file" the right term for this concept? We don't mean that -@c there is a separate one for include files (but "object file" or -@c "object module" isn't quite right either; the output from ld -r is a -@c single object file but contains many source files). -The first stab in the @code{.stab} section for each source file is +The first stab in the @code{.stab} section for each compilation unit is synthetic, generated entirely by the assembler, with no corresponding @code{.stab} directive as input to the assembler. This stab contains the following fields: @@ -3603,18 +3600,30 @@ section, and the @code{.stabstr} section has its ELF section header @code{sh_type} member set to @code{SHT_STRTAB} to mark it as a string table. -Because the linker does not process the @code{.stab} section in any -special way, none of the addresses in the @code{n_value} field of the -stabs are relocated by the linker. Instead they are relative to the -source file (or some entity smaller than a source file, like a -function). To find the address of each section corresponding to a given -source file, the (compiler? assembler?) puts out symbols giving the -address of each section for a given source file. Since these are normal -ELF symbols, the linker can relocate them correctly. They are -named @code{Bbss.bss} for the bss section, @code{Ddata.data} for -the data section, and @code{Drodata.rodata} for the rodata section. I -haven't yet figured out how the debugger gets the address for the text -section. +It should not be necessary for the linker to process the @code{.stab} +section in any special way, so (except for Solaris 2.2 and earlier, see +below) none of the addresses in the @code{n_value} field of the stabs +are relocated by the linker. Instead they are relative to the source +file (or some entity smaller than a source file, like a function). To +find the address of each section corresponding to a given source file, +the (compiler? assembler?) puts out symbols giving the address of each +section for a given source file. Since these are ELF (not stab) +symbols, the linker can relocate them correctly. They are named +@code{Bbss.bss} for the bss section, @code{Ddata.data} for the data +section, and @code{Drodata.rodata} for the rodata section. For the text +section, there is no such symbol. The linker provided with Solaris 2.2 +and earlier relocates stabs using relocation information from a +@code{.rela.stabs} section, which means that the value of an +@code{N_FUN} stab in an executable is the actual address. For Solaris +2.3 and later, the value of the @code{N_FUN} stab is zero and the +address of the function can be obtained from the ELF (non-stab) symbols. +Sun, in reference to bug 1142109, has verified that this is intentional. +Because looking things up in the ELF symbols is slow and GDB currently +only has code to do this for functions (which is enough for Solaris +since read-only variables go in the @code{.rodata} section), it would +probably be better to use a @code{Ttext.text} symbol for stabs-in-elf on +non-Solaris machines, and make the address in the N_FUN relative to the +@code{Ttext.text} symbol. @node Symbol Types Index @unnumbered Symbol Types Index |