FreeChainXenon/binutils-gdb
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

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

Browse source 
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).
This commit is contained in:
Jim Kingdon 1993-11-11 21:35:07 +00:00
parent 7ae681949a
commit 577379ab60
2 changed files with 36 additions and 15 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
gdb/doc/ChangeLog
View file

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

45
gdb/doc/stabs.texinfo
View file

@ -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