From: Jim Blandy <jimb@zwingli.cygnus.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [PING][RFA] Fall back on dynamic symtab in solib.c:bdf_lookup_symbol
Date: Fri, 04 Aug 2000 14:43:00 -0000 [thread overview]
Message-ID: <npog3ikmuy.fsf@zwingli.cygnus.com> (raw)
In-Reply-To: <200007270710.e6R7AjS00711@delius.kettenis.local>
> I'm still looking for approval of the following patch:
>
> http://sources.redhat.com/ml/gdb-patches/2000-05/msg00318.html
>
> Mark
Sorry about the delay. If this causes no test suite failures, then
it's fine to commit it.
From greg@mcgary.org Fri Aug 04 14:53:00 2000
From: Greg McGary <greg@mcgary.org>
To: gdb-patches@sourceware.cygnus.com
Subject: PATCH: fix crashes in partial-stab.h for BP programs
Date: Fri, 04 Aug 2000 14:53:00 -0000
Message-id: <200008042153.OAA22500@kayak.mcgary.org>
X-SW-Source: 2000-08/msg00107.html
Content-length: 1325
Programs built with bounded pointers
(see http://gcc.gnu.org/projects/bp/main.html )
cause indigestion for gdb because these code paths
are exercised with pst==NULL.
I don't claim to understand anything about this code, or the
implications of pst==NULL, but I do notice that many other places in
this file guard uses of pst with a check for NULL.
Greg
Index: gdb/partial-stab.h
===================================================================
RCS file: /cvs/src/src/gdb/partial-stab.h,v
retrieving revision 1.3
diff -u -p -r1.3 partial-stab.h
--- partial-stab.h 2000/05/04 16:52:33 1.3
+++ partial-stab.h 2000/08/04 19:42:04
@@ -401,7 +401,7 @@ switch (CUR_SYMBOL_TYPE)
function relative stabs, or the address of the function's
end for old style stabs. */
valu = CUR_SYMBOL_VALUE + last_function_start;
- if (pst->texthigh == 0 || valu > pst->texthigh)
+ if (pst && (pst->texthigh == 0 || valu > pst->texthigh))
pst->texthigh = valu;
break;
}
@@ -647,7 +647,7 @@ switch (CUR_SYMBOL_TYPE)
use the address of this function as the low bound for
the partial symbol table. */
if (textlow_not_set
- || (CUR_SYMBOL_VALUE < pst->textlow
+ || (pst && CUR_SYMBOL_VALUE < pst->textlow
&& CUR_SYMBOL_VALUE
!= ANOFFSET (objfile->section_offsets, SECT_OFF_TEXT (objfile))))
{
From msnyder@redhat.com Fri Aug 04 15:03:00 2000
From: Michael Snyder <msnyder@redhat.com>
To: Greg McGary <greg@mcgary.org>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: PATCH: fix crashes in partial-stab.h for BP programs
Date: Fri, 04 Aug 2000 15:03:00 -0000
Message-id: <398B3D92.1B1A@redhat.com>
References: <200008042153.OAA22500@kayak.mcgary.org>
X-SW-Source: 2000-08/msg00108.html
Content-length: 1702
I think these are good. Unles there's a reason why
we should take more drastic action (issue a warning
or bail) on a null pointer, let's check them in.
Michael
Greg McGary wrote:
>
> Programs built with bounded pointers
> (see http://gcc.gnu.org/projects/bp/main.html )
> cause indigestion for gdb because these code paths
> are exercised with pst==NULL.
>
> I don't claim to understand anything about this code, or the
> implications of pst==NULL, but I do notice that many other places in
> this file guard uses of pst with a check for NULL.
>
> Greg
>
> Index: gdb/partial-stab.h
> ===================================================================
> RCS file: /cvs/src/src/gdb/partial-stab.h,v
> retrieving revision 1.3
> diff -u -p -r1.3 partial-stab.h
> --- partial-stab.h 2000/05/04 16:52:33 1.3
> +++ partial-stab.h 2000/08/04 19:42:04
> @@ -401,7 +401,7 @@ switch (CUR_SYMBOL_TYPE)
> function relative stabs, or the address of the function's
> end for old style stabs. */
> valu = CUR_SYMBOL_VALUE + last_function_start;
> - if (pst->texthigh == 0 || valu > pst->texthigh)
> + if (pst && (pst->texthigh == 0 || valu > pst->texthigh))
> pst->texthigh = valu;
> break;
> }
> @@ -647,7 +647,7 @@ switch (CUR_SYMBOL_TYPE)
> use the address of this function as the low bound for
> the partial symbol table. */
> if (textlow_not_set
> - || (CUR_SYMBOL_VALUE < pst->textlow
> + || (pst && CUR_SYMBOL_VALUE < pst->textlow
> && CUR_SYMBOL_VALUE
> != ANOFFSET (objfile->section_offsets, SECT_OFF_TEXT (objfile))))
> {
From greg@mcgary.org Fri Aug 04 15:13:00 2000
From: Greg McGary <greg@mcgary.org>
To: Michael Snyder <msnyder@redhat.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: PATCH: fix crashes in partial-stab.h for BP programs
Date: Fri, 04 Aug 2000 15:13:00 -0000
Message-id: <ms4s50vfnr.fsf@mcgary.org>
References: <200008042153.OAA22500@kayak.mcgary.org> <398B3D92.1B1A@redhat.com>
X-SW-Source: 2000-08/msg00109.html
Content-length: 288
Michael Snyder <msnyder@redhat.com> writes:
> I think these are good. Unles there's a reason why
> we should take more drastic action (issue a warning
> or bail) on a null pointer, let's check them in.
We definitely shouldn't bail. gdb is very usable on BP programs with
this patch.
From ezannoni@cygnus.com Fri Aug 04 15:20:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: Michael Snyder <msnyder@redhat.com>
Cc: Greg McGary <greg@mcgary.org>, gdb-patches@sourceware.cygnus.com
Subject: Re: PATCH: fix crashes in partial-stab.h for BP programs
Date: Fri, 04 Aug 2000 15:20:00 -0000
Message-id: <14731.16831.916284.571139@kwikemart.cygnus.com>
References: <200008042153.OAA22500@kayak.mcgary.org> <398B3D92.1B1A@redhat.com>
X-SW-Source: 2000-08/msg00110.html
Content-length: 1883
Michael Snyder writes:
> I think these are good. Unles there's a reason why
> we should take more drastic action (issue a warning
> or bail) on a null pointer, let's check them in.
>
> Michael
>
>
Yes go ahead.
Elena
> Greg McGary wrote:
> >
> > Programs built with bounded pointers
> > (see http://gcc.gnu.org/projects/bp/main.html )
> > cause indigestion for gdb because these code paths
> > are exercised with pst==NULL.
> >
> > I don't claim to understand anything about this code, or the
> > implications of pst==NULL, but I do notice that many other places in
> > this file guard uses of pst with a check for NULL.
> >
> > Greg
> >
> > Index: gdb/partial-stab.h
> > ===================================================================
> > RCS file: /cvs/src/src/gdb/partial-stab.h,v
> > retrieving revision 1.3
> > diff -u -p -r1.3 partial-stab.h
> > --- partial-stab.h 2000/05/04 16:52:33 1.3
> > +++ partial-stab.h 2000/08/04 19:42:04
> > @@ -401,7 +401,7 @@ switch (CUR_SYMBOL_TYPE)
> > function relative stabs, or the address of the function's
> > end for old style stabs. */
> > valu = CUR_SYMBOL_VALUE + last_function_start;
> > - if (pst->texthigh == 0 || valu > pst->texthigh)
> > + if (pst && (pst->texthigh == 0 || valu > pst->texthigh))
> > pst->texthigh = valu;
> > break;
> > }
> > @@ -647,7 +647,7 @@ switch (CUR_SYMBOL_TYPE)
> > use the address of this function as the low bound for
> > the partial symbol table. */
> > if (textlow_not_set
> > - || (CUR_SYMBOL_VALUE < pst->textlow
> > + || (pst && CUR_SYMBOL_VALUE < pst->textlow
> > && CUR_SYMBOL_VALUE
> > != ANOFFSET (objfile->section_offsets, SECT_OFF_TEXT (objfile))))
> > {
From ezannoni@cygnus.com Fri Aug 04 15:22:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH RFA] Fixup SYMBOL_SECTION for objfiles_relocate()
Date: Fri, 04 Aug 2000 15:22:00 -0000
Message-id: <14731.16957.294904.738021@kwikemart.cygnus.com>
References: <1000804211627.ZM5495@ocotillo.lan>
X-SW-Source: 2000-08/msg00111.html
Content-length: 6349
Kevin Buettner writes:
> I request permission to commit the patch below.
>
> The OS for the project that I'm working on relocates the read/write
> and the read-only sections by different amounts. Thus it is critical
> that objfile_relocate() actually have correct section indices during
> the relocation process.
>
> I also discovered that for some symbol sym, SYMBOL_SECTION(sym) was
> not providing the correct section index. In fact, it was almost
> always 0. The same was true for partial symbols (upon which the same
> macro magically works) as well.
>
> The reason is that (at least for DWARF2) the SYMBOL_SECTION field
> (section) was simply getting initialized to 0. Furthermore, no
> attempt was made to set things right later on.
>
> The interesting thing is that SYMBOL_BFD_SECTION has exactly same
> problem, but we have some code which attempts to set things right at
> various points along the way. The relevant functions are
> fixup_symbol_section() and fixup_psymbol_section(). It seems to me
> that we ought to be setting SYMBOL_SECTION at the same time that we're
> setting BFD_SECTION and that is what the second hunk in the diff for
> symtab.c is doing below. [Thanks to Elena for bringing this to my
> attention.]
>
> Even once this is done, there is no guarantee that the symbols
> and/or partial symbols will have been fixed up (with respect to
> SYMBOL_SECTION) by the time that objfile_relocate() has been called.
> So... now objfile_relocate() calls fixup_symbol_section() and
> fixup_psymbol_section() as appropriate.
>
> I'm not convinced that fixing these fields up at various random places
> in the code where we need to access these fields is the right approach
> to solving this problem. It seems to me that it would be better to
> attempt to set them correctly at the time that (or perhaps slightly
> after) the symbol (or partial symbol) is created. I made an attempt
> at doing this, but I could not get it to work. (Perhaps the minimal
> symbols weren't available yet?) In any event, this is probably an
> issue that the symbol table maintainers should consider in the future.
> (grep for fixup_symbol_section() and look at all the places that
> it's used.)
>
Yes, this is a cleanup that should be added to the TO DO file.
Andrew, Jimb?
> * symtab.h (fixup_psymbol_section): Declare.
> * symtab.c (fixup_psymbol_section): Make extern.
> (fixup_section): Fix up section as well as bfd_section.
> * objfiles.c (objfile_relocate): Call fixup_symbol_section
> or fixup_psymbol_section before attempting to access
> the SYMBOL_SECTION component of a symbol or partial symbol.
>
I think this is good.
Elena
> Index: objfiles.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/objfiles.c,v
> retrieving revision 1.7
> diff -u -p -r1.7 objfiles.c
> --- objfiles.c 2000/07/30 01:48:26 1.7
> +++ objfiles.c 2000/08/04 20:46:02
> @@ -564,6 +564,9 @@ objfile_relocate (struct objfile *objfil
> for (j = 0; j < BLOCK_NSYMS (b); ++j)
> {
> struct symbol *sym = BLOCK_SYM (b, j);
> +
> + fixup_symbol_section (sym, objfile);
> +
> /* The RS6000 code from which this was taken skipped
> any symbols in STRUCT_NAMESPACE or UNDEF_NAMESPACE.
> But I'm leaving out that test, on the theory that
> @@ -606,15 +609,21 @@ objfile_relocate (struct objfile *objfil
> for (psym = objfile->global_psymbols.list;
> psym < objfile->global_psymbols.next;
> psym++)
> - if (SYMBOL_SECTION (*psym) >= 0)
> - SYMBOL_VALUE_ADDRESS (*psym) += ANOFFSET (delta,
> - SYMBOL_SECTION (*psym));
> + {
> + fixup_psymbol_section (*psym, objfile);
> + if (SYMBOL_SECTION (*psym) >= 0)
> + SYMBOL_VALUE_ADDRESS (*psym) += ANOFFSET (delta,
> + SYMBOL_SECTION (*psym));
> + }
> for (psym = objfile->static_psymbols.list;
> psym < objfile->static_psymbols.next;
> psym++)
> - if (SYMBOL_SECTION (*psym) >= 0)
> - SYMBOL_VALUE_ADDRESS (*psym) += ANOFFSET (delta,
> - SYMBOL_SECTION (*psym));
> + {
> + fixup_psymbol_section (*psym, objfile);
> + if (SYMBOL_SECTION (*psym) >= 0)
> + SYMBOL_VALUE_ADDRESS (*psym) += ANOFFSET (delta,
> + SYMBOL_SECTION (*psym));
> + }
> }
>
> {
> Index: symtab.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/symtab.c,v
> retrieving revision 1.10
> diff -u -p -r1.10 symtab.c
> --- symtab.c 2000/07/30 01:48:27 1.10
> +++ symtab.c 2000/08/04 20:46:07
> @@ -81,10 +81,6 @@ static struct partial_symbol *lookup_par
> const char *, int,
> namespace_enum);
>
> -static struct partial_symbol *fixup_psymbol_section (struct
> - partial_symbol *,
> - struct objfile *);
> -
> static struct symtab *lookup_symtab_1 (char *);
>
> static void cplusplus_hint (char *);
> @@ -520,7 +516,10 @@ fixup_section (struct general_symbol_inf
> msym = lookup_minimal_symbol (ginfo->name, NULL, objfile);
>
> if (msym)
> - ginfo->bfd_section = SYMBOL_BFD_SECTION (msym);
> + {
> + ginfo->bfd_section = SYMBOL_BFD_SECTION (msym);
> + ginfo->section = SYMBOL_SECTION (msym);
> + }
> }
>
> struct symbol *
> @@ -537,7 +536,7 @@ fixup_symbol_section (struct symbol *sym
> return sym;
> }
>
> -static struct partial_symbol *
> +struct partial_symbol *
> fixup_psymbol_section (struct partial_symbol *psym, struct objfile *objfile)
> {
> if (!psym)
> Index: symtab.h
> ===================================================================
> RCS file: /cvs/src/src/gdb/symtab.h,v
> retrieving revision 1.11
> diff -u -p -r1.11 symtab.h
> --- symtab.h 2000/06/05 20:49:53 1.11
> +++ symtab.h 2000/08/04 20:46:09
> @@ -1414,6 +1414,10 @@ extern int in_prologue (CORE_ADDR pc, CO
> extern struct symbol *fixup_symbol_section (struct symbol *,
> struct objfile *);
>
> +extern struct partial_symbol *fixup_psymbol_section (struct partial_symbol
> + *psym,
> + struct objfile *objfile);
> +
> /* Symbol searching */
>
> /* When using search_symbols, a list of the following structs is returned.
>
>
From kevinb@cygnus.com Fri Aug 04 16:17:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: Elena Zannoni <ezannoni@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH RFA] Fixup SYMBOL_SECTION for objfiles_relocate()
Date: Fri, 04 Aug 2000 16:17:00 -0000
Message-id: <1000804231651.ZM5709@ocotillo.lan>
References: <1000804211627.ZM5495@ocotillo.lan> <14731.16957.294904.738021@kwikemart.cygnus.com> <ezannoni@cygnus.com>
X-SW-Source: 2000-08/msg00112.html
Content-length: 452
On Aug 4, 6:22pm, Elena Zannoni wrote:
> > * symtab.h (fixup_psymbol_section): Declare.
> > * symtab.c (fixup_psymbol_section): Make extern.
> > (fixup_section): Fix up section as well as bfd_section.
> > * objfiles.c (objfile_relocate): Call fixup_symbol_section
> > or fixup_psymbol_section before attempting to access
> > the SYMBOL_SECTION component of a symbol or partial symbol.
> >
>
> I think this is good.
Committed.
Kevin
From kevinb@cygnus.com Fri Aug 04 17:01:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH RFC] Protoize ch-exp.c, core-regset.c
Date: Fri, 04 Aug 2000 17:01:00 -0000
Message-id: <1000805000138.ZM5802@ocotillo.lan>
References: <1000803190941.ZM2697@ocotillo.lan> <200008040931.FAA28059@indy.delorie.com> <1000804151730.ZM4041@ocotillo.lan> <200008041810.OAA28507@indy.delorie.com> <eliz@delorie.com>
X-SW-Source: 2000-08/msg00113.html
Content-length: 2328
The previous version of this patch at
http://sources.redhat.com/ml/gdb-patches/2000-08/msg00073.html
is withdrawn.
At Eli Zaretskii's suggestion, I will attempt to move comments about
the parameters out to a comment preceding the function and I will
attempt to write some prefatory material for those functions which are
lacking it. (Just the ones still in need of protoization however; I
don't intend to add a comment for every undocumented function in gdb! :-)
I'll wait another day before committing it.
* ch-exp.c (parse_opt_name_string): Protoize. [Thanks to Eli
Zaretskii for the prefatory comment.]
* core-regset.c (fetch_core_registers): Protoize.
Index: ch-exp.c
===================================================================
RCS file: /cvs/src/src/gdb/ch-exp.c,v
retrieving revision 1.4
diff -u -r1.4 ch-exp.c
--- ch-exp.c 2000/07/30 01:48:24 1.4
+++ ch-exp.c 2000/08/04 23:35:40
@@ -301,9 +301,11 @@
}
#if 0
+/* Parse the name of an option string. If ALLOW_ALL is 1, ALL is
+ allowed as a postfix. */
+
static tree
-parse_opt_name_string (allow_all)
- int allow_all; /* 1 if ALL is allowed as a postfix */
+parse_opt_name_string (int allow_all)
{
int token = PEEK_TOKEN ();
tree name;
Index: core-regset.c
===================================================================
RCS file: /cvs/src/src/gdb/core-regset.c,v
retrieving revision 1.5
diff -u -r1.5 core-regset.c
--- core-regset.c 2000/07/30 01:48:25 1.5
+++ core-regset.c 2000/08/04 23:35:40
@@ -72,7 +72,8 @@
Read the values of either the general register set (WHICH equals 0)
or the floating point register set (WHICH equals 2) from the core
file data (pointed to by CORE_REG_SECT), and update gdb's idea of
- their current values. The CORE_REG_SIZE parameter is ignored.
+ their current values. The CORE_REG_SIZE and REG_ADDR parameters are
+ ignored.
NOTES
@@ -81,11 +82,8 @@
*/
static void
-fetch_core_registers (core_reg_sect, core_reg_size, which, reg_addr)
- char *core_reg_sect;
- unsigned core_reg_size;
- int which;
- CORE_ADDR reg_addr; /* Unused in this version */
+fetch_core_registers (char *core_reg_sect, unsigned core_reg_size, int which,
+ CORE_ADDR reg_addr)
{
#if defined (HAVE_GREGSET_T) && defined (HAVE_FPREGSET_T)
gregset_t gregset;
next parent reply other threads:[~2000-08-04 14:43 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200007270710.e6R7AjS00711@delius.kettenis.local>
2000-08-04 14:43 ` Jim Blandy [this message]
2000-08-07 3:59 ` Mark Kettenis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=npog3ikmuy.fsf@zwingli.cygnus.com \
--to=jimb@zwingli.cygnus.com \
--cc=gdb-patches@sources.redhat.com \
--cc=kettenis@wins.uva.nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox