From 577379ab60ac92feab064cf96f9a8365bff39f81 Mon Sep 17 00:00:00 2001 From: Jim Kingdon Date: Thu, 11 Nov 1993 21:35:07 +0000 Subject: [PATCH] * 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 | 6 ++++++ gdb/doc/stabs.texinfo | 45 ++++++++++++++++++++++++++++--------------- 2 files changed, 36 insertions(+), 15 deletions(-) diff --git a/gdb/doc/ChangeLog b/gdb/doc/ChangeLog index 2b1513d0837..69a1bd8b178 100644 --- 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 c14aad8a206..e74127b8e85 100644 --- 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 -- 2.30.2