* 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/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.

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
+To keep linking fast, you don't want the linker to have to relocate very
-stabs, so (except for a few cases, see below) none of the addresses in
+many stabs.  Thus Sun has invented a scheme in which addresses in the
-the @code{n_value} field of the stabs are relocated by the linker.
+@code{n_value} field are relative to the source file (or some entity
-Instead they are relative to the source file (or some entity smaller
+smaller than a source file, like a function).  To find the address of
-than a source file, like a function).  To find the address of each
+each section corresponding to a given source file, the compiler puts out
-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
+relocated.  Thus addresses which would normally be relative to
-normally be relative to @code{Bbss.bss}, etc., are already relocated.
+@code{Bbss.bss}, etc., are already relocated.  The Sun linker provided
-The Sun linker provided with Solaris 2.2 and earlier relocates stabs
+with Solaris 2.2 and earlier relocates stabs using normal ELF relocation
-using normal ELF relocation information, as it would do for any section.
+information, as it would do for any section.  Sun has been threatening
-Sun has been threatening to kludge their linker to not do this (to speed
+to kludge their linker to not do this (to speed up linking), even though
-up linking), even though the correct way to avoid having the linker do
+the correct way to avoid having the linker do these relocations is to
-these relocations is to have the compiler no longer output relocatable
+have the compiler no longer output relocatable values.  Last I heard
-values.  Last I heard they had been talked out of the linker kludge.
+they had been talked out of the linker kludge.  See Sun point patch
-See Sun point patch 101052-01 and Sun bug 1142109.  This affects
+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