* stabs.texinfo (Stabs in ELF): Clarify how Bbss.bss work with respect

	to picking which Bbss.bss symbol to use, and (because there seems to
	be no good way of doing it) re-write some of the text to make it
	sound like Bbss.bss isn't such a great idea after all (as currently
	designed).

diff --git a/gdb/doc/ChangeLog b/gdb/doc/ChangeLog
index 2b1513d08374f68c0b98e397f0373ad573f8b939..69a1bd8b178397e99bc8168078b304f583f62196 100644 (file)
--- a/gdb/doc/ChangeLog
+++ b/gdb/doc/ChangeLog
@@ -1,5 +1,11 @@
 Thu Nov 11 13:26:45 1993  Jim Kingdon  (kingdon@lioth.cygnus.com)
 
+       * stabs.texinfo (Stabs in ELF): Clarify how Bbss.bss work with respect
+       to picking which Bbss.bss symbol to use, and (because there seems to
+       be no good way of doing it) re-write some of the text to make it
+       sound like Bbss.bss isn't such a great idea after all (as currently
+       designed).
+
        * gdb.texinfo (C): In addition to saying people have to use g++ for
        good results, say they have to use stabs.  Specifically say cfront
        doesn't work well.

diff --git a/gdb/doc/stabs.texinfo b/gdb/doc/stabs.texinfo
index c14aad8a2064b028f7d31552767095178ad819af..e74127b8e850362d98b2a39aff12d9de78914a00 100644 (file)
--- a/gdb/doc/stabs.texinfo
+++ b/gdb/doc/stabs.texinfo
@@ -3826,12 +3826,11 @@ 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.
 
-To keep linking fast, it is a bad idea to have the linker relocating
-stabs, so (except for a few cases, 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 puts out
+To keep linking fast, you don't want the linker to have to relocate very
+many stabs.  Thus Sun has invented a scheme in which addresses in the
+@code{n_value} field 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 puts out
 symbols giving the address of each section for a given source file.
 Since these are ELF (not stab) symbols, the linker relocates them
 correctly without having to touch the stabs section.  They are named
@@ -3840,15 +3839,15 @@ section, and @code{Drodata.rodata} for the rodata section.  For the text
 section, there is no such symbol (but there should be, see below).  For
 an example of how these symbols work, @xref{ELF Transformations}.  GCC
 does not provide these symbols; it instead relies on the stabs getting
-relocated, which slows down linking.  Thus addresses which would
-normally be relative to @code{Bbss.bss}, etc., are already relocated.
-The Sun linker provided with Solaris 2.2 and earlier relocates stabs
-using normal ELF relocation information, as it would do for any section.
-Sun has been threatening to kludge their linker to not do this (to speed
-up linking), even though the correct way to avoid having the linker do
-these relocations is to have the compiler no longer output relocatable
-values.  Last I heard they had been talked out of the linker kludge.
-See Sun point patch 101052-01 and Sun bug 1142109.  This affects
+relocated.  Thus addresses which would normally be relative to
+@code{Bbss.bss}, etc., are already relocated.  The Sun linker provided
+with Solaris 2.2 and earlier relocates stabs using normal ELF relocation
+information, as it would do for any section.  Sun has been threatening
+to kludge their linker to not do this (to speed up linking), even though
+the correct way to avoid having the linker do these relocations is to
+have the compiler no longer output relocatable values.  Last I heard
+they had been talked out of the linker kludge.  See Sun point patch
+101052-01 and Sun bug 1142109.  With the Sun compiler this affects
 @samp{S} symbol descriptor stabs (@pxref{Statics}) and functions
 (@pxref{Procedures}).  In the latter case, to adopt the clean solution
 (making the value of the stab relative to the start of the compilation
@@ -3857,6 +3856,22 @@ analogous to the @code{Bbss.bss}, etc., symbols.  I recommend this
 rather than using a zero value and getting the address from the ELF
 symbols.
 
+Finding the correct @code{Bbss.bss}, etc., symbol is difficult, because
+the linker simply concatenates the @code{.stab} sections from each
+@file{.o} file without including any information about which part of a
+@code{.stab} section comes from which @file{.o} file.  The way GDB does
+this is to look for an ELF @code{STT_FILE} symbol which has the same
+name as the last component of the file name from the @code{N_SO} symbol
+in the stabs (for example, if the file name is @file{../../gdb/main.c},
+it looks for an ELF @code{STT_FILE} symbol named @code{main.c}).  This
+loses if different files have the same name (they could be in different
+directories, a library could have been copied from one system to
+another, etc.).  It would be much cleaner to have the @code{Bbss.bss}
+symbols in the stabs themselves.  Having the linker relocate them there
+is no more work than having the linker relocate ELF symbols, and it
+solves the problem of having to associate the ELF and stab symbols.
+However, no one has yet designed or implemented such a scheme.
+
 @node Symbol Types Index
 @unnumbered Symbol Types Index