* [rfc/rft] [3/3] Remove stabs target macros: SOFUN_ADDRESS_MAYBE_MISSING
@ 2007-10-05 18:06 Ulrich Weigand
2007-10-06 7:16 ` Eli Zaretskii
0 siblings, 1 reply; 10+ messages in thread
From: Ulrich Weigand @ 2007-10-05 18:06 UTC (permalink / raw)
To: gdb-patches
Hello,
this removes the SOFUN_ADDRESS_MAYBE_MISSING target macro. There are
two main parts to this:
- struct minimal_symbol used to have the member "filename" present
only when SOFUN_ADDRESS_MAYBE_MISSING was true. The patch changes
this to make the member always available. Code used to initialize
and use those filenames is now also enabled unconditionally. (This
should not actually change the behaviour of GDB on any target.)
- Instead of the SOFUN_ADDRESS_MAYBE_MISSING macro, a new gdbarch
variable gdbarch_sofun_address_maybe_missing is introduces. All
places where GDB behaviour depended on SOFUN_ADDRESS_MAYBE_MISSING
now look at that gdbarch variable instead.
Bye,
Ulrich
ChangeLog:
* gdbarch.sh (sofun_address_maybe_missing): New gdbarch variable.
* gdbarch.c, gdbarch.h: Regenerate.
* dbxread.c (find_stab_function_addr): Define unconditionally.
(read_dbx_symtab): Use gdbarch_sofun_address_maybe_missing
instead of SOFUN_ADDRESS_MAYBE_MISSING.
(end_psymtab): Likewise.
(process_one_symbol): Likewise.
* mdebugread.c (parse_partial_symbols): Likewise.
* symtab.h (struct minimal_symbol): Always define "filename" member.
* elfread.c (elf_symtab_read): Use msym->filename unconditionally.
* minsyms.c (lookup_minimal_symbol): Likewise.
* symmisc.c (dump_msymbols): Likewise.
* config/i386/i386sol2.mt (DEPRECATED_TM_FILE): Remove.
* config/i386/linux.mt (DEPRECATED_TM_FILE): Remove.
* config/i386/tm-i386sol2.h: Remove file.
* config/i386/tm-linux.h: Remove file.
* i386-linux-tdep.c (i386_linux_init_abi): Add call to
set_gdbarch_sofun_address_maybe_missing.
* i386-sol2-tdep.c (i386_sol2_init_abi): Likewise.
* config/powerpc/linux.mt (DEPRECATED_TM_FILE): Remove.
* config/powerpc/nbsd.mt (DEPRECATED_TM_FILE): Remove.
* config/powerpc/obsd.mt (DEPRECATED_TM_FILE): Remove.
* config/powerpc/ppc-eabi.mt (DEPRECATED_TM_FILE): Remove.
* config/powerpc/ppc-sim.mt (DEPRECATED_TM_FILE): Remove.
* config/powerpc/tm-ppc-eabi.h: Remove file.
* rs6000-tdep.c (rs6000_gdbarch_init): Add call to
set_gdbarch_sofun_address_maybe_missing.
* config/sparc/sol2-64.mt (DEPRECATED_TM_FILE): Remove.
* config/sparc/sol2.mt (DEPRECATED_TM_FILE): Remove.
* config/sparc/tm-sol2.h: Remove file.
* sparc64-sol2-tdep.c (sparc64_sol2_init_abi): Add call to
set_gdbarch_sofun_address_maybe_missing.
* sparc-sol2-tdep.c (sparc32_sol2_init_abi): Likewise.
doc/ChangeLog:
* gdbint.texinfo: Document gdbarch_sofun_address_maybe_missing
instead of SOFUN_ADDRESS_MAYBE_MISSING.
diff -urNp gdb-orig/gdb/config/i386/i386sol2.mt gdb-head/gdb/config/i386/i386sol2.mt
--- gdb-orig/gdb/config/i386/i386sol2.mt 2007-10-05 14:54:47.000000000 +0200
+++ gdb-head/gdb/config/i386/i386sol2.mt 2007-10-05 17:55:13.498978656 +0200
@@ -1,4 +1,3 @@
# Target: Solaris x86
TDEPFILES= i386-tdep.o i387-tdep.o i386-sol2-tdep.o sol2-tdep.o \
corelow.o solib.o solib-svr4.o
-DEPRECATED_TM_FILE= tm-i386sol2.h
diff -urNp gdb-orig/gdb/config/i386/linux.mt gdb-head/gdb/config/i386/linux.mt
--- gdb-orig/gdb/config/i386/linux.mt 2007-10-05 14:54:47.000000000 +0200
+++ gdb-head/gdb/config/i386/linux.mt 2007-10-05 17:55:13.502978080 +0200
@@ -1,4 +1,3 @@
# Target: Intel 386 running GNU/Linux
TDEPFILES= i386-tdep.o i386-linux-tdep.o glibc-tdep.o i387-tdep.o \
solib.o solib-svr4.o symfile-mem.o corelow.o
-DEPRECATED_TM_FILE= tm-linux.h
diff -urNp gdb-orig/gdb/config/i386/tm-i386sol2.h gdb-head/gdb/config/i386/tm-i386sol2.h
--- gdb-orig/gdb/config/i386/tm-i386sol2.h 2007-10-05 17:55:07.749008957 +0200
+++ gdb-head/gdb/config/i386/tm-i386sol2.h 1970-01-01 01:00:00.000000000 +0100
@@ -1,27 +0,0 @@
-/* Macro definitions for GDB on an Intel i386 running Solaris 2.
-
- Copyright 1998, 1999, 2000, 2004, 2007 Free Software Foundation, Inc.
-
- This file is part of GDB.
-
- This program is free software; you can redistribute it and/or modify
- it under the terms of the GNU General Public License as published by
- the Free Software Foundation; either version 3 of the License, or
- (at your option) any later version.
-
- This program is distributed in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- GNU General Public License for more details.
-
- You should have received a copy of the GNU General Public License
- along with this program. If not, see <http://www.gnu.org/licenses/>. */
-
-#ifndef TM_I386SOL2_H
-#define TM_I386SOL2_H 1
-
-/* The SunPRO compiler puts out 0 instead of the address in N_SO symbols,
- and for SunPRO 3.0, N_FUN symbols too. */
-#define SOFUN_ADDRESS_MAYBE_MISSING
-
-#endif /* tm-i386sol2.h */
diff -urNp gdb-orig/gdb/config/i386/tm-linux.h gdb-head/gdb/config/i386/tm-linux.h
--- gdb-orig/gdb/config/i386/tm-linux.h 2007-10-05 14:54:47.000000000 +0200
+++ gdb-head/gdb/config/i386/tm-linux.h 1970-01-01 01:00:00.000000000 +0100
@@ -1,28 +0,0 @@
-/* Definitions to target GDB to GNU/Linux on 386.
-
- Copyright 1992, 1993, 1995, 1996, 1998, 1999, 2000, 2001, 2002, 2004, 2007
- Free Software Foundation, Inc.
-
- This file is part of GDB.
-
- This program is free software; you can redistribute it and/or modify
- it under the terms of the GNU General Public License as published by
- the Free Software Foundation; either version 3 of the License, or
- (at your option) any later version.
-
- This program is distributed in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- GNU General Public License for more details.
-
- You should have received a copy of the GNU General Public License
- along with this program. If not, see <http://www.gnu.org/licenses/>. */
-
-#ifndef TM_LINUX_H
-#define TM_LINUX_H
-
-/* N_FUN symbols in shared libaries have 0 for their values and need
- to be relocated. */
-#define SOFUN_ADDRESS_MAYBE_MISSING
-
-#endif /* #ifndef TM_LINUX_H */
diff -urNp gdb-orig/gdb/config/powerpc/linux.mt gdb-head/gdb/config/powerpc/linux.mt
--- gdb-orig/gdb/config/powerpc/linux.mt 2007-10-05 14:54:47.000000000 +0200
+++ gdb-head/gdb/config/powerpc/linux.mt 2007-10-05 17:55:13.536973183 +0200
@@ -1,7 +1,6 @@
# Target: Motorola PPC on Linux
TDEPFILES= rs6000-tdep.o ppc-linux-tdep.o ppc-sysv-tdep.o solib.o \
solib-svr4.o solib-legacy.o corelow.o symfile-mem.o
-DEPRECATED_TM_FILE= tm-ppc-eabi.h
SIM_OBS = remote-sim.o
SIM = ../sim/ppc/libsim.a
diff -urNp gdb-orig/gdb/config/powerpc/nbsd.mt gdb-head/gdb/config/powerpc/nbsd.mt
--- gdb-orig/gdb/config/powerpc/nbsd.mt 2007-10-05 14:54:47.000000000 +0200
+++ gdb-head/gdb/config/powerpc/nbsd.mt 2007-10-05 17:55:13.540972606 +0200
@@ -1,7 +1,6 @@
# Target: NetBSD/powerpc
TDEPFILES= rs6000-tdep.o ppc-sysv-tdep.o ppcnbsd-tdep.o \
corelow.o solib.o solib-svr4.o
-DEPRECATED_TM_FILE= tm-ppc-eabi.h
SIM_OBS = remote-sim.o
SIM = ../sim/ppc/libsim.a
diff -urNp gdb-orig/gdb/config/powerpc/obsd.mt gdb-head/gdb/config/powerpc/obsd.mt
--- gdb-orig/gdb/config/powerpc/obsd.mt 2007-10-05 14:54:47.000000000 +0200
+++ gdb-head/gdb/config/powerpc/obsd.mt 2007-10-05 17:55:13.544972030 +0200
@@ -1,4 +1,3 @@
# Target: OpenBSD/powerpc
TDEPFILES= rs6000-tdep.o ppc-sysv-tdep.o ppcobsd-tdep.o \
corelow.o solib.o solib-svr4.o
-DEPRECATED_TM_FILE= tm-ppc-eabi.h
diff -urNp gdb-orig/gdb/config/powerpc/ppc-eabi.mt gdb-head/gdb/config/powerpc/ppc-eabi.mt
--- gdb-orig/gdb/config/powerpc/ppc-eabi.mt 2007-10-05 14:54:47.000000000 +0200
+++ gdb-head/gdb/config/powerpc/ppc-eabi.mt 2007-10-05 17:55:13.547971598 +0200
@@ -1,3 +1,2 @@
# Target: PowerPC running eabi
TDEPFILES= rs6000-tdep.o monitor.o dsrec.o ppcbug-rom.o dink32-rom.o ppc-sysv-tdep.o solib.o solib-svr4.o
-DEPRECATED_TM_FILE= tm-ppc-eabi.h
diff -urNp gdb-orig/gdb/config/powerpc/ppc-sim.mt gdb-head/gdb/config/powerpc/ppc-sim.mt
--- gdb-orig/gdb/config/powerpc/ppc-sim.mt 2007-10-05 14:54:47.000000000 +0200
+++ gdb-head/gdb/config/powerpc/ppc-sim.mt 2007-10-05 17:55:13.556970302 +0200
@@ -1,6 +1,5 @@
# Target: PowerPC running eabi and including the simulator
TDEPFILES= rs6000-tdep.o monitor.o dsrec.o ppcbug-rom.o dink32-rom.o ppc-sysv-tdep.o solib.o solib-svr4.o
-DEPRECATED_TM_FILE= tm-ppc-eabi.h
SIM_OBS = remote-sim.o
SIM = ../sim/ppc/libsim.a
diff -urNp gdb-orig/gdb/config/powerpc/tm-ppc-eabi.h gdb-head/gdb/config/powerpc/tm-ppc-eabi.h
--- gdb-orig/gdb/config/powerpc/tm-ppc-eabi.h 2007-10-05 14:54:47.000000000 +0200
+++ gdb-head/gdb/config/powerpc/tm-ppc-eabi.h 1970-01-01 01:00:00.000000000 +0100
@@ -1,27 +0,0 @@
-/* Macro definitions for Power PC running embedded ABI.
- Copyright 1995, 1996, 1997, 1998, 1999, 2000, 2007
- Free Software Foundation, Inc.
-
- This file is part of GDB.
-
- This program is free software; you can redistribute it and/or modify
- it under the terms of the GNU General Public License as published by
- the Free Software Foundation; either version 3 of the License, or
- (at your option) any later version.
-
- This program is distributed in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- GNU General Public License for more details.
-
- You should have received a copy of the GNU General Public License
- along with this program. If not, see <http://www.gnu.org/licenses/>. */
-
-#ifndef TM_PPC_EABI_H
-#define TM_PPC_EABI_H
-
-/* The value of symbols of type N_SO and N_FUN maybe null when
- it shouldn't be. */
-#define SOFUN_ADDRESS_MAYBE_MISSING
-
-#endif /* TM_PPC_EABI_H */
diff -urNp gdb-orig/gdb/config/sparc/sol2-64.mt gdb-head/gdb/config/sparc/sol2-64.mt
--- gdb-orig/gdb/config/sparc/sol2-64.mt 2007-10-05 14:54:47.000000000 +0200
+++ gdb-head/gdb/config/sparc/sol2-64.mt 2007-10-05 17:55:13.569968429 +0200
@@ -1,4 +1,3 @@
# Target: Solaris UltraSPARC
TDEPFILES= sparc64-tdep.o sparc64-sol2-tdep.o sparc-tdep.o sparc-sol2-tdep.o \
sol2-tdep.o solib.o solib-svr4.o
-DEPRECATED_TM_FILE= tm-sol2.h
diff -urNp gdb-orig/gdb/config/sparc/sol2.mt gdb-head/gdb/config/sparc/sol2.mt
--- gdb-orig/gdb/config/sparc/sol2.mt 2007-10-05 14:54:47.000000000 +0200
+++ gdb-head/gdb/config/sparc/sol2.mt 2007-10-05 17:55:13.572967997 +0200
@@ -1,3 +1,2 @@
# Target: Solaris SPARC
TDEPFILES= sparc-tdep.o sparc-sol2-tdep.o sol2-tdep.o solib.o solib-svr4.o
-DEPRECATED_TM_FILE= tm-sol2.h
diff -urNp gdb-orig/gdb/config/sparc/tm-sol2.h gdb-head/gdb/config/sparc/tm-sol2.h
--- gdb-orig/gdb/config/sparc/tm-sol2.h 2007-10-05 17:55:07.753008381 +0200
+++ gdb-head/gdb/config/sparc/tm-sol2.h 1970-01-01 01:00:00.000000000 +0100
@@ -1,29 +0,0 @@
-/* Target-dependent definitions for Solaris SPARC.
-
- Copyright 2003, 2004, 2007 Free Software Foundation, Inc.
-
- This file is part of GDB.
-
- This program is free software; you can redistribute it and/or modify
- it under the terms of the GNU General Public License as published by
- the Free Software Foundation; either version 3 of the License, or
- (at your option) any later version.
-
- This program is distributed in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- GNU General Public License for more details.
-
- You should have received a copy of the GNU General Public License
- along with this program. If not, see <http://www.gnu.org/licenses/>. */
-
-#ifndef TM_SOL2_H
-#define TM_SOL2_H
-
-/* The Sun compilers (Sun ONE Studio, Forte Developer, Sun WorkShop,
- SunPRO) compiler puts out 0 instead of the address in N_SO stabs.
- Starting with SunPRO 3.0, the compiler does this for N_FUN stabs
- too. */
-#define SOFUN_ADDRESS_MAYBE_MISSING
-
-#endif /* tm-sol2.h */
diff -urNp gdb-orig/gdb/dbxread.c gdb-head/gdb/dbxread.c
--- gdb-orig/gdb/dbxread.c 2007-10-05 17:55:07.764006796 +0200
+++ gdb-head/gdb/dbxread.c 2007-10-05 17:55:13.586965980 +0200
@@ -1116,7 +1116,6 @@ read_dbx_dynamic_symtab (struct objfile
do_cleanups (back_to);
}
-#ifdef SOFUN_ADDRESS_MAYBE_MISSING
static CORE_ADDR
find_stab_function_addr (char *namestring, char *filename,
struct objfile *objfile)
@@ -1160,7 +1159,6 @@ find_stab_function_addr (char *namestrin
return msym == NULL ? 0 : SYMBOL_VALUE_ADDRESS (msym);
}
-#endif /* SOFUN_ADDRESS_MAYBE_MISSING */
static void
function_outside_compilation_unit_complaint (const char *arg1)
@@ -1463,21 +1461,19 @@ read_dbx_symtab (struct objfile *objfile
prev_textlow_not_set = textlow_not_set;
-#ifdef SOFUN_ADDRESS_MAYBE_MISSING
/* A zero value is probably an indication for the SunPRO 3.0
compiler. end_psymtab explicitly tests for zero, so
don't relocate it. */
- if (nlist.n_value == 0)
+ if (nlist.n_value == 0
+ && gdbarch_sofun_address_maybe_missing (current_gdbarch))
{
textlow_not_set = 1;
valu = 0;
}
else
textlow_not_set = 0;
-#else
- textlow_not_set = 0;
-#endif
+
past_first_source_file = 1;
if (prev_so_symnum != symnum - 1)
@@ -1832,11 +1828,11 @@ read_dbx_symtab (struct objfile *objfile
SECT_OFF_TEXT (objfile));
/* Kludges for ELF/STABS with Sun ACC */
last_function_name = namestring;
-#ifdef SOFUN_ADDRESS_MAYBE_MISSING
/* Do not fix textlow==0 for .o or NLM files, as 0 is a legit
value for the bottom of the text seg in those cases. */
if (nlist.n_value == ANOFFSET (objfile->section_offsets,
- SECT_OFF_TEXT (objfile)))
+ SECT_OFF_TEXT (objfile))
+ && gdbarch_sofun_address_maybe_missing (current_gdbarch))
{
CORE_ADDR minsym_valu =
find_stab_function_addr (namestring,
@@ -1850,12 +1846,12 @@ read_dbx_symtab (struct objfile *objfile
if (minsym_valu != 0)
nlist.n_value = minsym_valu;
}
- if (pst && textlow_not_set)
+ if (pst && textlow_not_set
+ && gdbarch_sofun_address_maybe_missing (current_gdbarch))
{
pst->textlow = nlist.n_value;
textlow_not_set = 0;
}
-#endif
/* End kludge. */
/* Keep track of the start of the last function so we
@@ -1900,11 +1896,11 @@ read_dbx_symtab (struct objfile *objfile
SECT_OFF_TEXT (objfile));
/* Kludges for ELF/STABS with Sun ACC */
last_function_name = namestring;
-#ifdef SOFUN_ADDRESS_MAYBE_MISSING
/* Do not fix textlow==0 for .o or NLM files, as 0 is a legit
value for the bottom of the text seg in those cases. */
if (nlist.n_value == ANOFFSET (objfile->section_offsets,
- SECT_OFF_TEXT (objfile)))
+ SECT_OFF_TEXT (objfile))
+ && gdbarch_sofun_address_maybe_missing (current_gdbarch))
{
CORE_ADDR minsym_valu =
find_stab_function_addr (namestring,
@@ -1918,12 +1914,12 @@ read_dbx_symtab (struct objfile *objfile
if (minsym_valu != 0)
nlist.n_value = minsym_valu;
}
- if (pst && textlow_not_set)
+ if (pst && textlow_not_set
+ && gdbarch_sofun_address_maybe_missing (current_gdbarch))
{
pst->textlow = nlist.n_value;
textlow_not_set = 0;
}
-#endif
/* End kludge. */
/* Keep track of the start of the last function so we
@@ -2049,12 +2045,11 @@ read_dbx_symtab (struct objfile *objfile
continue;
case N_ENDM:
-#ifdef SOFUN_ADDRESS_MAYBE_MISSING
/* Solaris 2 end of module, finish current partial symbol table.
end_psymtab will set pst->texthigh to the proper value, which
is necessary if a module compiled without debugging info
follows this module. */
- if (pst)
+ if (pst && gdbarch_sofun_address_maybe_missing (current_gdbarch))
{
end_psymtab (pst, psymtab_include_list, includes_used,
symnum * symbol_size,
@@ -2064,7 +2059,6 @@ read_dbx_symtab (struct objfile *objfile
includes_used = 0;
dependencies_used = 0;
}
-#endif
continue;
case N_RBRAC:
@@ -2186,7 +2180,6 @@ end_psymtab (struct partial_symtab *pst,
LDSYMLEN (pst) = capping_symbol_offset - LDSYMOFF (pst);
pst->texthigh = capping_text;
-#ifdef SOFUN_ADDRESS_MAYBE_MISSING
/* Under Solaris, the N_SO symbols always have a value of 0,
instead of the usual address of the .o file. Therefore,
we have to do some tricks to fill in texthigh and textlow.
@@ -2202,7 +2195,8 @@ end_psymtab (struct partial_symtab *pst,
a reliable texthigh by taking the address plus size of the
last function in the file. */
- if (pst->texthigh == 0 && last_function_name)
+ if (pst->texthigh == 0 && last_function_name
+ && gdbarch_sofun_address_maybe_missing (current_gdbarch))
{
char *p;
int n;
@@ -2233,8 +2227,10 @@ end_psymtab (struct partial_symtab *pst,
last_function_name = NULL;
}
+ if (!gdbarch_sofun_address_maybe_missing (current_gdbarch))
+ ;
/* this test will be true if the last .o file is only data */
- if (textlow_not_set)
+ else if (textlow_not_set)
pst->textlow = pst->texthigh;
else
{
@@ -2259,7 +2255,6 @@ end_psymtab (struct partial_symtab *pst,
}
/* End of kludge for patching Solaris textlow and texthigh. */
-#endif /* SOFUN_ADDRESS_MAYBE_MISSING. */
pst->n_global_syms =
objfile->global_psymbols.next - (objfile->global_psymbols.list + pst->globals_offset);
@@ -3107,12 +3102,12 @@ no enclosing block"));
case 'F':
function_stab_type = type;
-#ifdef SOFUN_ADDRESS_MAYBE_MISSING
/* Deal with the SunPRO 3.0 compiler which omits the
address from N_FUN symbols. */
if (type == N_FUN
&& valu == ANOFFSET (section_offsets,
- SECT_OFF_TEXT (objfile)))
+ SECT_OFF_TEXT (objfile))
+ && gdbarch_sofun_address_maybe_missing (current_gdbarch))
{
CORE_ADDR minsym_valu =
find_stab_function_addr (name, last_source_file, objfile);
@@ -3126,7 +3121,6 @@ no enclosing block"));
if (minsym_valu != 0)
valu = minsym_valu;
}
-#endif
if (block_address_function_relative)
/* For Solaris 2 compilers, the block addresses and
diff -urNp gdb-orig/gdb/doc/gdbint.texinfo gdb-head/gdb/doc/gdbint.texinfo
--- gdb-orig/gdb/doc/gdbint.texinfo 2007-10-05 17:52:44.557830426 +0200
+++ gdb-head/gdb/doc/gdbint.texinfo 2007-10-05 17:55:13.642090238 +0200
@@ -3847,21 +3847,21 @@ A function that inserts or removes (depe
the next instruction. See @file{sparc-tdep.c} and @file{rs6000-tdep.c}
for examples.
-@item SOFUN_ADDRESS_MAYBE_MISSING
-@findex SOFUN_ADDRESS_MAYBE_MISSING
+@item int gdbarch_sofun_address_maybe_missing
+@findex gdbarch_sofun_address_maybe_missing
Somebody clever observed that, the more actual addresses you have in the
debug information, the more time the linker has to spend relocating
them. So whenever there's some other way the debugger could find the
address it needs, you should omit it from the debug info, to make
linking faster.
-@code{SOFUN_ADDRESS_MAYBE_MISSING} indicates that a particular set of
+@code{gdbarch_sofun_address_maybe_missing} indicates that a particular set of
hacks of this sort are in use, affecting @code{N_SO} and @code{N_FUN}
entries in stabs-format debugging information. @code{N_SO} stabs mark
the beginning and ending addresses of compilation units in the text
segment. @code{N_FUN} stabs mark the starts and ends of functions.
-@code{SOFUN_ADDRESS_MAYBE_MISSING} means two things:
+@code{gdbarch_sofun_address_maybe_missing} means two things:
@itemize @bullet
@item
diff -urNp gdb-orig/gdb/elfread.c gdb-head/gdb/elfread.c
--- gdb-orig/gdb/elfread.c 2007-10-05 14:54:47.000000000 +0200
+++ gdb-head/gdb/elfread.c 2007-10-05 17:55:13.683084333 +0200
@@ -213,10 +213,8 @@ elf_symtab_read (struct objfile *objfile
/* If filesym is nonzero, it points to a file symbol, but we haven't
seen any section info for it yet. */
asymbol *filesym = 0;
-#ifdef SOFUN_ADDRESS_MAYBE_MISSING
/* Name of filesym, as saved on the objfile_obstack. */
char *filesymname = obsavestring ("", 0, &objfile->objfile_obstack);
-#endif
struct dbx_symfile_info *dbx = objfile->deprecated_sym_stab_info;
int stripped = (bfd_get_symcount (objfile->obfd) == 0);
@@ -258,10 +256,8 @@ elf_symtab_read (struct objfile *objfile
msym = record_minimal_symbol
((char *) sym->name, symaddr,
mst_solib_trampoline, sym->section, objfile);
-#ifdef SOFUN_ADDRESS_MAYBE_MISSING
if (msym != NULL)
msym->filename = filesymname;
-#endif
continue;
}
@@ -281,11 +277,9 @@ elf_symtab_read (struct objfile *objfile
sectinfo = NULL;
}
filesym = sym;
-#ifdef SOFUN_ADDRESS_MAYBE_MISSING
filesymname =
obsavestring ((char *) filesym->name, strlen (filesym->name),
&objfile->objfile_obstack);
-#endif
}
else if (sym->flags & BSF_SECTION_SYM)
continue;
@@ -476,10 +470,8 @@ elf_symtab_read (struct objfile *objfile
unsigned long size = ((elf_symbol_type *) sym)->internal_elf_sym.st_size;
MSYMBOL_SIZE(msym) = size;
}
-#ifdef SOFUN_ADDRESS_MAYBE_MISSING
if (msym != NULL)
msym->filename = filesymname;
-#endif
gdbarch_elf_make_msymbol_special (current_gdbarch, sym, msym);
}
}
diff -urNp gdb-orig/gdb/gdbarch.c gdb-head/gdb/gdbarch.c
--- gdb-orig/gdb/gdbarch.c 2007-10-05 17:55:07.811999882 +0200
+++ gdb-head/gdb/gdbarch.c 2007-10-05 17:55:13.694082748 +0200
@@ -233,6 +233,7 @@ struct gdbarch
gdbarch_core_read_description_ftype *core_read_description;
gdbarch_variables_inside_block_ftype *variables_inside_block;
gdbarch_static_transform_name_ftype *static_transform_name;
+ int sofun_address_maybe_missing;
};
@@ -358,6 +359,7 @@ struct gdbarch startup_gdbarch =
0, /* core_read_description */
0, /* variables_inside_block */
0, /* static_transform_name */
+ 0, /* sofun_address_maybe_missing */
/* startup_gdbarch() */
};
@@ -608,6 +610,7 @@ verify_gdbarch (struct gdbarch *current_
/* Skip verify of core_read_description, has predicate */
/* Skip verify of variables_inside_block, has predicate */
/* Skip verify of static_transform_name, has predicate */
+ /* Skip verify of sofun_address_maybe_missing, invalid_p == 0 */
buf = ui_file_xstrdup (log, &dummy);
make_cleanup (xfree, buf);
if (strlen (buf) > 0)
@@ -1005,6 +1008,9 @@ gdbarch_dump (struct gdbarch *current_gd
"gdbarch_dump: software_single_step = <0x%lx>\n",
(long) current_gdbarch->software_single_step);
fprintf_unfiltered (file,
+ "gdbarch_dump: sofun_address_maybe_missing = %s\n",
+ paddr_d (current_gdbarch->sofun_address_maybe_missing));
+ fprintf_unfiltered (file,
"gdbarch_dump: sp_regnum = %s\n",
paddr_d (current_gdbarch->sp_regnum));
fprintf_unfiltered (file,
@@ -3100,6 +3106,23 @@ set_gdbarch_static_transform_name (struc
gdbarch->static_transform_name = static_transform_name;
}
+int
+gdbarch_sofun_address_maybe_missing (struct gdbarch *gdbarch)
+{
+ gdb_assert (gdbarch != NULL);
+ /* Skip verify of sofun_address_maybe_missing, invalid_p == 0 */
+ if (gdbarch_debug >= 2)
+ fprintf_unfiltered (gdb_stdlog, "gdbarch_sofun_address_maybe_missing called\n");
+ return gdbarch->sofun_address_maybe_missing;
+}
+
+void
+set_gdbarch_sofun_address_maybe_missing (struct gdbarch *gdbarch,
+ int sofun_address_maybe_missing)
+{
+ gdbarch->sofun_address_maybe_missing = sofun_address_maybe_missing;
+}
+
/* Keep a registry of per-architecture data-pointers required by GDB
modules. */
diff -urNp gdb-orig/gdb/gdbarch.h gdb-head/gdb/gdbarch.h
--- gdb-orig/gdb/gdbarch.h 2007-10-05 17:55:07.855993545 +0200
+++ gdb-head/gdb/gdbarch.h 2007-10-05 17:55:13.735076842 +0200
@@ -711,6 +711,11 @@ typedef char * (gdbarch_static_transform
extern char * gdbarch_static_transform_name (struct gdbarch *gdbarch, char *name);
extern void set_gdbarch_static_transform_name (struct gdbarch *gdbarch, gdbarch_static_transform_name_ftype *static_transform_name);
+/* Set if the address in N_SO or N_FUN stabs may be zero. */
+
+extern int gdbarch_sofun_address_maybe_missing (struct gdbarch *gdbarch);
+extern void set_gdbarch_sofun_address_maybe_missing (struct gdbarch *gdbarch, int sofun_address_maybe_missing);
+
extern struct gdbarch_tdep *gdbarch_tdep (struct gdbarch *gdbarch);
diff -urNp gdb-orig/gdb/gdbarch.sh gdb-head/gdb/gdbarch.sh
--- gdb-orig/gdb/gdbarch.sh 2007-10-05 17:55:07.899987207 +0200
+++ gdb-head/gdb/gdbarch.sh 2007-10-05 17:55:13.759073385 +0200
@@ -661,6 +661,8 @@ M::const struct target_desc *:core_read_
F::int:variables_inside_block:int desc, int gcc_p:desc, gcc_p
# Handle special encoding of static variables in stabs debug info.
F::char *:static_transform_name:char *name:name
+# Set if the address in N_SO or N_FUN stabs may be zero.
+v::int:sofun_address_maybe_missing:::0:0::0
EOF
}
diff -urNp gdb-orig/gdb/i386-linux-tdep.c gdb-head/gdb/i386-linux-tdep.c
--- gdb-orig/gdb/i386-linux-tdep.c 2007-10-05 14:54:47.000000000 +0200
+++ gdb-head/gdb/i386-linux-tdep.c 2007-10-05 17:55:13.802067192 +0200
@@ -429,6 +429,10 @@ i386_linux_init_abi (struct gdbarch_info
tdep->sc_reg_offset = i386_linux_sc_reg_offset;
tdep->sc_num_regs = ARRAY_SIZE (i386_linux_sc_reg_offset);
+ /* N_FUN symbols in shared libaries have 0 for their values and need
+ to be relocated. */
+ set_gdbarch_sofun_address_maybe_missing (gdbarch, 1);
+
/* GNU/Linux uses SVR4-style shared libraries. */
set_gdbarch_skip_trampoline_code (gdbarch, find_solib_trampoline_target);
set_solib_svr4_fetch_link_map_offsets
diff -urNp gdb-orig/gdb/i386-sol2-tdep.c gdb-head/gdb/i386-sol2-tdep.c
--- gdb-orig/gdb/i386-sol2-tdep.c 2007-10-05 17:55:07.940981301 +0200
+++ gdb-head/gdb/i386-sol2-tdep.c 2007-10-05 17:55:13.806066615 +0200
@@ -109,6 +109,10 @@ i386_sol2_init_abi (struct gdbarch_info
/* Solaris is SVR4-based. */
i386_svr4_init_abi (info, gdbarch);
+ /* The SunPRO compiler puts out 0 instead of the address in N_SO symbols,
+ and for SunPRO 3.0, N_FUN symbols too. */
+ set_gdbarch_sofun_address_maybe_missing (gdbarch, 1);
+
/* Handle SunPRO encoding of static symbols. */
set_gdbarch_static_transform_name (gdbarch, i386_sol2_static_transform_name);
diff -urNp gdb-orig/gdb/mdebugread.c gdb-head/gdb/mdebugread.c
--- gdb-orig/gdb/mdebugread.c 2007-10-05 17:55:07.996973235 +0200
+++ gdb-head/gdb/mdebugread.c 2007-10-05 17:55:13.828063447 +0200
@@ -2844,21 +2844,20 @@ parse_partial_symbols (struct objfile *o
prev_textlow_not_set = textlow_not_set;
-#ifdef SOFUN_ADDRESS_MAYBE_MISSING
/* A zero value is probably an indication for the SunPRO 3.0
compiler. end_psymtab explicitly tests for zero, so
don't relocate it. */
- if (sh.value == 0)
+ if (sh.value == 0
+ && gdbarch_sofun_address_maybe_missing
+ (current_gdbarch))
{
textlow_not_set = 1;
valu = 0;
}
else
textlow_not_set = 0;
-#else
- textlow_not_set = 0;
-#endif
+
past_first_source_file = 1;
if (prev_so_symnum != symnum - 1)
@@ -3225,19 +3224,19 @@ parse_partial_symbols (struct objfile *o
continue;
case N_ENDM:
-#ifdef SOFUN_ADDRESS_MAYBE_MISSING
/* Solaris 2 end of module, finish current partial
symbol table. END_PSYMTAB will set
pst->texthigh to the proper value, which is
necessary if a module compiled without
debugging info follows this module. */
- if (pst)
+ if (pst
+ && gdbarch_sofun_address_maybe_missing
+ (current_gdbarch))
{
pst = (struct partial_symtab *) 0;
includes_used = 0;
dependencies_used = 0;
}
-#endif
continue;
case N_RBRAC:
diff -urNp gdb-orig/gdb/minsyms.c gdb-head/gdb/minsyms.c
--- gdb-orig/gdb/minsyms.c 2007-10-05 14:54:47.000000000 +0200
+++ gdb-head/gdb/minsyms.c 2007-10-05 17:55:13.871057253 +0200
@@ -165,14 +165,12 @@ lookup_minimal_symbol (const char *name,
unsigned int hash = msymbol_hash (name) % MINIMAL_SYMBOL_HASH_SIZE;
unsigned int dem_hash = msymbol_hash_iw (name) % MINIMAL_SYMBOL_HASH_SIZE;
-#ifdef SOFUN_ADDRESS_MAYBE_MISSING
if (sfile != NULL)
{
char *p = strrchr (sfile, '/');
if (p != NULL)
sfile = p + 1;
}
-#endif
for (objfile = object_files;
objfile != NULL && found_symbol == NULL;
@@ -209,18 +207,9 @@ lookup_minimal_symbol (const char *name,
case mst_file_text:
case mst_file_data:
case mst_file_bss:
-#ifdef SOFUN_ADDRESS_MAYBE_MISSING
if (sfile == NULL
|| strcmp (msymbol->filename, sfile) == 0)
found_file_symbol = msymbol;
-#else
- /* We have neither the ability nor the need to
- deal with the SFILE parameter. If we find
- more than one symbol, just return the latest
- one (the user can't expect useful behavior in
- that case). */
- found_file_symbol = msymbol;
-#endif
break;
case mst_solib_trampoline:
diff -urNp gdb-orig/gdb/rs6000-tdep.c gdb-head/gdb/rs6000-tdep.c
--- gdb-orig/gdb/rs6000-tdep.c 2007-10-05 14:54:47.000000000 +0200
+++ gdb-head/gdb/rs6000-tdep.c 2007-10-05 17:55:13.882055668 +0200
@@ -3739,6 +3739,10 @@ rs6000_gdbarch_init (struct gdbarch_info
set_gdbarch_inner_than (gdbarch, core_addr_lessthan);
set_gdbarch_breakpoint_from_pc (gdbarch, rs6000_breakpoint_from_pc);
+ /* The value of symbols of type N_SO and N_FUN maybe null when
+ it shouldn't be. */
+ set_gdbarch_sofun_address_maybe_missing (gdbarch, 1);
+
/* Handles single stepping of atomic sequences. */
set_gdbarch_software_single_step (gdbarch, deal_with_atomic_sequence);
diff -urNp gdb-orig/gdb/sparc64-sol2-tdep.c gdb-head/gdb/sparc64-sol2-tdep.c
--- gdb-orig/gdb/sparc64-sol2-tdep.c 2007-10-05 17:55:08.036967473 +0200
+++ gdb-head/gdb/sparc64-sol2-tdep.c 2007-10-05 17:55:13.921050051 +0200
@@ -157,6 +157,11 @@ sparc64_sol2_init_abi (struct gdbarch_in
sparc64_init_abi (info, gdbarch);
+ /* The Sun compilers (Sun ONE Studio, Forte Developer, Sun WorkShop, SunPRO)
+ compiler puts out 0 instead of the address in N_SO stabs. Starting with
+ SunPRO 3.0, the compiler does this for N_FUN stabs too. */
+ set_gdbarch_sofun_address_maybe_missing (gdbarch, 1);
+
/* The Sun compilers also do "globalization"; see the comment in
sparc_sol2_static_transform_name for more information. */
set_gdbarch_static_transform_name
diff -urNp gdb-orig/gdb/sparc-sol2-tdep.c gdb-head/gdb/sparc-sol2-tdep.c
--- gdb-orig/gdb/sparc-sol2-tdep.c 2007-10-05 17:55:08.041966753 +0200
+++ gdb-head/gdb/sparc-sol2-tdep.c 2007-10-05 17:55:13.925049475 +0200
@@ -206,6 +206,11 @@ sparc32_sol2_init_abi (struct gdbarch_in
{
struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
+ /* The Sun compilers (Sun ONE Studio, Forte Developer, Sun WorkShop, SunPRO)
+ compiler puts out 0 instead of the address in N_SO stabs. Starting with
+ SunPRO 3.0, the compiler does this for N_FUN stabs too. */
+ set_gdbarch_sofun_address_maybe_missing (gdbarch, 1);
+
/* The Sun compilers also do "globalization"; see the comment in
sparc_sol2_static_transform_name for more information. */
set_gdbarch_static_transform_name
diff -urNp gdb-orig/gdb/symmisc.c gdb-head/gdb/symmisc.c
--- gdb-orig/gdb/symmisc.c 2007-10-05 14:54:47.000000000 +0200
+++ gdb-head/gdb/symmisc.c 2007-10-05 17:55:13.931048610 +0200
@@ -356,10 +356,8 @@ dump_msymbols (struct objfile *objfile,
{
fprintf_filtered (outfile, " %s", SYMBOL_DEMANGLED_NAME (msymbol));
}
-#ifdef SOFUN_ADDRESS_MAYBE_MISSING
if (msymbol->filename)
fprintf_filtered (outfile, " %s", msymbol->filename);
-#endif
fputs_filtered ("\n", outfile);
}
if (objfile->minimal_symbol_count != index)
diff -urNp gdb-orig/gdb/symtab.h gdb-head/gdb/symtab.h
--- gdb-orig/gdb/symtab.h 2007-10-05 14:54:47.000000000 +0200
+++ gdb-head/gdb/symtab.h 2007-10-05 17:55:13.937047746 +0200
@@ -345,10 +345,8 @@ struct minimal_symbol
unsigned long size;
-#ifdef SOFUN_ADDRESS_MAYBE_MISSING
/* Which source file is this symbol in? Only relevant for mst_file_*. */
char *filename;
-#endif
/* Classification type for this minimal symbol. */
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [rfc/rft] [3/3] Remove stabs target macros: SOFUN_ADDRESS_MAYBE_MISSING
2007-10-05 18:06 [rfc/rft] [3/3] Remove stabs target macros: SOFUN_ADDRESS_MAYBE_MISSING Ulrich Weigand
@ 2007-10-06 7:16 ` Eli Zaretskii
2007-10-08 11:19 ` Ulrich Weigand
0 siblings, 1 reply; 10+ messages in thread
From: Eli Zaretskii @ 2007-10-06 7:16 UTC (permalink / raw)
To: Ulrich Weigand; +Cc: gdb-patches
> Date: Fri, 5 Oct 2007 20:06:20 +0200 (CEST)
> From: "Ulrich Weigand" <uweigand@de.ibm.com>
>
> this removes the SOFUN_ADDRESS_MAYBE_MISSING target macro. There are
> two main parts to this:
>
> - struct minimal_symbol used to have the member "filename" present
> only when SOFUN_ADDRESS_MAYBE_MISSING was true. The patch changes
> this to make the member always available. Code used to initialize
> and use those filenames is now also enabled unconditionally. (This
> should not actually change the behaviour of GDB on any target.)
>
> - Instead of the SOFUN_ADDRESS_MAYBE_MISSING macro, a new gdbarch
> variable gdbarch_sofun_address_maybe_missing is introduces. All
> places where GDB behaviour depended on SOFUN_ADDRESS_MAYBE_MISSING
> now look at that gdbarch variable instead.
Thanks.
> doc/ChangeLog:
>
> * gdbint.texinfo: Document gdbarch_sofun_address_maybe_missing
> instead of SOFUN_ADDRESS_MAYBE_MISSING.
This part is almost okay; I have a few minor comments:
. The ChangeLog entry needs to state the name(s) of the node(s) where
you make the changes (in parens, as if they were names of
functions).
. Please put the function prototypes where you describe them. For
example:
> -@item SOFUN_ADDRESS_MAYBE_MISSING
> -@findex SOFUN_ADDRESS_MAYBE_MISSING
> +@item int gdbarch_sofun_address_maybe_missing
> +@findex gdbarch_sofun_address_maybe_missing
The old SOFUN_ADDRESS_MAYBE_MISSING was a macro without arguments, but
the new gdbarch_sofun_address_maybe_missing is a function that accepts
arguments. The @item line should show the full prototype of the
function, including the type(s) of its argument(s).
. Some of the changes were too mechanical: replacing a macro with a
function sometimes needs more elaborate changes in the text to
avoid unclear or incorrect wording:
> -@code{SOFUN_ADDRESS_MAYBE_MISSING} indicates that a particular set of
> +@code{gdbarch_sofun_address_maybe_missing} indicates that a particular set of
A function cannot _indicate_ anything, it can return a value that
indicates something. (The old text was correct because the macro was
used in an #ifdef at compile time.)
> -@code{SOFUN_ADDRESS_MAYBE_MISSING} means two things:
> +@code{gdbarch_sofun_address_maybe_missing} means two things:
Again, a function cannot _mean_ anything; please rephrase.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [rfc/rft] [3/3] Remove stabs target macros: SOFUN_ADDRESS_MAYBE_MISSING
2007-10-06 7:16 ` Eli Zaretskii
@ 2007-10-08 11:19 ` Ulrich Weigand
2007-10-08 23:17 ` Eli Zaretskii
0 siblings, 1 reply; 10+ messages in thread
From: Ulrich Weigand @ 2007-10-08 11:19 UTC (permalink / raw)
To: eliz; +Cc: gdb-patches
Eli Zaretskii wrote;
> This part is almost okay; I have a few minor comments:
>
> . The ChangeLog entry needs to state the name(s) of the node(s) where
> you make the changes (in parens, as if they were names of
> functions).
Sure, I'll do that.
> . Please put the function prototypes where you describe them. For
> example:
>
> > -@item SOFUN_ADDRESS_MAYBE_MISSING
> > -@findex SOFUN_ADDRESS_MAYBE_MISSING
> > +@item int gdbarch_sofun_address_maybe_missing
> > +@findex gdbarch_sofun_address_maybe_missing
>
> The old SOFUN_ADDRESS_MAYBE_MISSING was a macro without arguments, but
> the new gdbarch_sofun_address_maybe_missing is a function that accepts
> arguments. The @item line should show the full prototype of the
> function, including the type(s) of its argument(s).
Well, the sofun_address_maybe_missing gdbarch entry is of type "v",
i.e. it is a simple variable of type "int", not a function.
That means the argument to set_gdbarch_sofun_address_maybe_missing
is a simple boolean. I had thought the documentation for gdbarch
entries should refer to the entity that you pass to the set_gdbarch_
function; after all that is what the -tdep.c programmer writes.
On the other hand, the accessor function gdbarch_sofun_address_maybe_missing
does have an argument, namely the gdbarch that is being queried. I see
that some of the other entries do show these arguments, so you could say
it should be added in the case as well.
I guess the question is, what is the entity that the documentation
should specify for gdbarch entries:
- the gdbarch_... accessor function
or
- the argument passed to the set_gdbarch_... routine
I'll be happy to do it either way, please let me know which you prefer.
> . Some of the changes were too mechanical: replacing a macro with a
> function sometimes needs more elaborate changes in the text to
> avoid unclear or incorrect wording:
This is because I was describing a boolean "int" value, not a
function. If we're to describe the access functions, that needs
to be rephrased accordingly, of course.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [rfc/rft] [3/3] Remove stabs target macros: SOFUN_ADDRESS_MAYBE_MISSING
2007-10-08 11:19 ` Ulrich Weigand
@ 2007-10-08 23:17 ` Eli Zaretskii
2007-10-09 19:55 ` Ulrich Weigand
0 siblings, 1 reply; 10+ messages in thread
From: Eli Zaretskii @ 2007-10-08 23:17 UTC (permalink / raw)
To: Ulrich Weigand; +Cc: gdb-patches
> Date: Mon, 8 Oct 2007 13:19:36 +0200 (CEST)
> From: "Ulrich Weigand" <uweigand@de.ibm.com>
> Cc: gdb-patches@sourceware.org
>
> > . Please put the function prototypes where you describe them. For
> > example:
> >
> > > -@item SOFUN_ADDRESS_MAYBE_MISSING
> > > -@findex SOFUN_ADDRESS_MAYBE_MISSING
> > > +@item int gdbarch_sofun_address_maybe_missing
> > > +@findex gdbarch_sofun_address_maybe_missing
> >
> > The old SOFUN_ADDRESS_MAYBE_MISSING was a macro without arguments, but
> > the new gdbarch_sofun_address_maybe_missing is a function that accepts
> > arguments. The @item line should show the full prototype of the
> > function, including the type(s) of its argument(s).
>
> Well, the sofun_address_maybe_missing gdbarch entry is of type "v",
> i.e. it is a simple variable of type "int", not a function.
Okay, that means my example was chosen wrongly (but please do state
somewhere that this is a variable). However, IIRC you have other
changes where a macro is replaced with a function, but arguments of
that function are not shown, and that's what I'd like you to fix. A
reader of the manual should not need to consult sources to understand
how to define such a function.
> I guess the question is, what is the entity that the documentation
> should specify for gdbarch entries:
>
> - the gdbarch_... accessor function
> or
> - the argument passed to the set_gdbarch_... routine
Whatever replaced the old macro should be documented in its stead. I
thought you replaced macros with functions, but maybe I misunderstood.
> > . Some of the changes were too mechanical: replacing a macro with a
> > function sometimes needs more elaborate changes in the text to
> > avoid unclear or incorrect wording:
>
> This is because I was describing a boolean "int" value, not a
> function.
I think I saw such problems with functions as well. But if you state
clearly which ones are variables, I'll be glad to review the patch
again.
Thanks.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [rfc/rft] [3/3] Remove stabs target macros: SOFUN_ADDRESS_MAYBE_MISSING
2007-10-08 23:17 ` Eli Zaretskii
@ 2007-10-09 19:55 ` Ulrich Weigand
2007-10-09 23:29 ` Eli Zaretskii
0 siblings, 1 reply; 10+ messages in thread
From: Ulrich Weigand @ 2007-10-09 19:55 UTC (permalink / raw)
To: eliz; +Cc: gdb-patches
Eli Zaretskii wrote:
> > Well, the sofun_address_maybe_missing gdbarch entry is of type "v",
> > i.e. it is a simple variable of type "int", not a function.
>
> Okay, that means my example was chosen wrongly (but please do state
> somewhere that this is a variable). However, IIRC you have other
> changes where a macro is replaced with a function, but arguments of
> that function are not shown, and that's what I'd like you to fix. A
> reader of the manual should not need to consult sources to understand
> how to define such a function.
SOFUN_ADDRESS_MAYBE_MISSING is the only doc change in this patch.
(In another patch there was a function, but as far as I can see I've
left the argument in there ...).
> > I guess the question is, what is the entity that the documentation
> > should specify for gdbarch entries:
> >
> > - the gdbarch_... accessor function
> > or
> > - the argument passed to the set_gdbarch_... routine
>
> Whatever replaced the old macro should be documented in its stead. I
> thought you replaced macros with functions, but maybe I misunderstood.
This is not quite how the gdbarch mechanism works. In the old style,
you have a macro (function-like or not) that is defined in a header file,
and used -under the same name- in GDB source code.
The new gdbarch mechanism replaces those global macros with entries
in a data structure; and provides accessor functions to set and query
those values. These also come in different variants for function-like
and variable-like entities.
For a function-like gdbarch parameter, there is a set_gdbarch_... routine
that the architecture-specific part calls, passing in a funtion pointer to
the actual implementation of that routine. There is also an gdbarch_...
accessor routine that calls the appropriate implementation. (Both of these
are automatically generated by the gdbarch script.)
For a variable-like gdbarch parameter, the set_gdbarch_... routine is called
simply with the value of the parameter for this platform. The gdbarch_...
accessor routine just returns that value.
That means for the writer of the target-dependent code, instead of defining
a macro in a tm-*.h header file, they need to call the appropriate
set_gdbarch_... routine in their target's gdbarch_init routine. If they
want to *use* the architecture-specific setting, instead of just refering
to the macro, they'll have to call the appropriate gdbarch_... accessor.
In the current example, instead of placing
#define SOFUN_ADDRESS_MAYBE_MISSING
in a tm-*.h header file, you'd have to call
set_gdbarch_sofun_address_maybe_missing (gdbarch, 1);
in your gdbarch_init routine.
Instead of checking for
#ifdef SOFUN_ADDRESS_MAYBE_MISSING
you'd have to use something along the lines of
if (gdbarch_sofun_address_maybe_missing (gdbarch))
For a typical case of a function-like gdbarch parameter, e.g. register_name,
you used to have a target macro
#define REGISTER_NAME(regnr) ...
This was replaced by defining a local function, e.g.
static const char *
my_register_name (int regnr) { ... }
and registering it in the gdbarch_init routine:
set_gdbarch_register_name (gdbarch, my_register_name);
To *use* that gdbarch parameter, you'd have to call the accessor routine
const char *gdbarch_register_name (struct gdbarch *gdbarch, int regnr);
Overall, the one entity (macro) has been replaced by really *three*
entities: the gdbarch parameter as stored in the gdbarch structure
(which may be either a variable or a function, but is never directly
visible to the programmer), and the set_gdbarch_... and gdbarch_...
accessor functions (which themselves are always functions, but may
take different arguments depending on the type of the underlying
gdbarch parameter).
Now, all of this isn't really anything new, that's how gdbarch has
been working for many years now. But the associated documentation
looks like it doesn't quite reflect that change in a really consistent
manner, that's why I was asking how it *should* be ...
From looking at other the documentation of other entries, most appear
to refer to the accessor function. The analogous doc for the
sofun_address_maybe_missing case could read something like:
--- gdb-orig/gdb/doc/gdbint.texinfo 2007-10-05 18:19:25.000000000 +0200
+++ gdb-head/gdb/doc/gdbint.texinfo 2007-10-09 21:45:12.795269867 +0200
@@ -3847,21 +3847,22 @@
the next instruction. See @file{sparc-tdep.c} and @file{rs6000-tdep.c}
for examples.
-@item SOFUN_ADDRESS_MAYBE_MISSING
-@findex SOFUN_ADDRESS_MAYBE_MISSING
+@item int gdbarch_sofun_address_maybe_missing (@var{gdbarch})
+@findex gdbarch_sofun_address_maybe_missing
Somebody clever observed that, the more actual addresses you have in the
debug information, the more time the linker has to spend relocating
them. So whenever there's some other way the debugger could find the
address it needs, you should omit it from the debug info, to make
linking faster.
-@code{SOFUN_ADDRESS_MAYBE_MISSING} indicates that a particular set of
-hacks of this sort are in use, affecting @code{N_SO} and @code{N_FUN}
-entries in stabs-format debugging information. @code{N_SO} stabs mark
-the beginning and ending addresses of compilation units in the text
-segment. @code{N_FUN} stabs mark the starts and ends of functions.
+@code{gdbarch_sofun_address_maybe_missing} returns a non-zero value
+to indicate that a particular set of hacks of this sort are in use,
+affecting @code{N_SO} and @code{N_FUN} entries in stabs-format
+debugging information. @code{N_SO} stabs mark the beginning and
+ending addresses of compilation units in the text segment.
+@code{N_FUN} stabs mark the starts and ends of functions.
-@code{SOFUN_ADDRESS_MAYBE_MISSING} means two things:
+If @code{gdbarch_sofun_address_maybe_missing} returns non-zero:
@itemize @bullet
@item
What I find a litte bit odd about documenting gdbarch routines this
way is that the typical writer of platform-specific GDB code will
never actually use this accessor function. For them, the important
question is whether or not to *set* that parameter in their gdbarch
init function ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [rfc/rft] [3/3] Remove stabs target macros: SOFUN_ADDRESS_MAYBE_MISSING
2007-10-09 19:55 ` Ulrich Weigand
@ 2007-10-09 23:29 ` Eli Zaretskii
2007-10-14 20:32 ` Ulrich Weigand
0 siblings, 1 reply; 10+ messages in thread
From: Eli Zaretskii @ 2007-10-09 23:29 UTC (permalink / raw)
To: Ulrich Weigand; +Cc: gdb-patches
> Date: Tue, 9 Oct 2007 21:50:36 +0200 (CEST)
> From: "Ulrich Weigand" <uweigand@de.ibm.com>
> Cc: gdb-patches@sourceware.org
>
> That means for the writer of the target-dependent code, instead of defining
> a macro in a tm-*.h header file, they need to call the appropriate
> set_gdbarch_... routine in their target's gdbarch_init routine. If they
> want to *use* the architecture-specific setting, instead of just refering
> to the macro, they'll have to call the appropriate gdbarch_... accessor.
>
> In the current example, instead of placing
> #define SOFUN_ADDRESS_MAYBE_MISSING
> in a tm-*.h header file, you'd have to call
> set_gdbarch_sofun_address_maybe_missing (gdbarch, 1);
> in your gdbarch_init routine.
>
> Instead of checking for
> #ifdef SOFUN_ADDRESS_MAYBE_MISSING
> you'd have to use something along the lines of
> if (gdbarch_sofun_address_maybe_missing (gdbarch))
In this case, the manual should say something like this:
@item set_gdbarch_sofun_address_maybe_missing (@var{arch}, @var{set})
Calling this with a non-zero argument @var{set} in @code{gdbarch_init}
tells @value{GDBN} that the architecture @var{arch} uses a particular
set of hacks of this sort ...
That is, we need to tell the reader what to put in the code she
writes, not how will the GDB code test for that feature. (It is
possible to _also_ describe the latter for completeness, but the
former _must_ be described.)
> For a typical case of a function-like gdbarch parameter, e.g. register_name,
> you used to have a target macro
> #define REGISTER_NAME(regnr) ...
>
> This was replaced by defining a local function, e.g.
>
> static const char *
> my_register_name (int regnr) { ... }
>
> and registering it in the gdbarch_init routine:
>
> set_gdbarch_register_name (gdbarch, my_register_name);
>
> To *use* that gdbarch parameter, you'd have to call the accessor routine
>
> const char *gdbarch_register_name (struct gdbarch *gdbarch, int regnr);
Again, the manual should first and foremost describe what the
architecture maintainer needs to do to get support for register names.
Something like this:
@item set_gdbarch_register_name (@var{arch}, @var{func})
Call this function to register @var{func} as the callback that
returns the name of a register for the architecture @var{arch}.
@var{func} should be written according to the following prototype:
@smallexample
static const char *@var{func} (int @var{regno});
@end smallexample
@noindent
It will be called with the argument @var{regno} set to the number of
the register whose name is required.
Optionally, you can also say
To retrieve the register name, call @code{gdbarch_register_name} and
pass it the register number as its second argument.
@code{gdbarch_register_name} will call your registered @var{func}
internally.
> Overall, the one entity (macro) has been replaced by really *three*
> entities: the gdbarch parameter as stored in the gdbarch structure
> (which may be either a variable or a function, but is never directly
> visible to the programmer)
I think the second example above demonstrates that for the function
case, the parameter _is_ visible to the programmer, since the
programmer needs to implement that function and register it, right?
> >From looking at other the documentation of other entries, most appear
> to refer to the accessor function. The analogous doc for the
> sofun_address_maybe_missing case could read something like:
>
> --- gdb-orig/gdb/doc/gdbint.texinfo 2007-10-05 18:19:25.000000000 +0200
> +++ gdb-head/gdb/doc/gdbint.texinfo 2007-10-09 21:45:12.795269867 +0200
> @@ -3847,21 +3847,22 @@
> the next instruction. See @file{sparc-tdep.c} and @file{rs6000-tdep.c}
> for examples.
>
> -@item SOFUN_ADDRESS_MAYBE_MISSING
> -@findex SOFUN_ADDRESS_MAYBE_MISSING
> +@item int gdbarch_sofun_address_maybe_missing (@var{gdbarch})
> +@findex gdbarch_sofun_address_maybe_missing
> Somebody clever observed that, the more actual addresses you have in the
> debug information, the more time the linker has to spend relocating
> them. So whenever there's some other way the debugger could find the
> address it needs, you should omit it from the debug info, to make
> linking faster.
>
> -@code{SOFUN_ADDRESS_MAYBE_MISSING} indicates that a particular set of
> -hacks of this sort are in use, affecting @code{N_SO} and @code{N_FUN}
> -entries in stabs-format debugging information. @code{N_SO} stabs mark
> -the beginning and ending addresses of compilation units in the text
> -segment. @code{N_FUN} stabs mark the starts and ends of functions.
> +@code{gdbarch_sofun_address_maybe_missing} returns a non-zero value
> +to indicate that a particular set of hacks of this sort are in use,
> +affecting @code{N_SO} and @code{N_FUN} entries in stabs-format
> +debugging information. @code{N_SO} stabs mark the beginning and
> +ending addresses of compilation units in the text segment.
> +@code{N_FUN} stabs mark the starts and ends of functions.
You see, this is backwards: this section of the manual intends to
explain how to write target-specific back-end, but the text you
suggested actually ends up saying nothing at all about that. Instead,
it says how GDB would use the definition to figure out what the target
needs or does. That's not what we want.
> What I find a litte bit odd about documenting gdbarch routines this
> way is that the typical writer of platform-specific GDB code will
> never actually use this accessor function. For them, the important
> question is whether or not to *set* that parameter in their gdbarch
> init function ...
Exactly.
So you see that converting the old macro-oriented docs to the new one
is hardly a trivial mechanical job. It needs much more thinking and
creative rewriting. Let's try to make this right this time, even if
the other places where macros were replaced by gdbarch functions do it
wrong. (I will add to my TODO an item to review the other places and
correct whatever needs correction.)
Thanks for taking time to explain this!
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [rfc/rft] [3/3] Remove stabs target macros: SOFUN_ADDRESS_MAYBE_MISSING
2007-10-09 23:29 ` Eli Zaretskii
@ 2007-10-14 20:32 ` Ulrich Weigand
2007-10-14 22:16 ` Eli Zaretskii
0 siblings, 1 reply; 10+ messages in thread
From: Ulrich Weigand @ 2007-10-14 20:32 UTC (permalink / raw)
To: eliz; +Cc: gdb-patches
Eli Zaretskii wrote:
> So you see that converting the old macro-oriented docs to the new one
> is hardly a trivial mechanical job. It needs much more thinking and
> creative rewriting. Let's try to make this right this time, even if
> the other places where macros were replaced by gdbarch functions do it
> wrong. (I will add to my TODO an item to review the other places and
> correct whatever needs correction.)
Would the following wording for the SOFUN_ADDRESS_MAYBE_MISSING change
be OK? I've moved the new text from the generic "Target Conditionals"
section to the "Compiler Characteristics" section, both to indicate that
the new style of documentation doesn't match the rest of the Target
Conditionals section any more, and because it seems to fit there better
anyway ...
Bye,
Ulrich
ChangeLog:
* gdbarch.texi (Target Conditionals): Remove documentation of
SOFUN_ADDRESS_MAYBE_MISSING, replaced by ...
(Compiler Characteristics): ... documentation of
set_gdbarch_sofun_address_maybe_missing.
diff -urNp gdb-orig/gdb/doc/gdbint.texinfo gdb-head/gdb/doc/gdbint.texinfo
--- gdb-orig/gdb/doc/gdbint.texinfo 2007-10-13 02:05:34.000000000 +0200
+++ gdb-head/gdb/doc/gdbint.texinfo 2007-10-14 22:07:50.003214603 +0200
@@ -3264,6 +3264,37 @@ See @file{mips-tdep.c}. It does not do
@node Compiler Characteristics
@section Compiler Characteristics
+@item set_gdbarch_sofun_address_maybe_missing (@var{gdbarch}, @var{set})
+@findex set_gdbarch_sofun_address_maybe_missing
+Somebody clever observed that, the more actual addresses you have in the
+debug information, the more time the linker has to spend relocating
+them. So whenever there's some other way the debugger could find the
+address it needs, you should omit it from the debug info, to make
+linking faster.
+
+Calling @code{set_gdbarch_sofun_address_maybe_missing} with a non-zero
+argument @var{set} indicates that a particular set of hacks of this sort
+are in use, affecting @code{N_SO} and @code{N_FUN} entries in stabs-format
+debugging information. @code{N_SO} stabs mark the beginning and ending
+addresses of compilation units in the text segment. @code{N_FUN} stabs
+mark the starts and ends of functions.
+
+In this case, @value{GDBN} assumes two things:
+
+@itemize @bullet
+@item
+@code{N_FUN} stabs have an address of zero. Instead, you should find the
+addresses where the function starts by taking the function name from the
+stab, and then looking that up in the minsyms (the linker/assembler symbol
+table). In other words, the stab has the name, and the linker/assembler
+symbol table is the only place that carries the address.
+
+@item
+@code{N_SO} stabs have an address of zero, too. You just look at the
+@code{N_FUN} stabs that appear before and after the @code{N_SO} stab, and
+guess the starting and ending addresses of the compilation unit from them.
+@end itemize
+
@node Target Conditionals
@section Target Conditionals
@@ -3825,38 +3856,6 @@ A function that inserts or removes (depe
the next instruction. See @file{sparc-tdep.c} and @file{rs6000-tdep.c}
for examples.
-@item SOFUN_ADDRESS_MAYBE_MISSING
-@findex SOFUN_ADDRESS_MAYBE_MISSING
-Somebody clever observed that, the more actual addresses you have in the
-debug information, the more time the linker has to spend relocating
-them. So whenever there's some other way the debugger could find the
-address it needs, you should omit it from the debug info, to make
-linking faster.
-
-@code{SOFUN_ADDRESS_MAYBE_MISSING} indicates that a particular set of
-hacks of this sort are in use, affecting @code{N_SO} and @code{N_FUN}
-entries in stabs-format debugging information. @code{N_SO} stabs mark
-the beginning and ending addresses of compilation units in the text
-segment. @code{N_FUN} stabs mark the starts and ends of functions.
-
-@code{SOFUN_ADDRESS_MAYBE_MISSING} means two things:
-
-@itemize @bullet
-@item
-@code{N_FUN} stabs have an address of zero. Instead, you should find the
-addresses where the function starts by taking the function name from
-the stab, and then looking that up in the minsyms (the
-linker/assembler symbol table). In other words, the stab has the
-name, and the linker/assembler symbol table is the only place that carries
-the address.
-
-@item
-@code{N_SO} stabs have an address of zero, too. You just look at the
-@code{N_FUN} stabs that appear before and after the @code{N_SO} stab,
-and guess the starting and ending addresses of the compilation unit from
-them.
-@end itemize
-
@item int gdbarch_pc_regnum (@var{gdbarch})
@findex gdbarch_pc_regnum
If the program counter is kept in a register, then let this function return
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [rfc/rft] [3/3] Remove stabs target macros: SOFUN_ADDRESS_MAYBE_MISSING
2007-10-14 20:32 ` Ulrich Weigand
@ 2007-10-14 22:16 ` Eli Zaretskii
2007-10-15 14:10 ` Ulrich Weigand
0 siblings, 1 reply; 10+ messages in thread
From: Eli Zaretskii @ 2007-10-14 22:16 UTC (permalink / raw)
To: Ulrich Weigand; +Cc: gdb-patches
> Date: Sun, 14 Oct 2007 22:13:23 +0200 (CEST)
> From: "Ulrich Weigand" <uweigand@de.ibm.com>
> Cc: gdb-patches@sourceware.org
>
> Would the following wording for the SOFUN_ADDRESS_MAYBE_MISSING change
> be OK?
Yes, but...
> +In this case, @value{GDBN} assumes two things:
> +
> +@itemize @bullet
> +@item
> +@code{N_FUN} stabs have an address of zero. Instead, you should find the
> +addresses where the function starts by taking the function name from the
> +stab, and then looking that up in the minsyms (the linker/assembler symbol
> +table). In other words, the stab has the name, and the linker/assembler
> +symbol table is the only place that carries the address.
I'm confused by the "Instead" thing: instead of what? instead of using
the (otherwise non-zero) address of N_FUN?
Otherwise, it looks okay. Thanks.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [rfc/rft] [3/3] Remove stabs target macros: SOFUN_ADDRESS_MAYBE_MISSING
2007-10-14 22:16 ` Eli Zaretskii
@ 2007-10-15 14:10 ` Ulrich Weigand
2007-10-15 17:53 ` Eli Zaretskii
0 siblings, 1 reply; 10+ messages in thread
From: Ulrich Weigand @ 2007-10-15 14:10 UTC (permalink / raw)
To: eliz; +Cc: gdb-patches
Eli Zaretskii wrote:
> > +@code{N_FUN} stabs have an address of zero. Instead, you should find the
> > +addresses where the function starts by taking the function name from the
> > +stab, and then looking that up in the minsyms (the linker/assembler symbol
> > +table). In other words, the stab has the name, and the linker/assembler
> > +symbol table is the only place that carries the address.
>
> I'm confused by the "Instead" thing: instead of what? instead of using
> the (otherwise non-zero) address of N_FUN?
Yes, exactly. Do you feel this needs to be clarified?
"Instead of using this address, you should find ..." ?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [rfc/rft] [3/3] Remove stabs target macros: SOFUN_ADDRESS_MAYBE_MISSING
2007-10-15 14:10 ` Ulrich Weigand
@ 2007-10-15 17:53 ` Eli Zaretskii
0 siblings, 0 replies; 10+ messages in thread
From: Eli Zaretskii @ 2007-10-15 17:53 UTC (permalink / raw)
To: Ulrich Weigand; +Cc: gdb-patches
> Date: Mon, 15 Oct 2007 15:50:09 +0200 (CEST)
> From: "Ulrich Weigand" <uweigand@de.ibm.com>
> Cc: gdb-patches@sourceware.org
>
> > I'm confused by the "Instead" thing: instead of what? instead of using
> > the (otherwise non-zero) address of N_FUN?
>
> Yes, exactly. Do you feel this needs to be clarified?
>
> "Instead of using this address, you should find ..." ?
Yes, please.
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2007-10-15 17:34 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-10-05 18:06 [rfc/rft] [3/3] Remove stabs target macros: SOFUN_ADDRESS_MAYBE_MISSING Ulrich Weigand
2007-10-06 7:16 ` Eli Zaretskii
2007-10-08 11:19 ` Ulrich Weigand
2007-10-08 23:17 ` Eli Zaretskii
2007-10-09 19:55 ` Ulrich Weigand
2007-10-09 23:29 ` Eli Zaretskii
2007-10-14 20:32 ` Ulrich Weigand
2007-10-14 22:16 ` Eli Zaretskii
2007-10-15 14:10 ` Ulrich Weigand
2007-10-15 17:53 ` Eli Zaretskii
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox