Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Berlin <dberlin@dberlin.org>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: Jim Blandy <jimb@redhat.com>,
	David Carlton <carlton@math.stanford.edu>,
	<gdb-patches@sources.redhat.com>
Subject: Re: RFA: Search for symbol names the same way they're hashed.
Date: Wed, 02 Oct 2002 16:10:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.44.0210021856210.4265-100000@dberlin.org> (raw)
In-Reply-To: <20021002210413.GA18056@nevyn.them.org>



On Wed, 2 Oct 2002, Daniel Jacobowitz wrote:

> On Wed, Oct 02, 2002 at 04:43:34PM -0400, Daniel Berlin wrote:
> > 
> > On Wednesday, October 2, 2002, at 03:18  PM, Jim Blandy wrote:
> > 
> > >
> > >I just did a quick survey of the uses of SYMBOL_SOURCE_NAME.  They all
> > >fall into two categories:
> > >- printing symbol names, and
> > >- sort comparison functions.
> > >
> > >The first usage is exactly correct: the way a symbol prints should
> > >respect the current demangling setting.
> > >
> > >The second usage seems wrong to me: if you sort under one demangling
> > >setting, but then search under a different one, well, ... duh.
> > 
> > SYMBOL_SOURCE_NAME changes won't help here, it'll only fix half the 
> > problem.
> > 
> > Try setting a demangling style that is wrong (say EDG), then loading a 
> > C++ file (ie reading it's symbols), then setting the right demangling 
> > style.
> > 
> > Observe:
> > [dberlin@dberlin gdb]$ ./gdb
> > GNU gdb 2002-08-15-cvs
> > Copyright 2002 Free Software Foundation, Inc.
> > GDB is free software, covered by the GNU General Public License, and 
> > you are
> > welcome to change it and/or distribute copies of it under certain 
> > conditions.
> > Type "show copying" to see the conditions.
> > There is absolutely no warranty for GDB.  Type "show warranty" for 
> > details.
> > This GDB was configured as "i686-pc-linux-gnu".
> > Setting up the environment for debugging gdb.
> > .gdbinit:5: Error in sourced command file:
> > No symbol table is loaded.  Use the "file" command.
> > (gdb) set demangle-style edg
> > (gdb) file a.out
> > Reading symbols from a.out...done.
> > (gdb) info func bob
> > All functions matching regular expression "bob":
> > 
> > File testcpp.cpp:
> > int _Z3bobv(void);
> > (gdb) set demangle-style gnu
> > gnu     gnu-v3
> > (gdb) set demangle-style gnu-v3
> > (gdb) info func bob
> > All functions matching regular expression "bob":
> > 
> > File testcpp.cpp:
> > int _Z3bobv(void);
> > (gdb) b bob
> > Function "bob" not defined.
> > (gdb)
> > 
> > Even after you set the right demangling style, it's too late.
> > The symbols in the symbol table will have the wrong demangled names, so 
> > even if you made SYMBOL_DEMANGLEST or whatever, it will still be wrong.
> > 
> > We need to make demangling-style only affect *printout* and *user 
> > entered strings*, and during symbol reading, force it to auto, so it 
> > always gets the right names in the symbol table in the first place.
> 
> Doesn't that sort of defeat the point of letting the user set
> demangling style? 

What is your definition of what the demangling style should apply to?

> It's in case something goes wrong with
> autodetection....

Then fix the auto-detection.
Is there an ambiguous case you know of (or anyone, for that matter), or 
is this theoretical? 

The point of set demangle-style, AFAIK, is for assembler printouts.
*Not* for normal source code.

The user, even if they were to set the demangling style, would probably 
not expect it to apply to *all symbol files* loaded after they set it, but 
not those before you set it.

It gives you different behavior if you do "gdb ./testobj", then set the 
demanging style, then if you do "gdb", set the demangling style, then load 
the file.


Watch:
[dberlin@dberlin gdb]$ gdb ./a.out
GNU gdb 5.2.1-2mdk (Mandrake Linux)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you 
are
welcome to change it and/or distribute copies of it under certain 
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for 
details.
This GDB was configured as "i586-mandrake-linux-gnu"...
Setting up the environment for debugging gdb.
.gdbinit:5: Error in sourced command file:
Function "internal_error" not defined.
(gdb) set demangle-style edg
(gdb) b bob
Breakpoint 1 at 0x804835c: file testcpp.cpp, line 2.
(gdb) info func bob
All functions matching regular expression "bob":

File testcpp.cpp:
int _Z3bobv(void);
(gdb) q
[dberlin@dberlin gdb]$ gdb
GNU gdb 5.2.1-2mdk (Mandrake Linux)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you 
are
welcome to change it and/or distribute copies of it under certain 
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for 
details.
This GDB was configured as "i586-mandrake-linux-gnu".
Setting up the environment for debugging gdb.
.gdbinit:5: Error in sourced command file:
No symbol table is loaded.  Use the "file" command.
(gdb) set de
debug           debugvarobj     demangle-style
(gdb) set demangle-style edg
(gdb) file a.out
Reading symbols from a.out...done.
(gdb) b bob
Function "bob" not defined.
(gdb) info func bob
All functions matching regular expression "bob":

File testcpp.cpp:
int _Z3bobv(void);
(gdb)



This is minimal symbol fun in exactly the way i described.
Since it's already loaded msyms in "auto" mode in the first case, even 
though the psyms and normal syms have the *wrong* name.

As a user, the fact that "b bob" works in the first case, but not in the 
second, confuses the hell out of me.

I would venture nobody noticed because nobody changed the demangling 
style, not because it was coded this way.
> 
> Perhaps we need to decide what the point of letting users force the
> demangle style is, first.
Assembler printouts.

> 
> 


  reply	other threads:[~2002-10-02 23:10 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-01 20:45 Jim Blandy
2002-10-02 10:45 ` David Carlton
2002-10-02 12:35   ` Jim Blandy
2002-10-02 12:41     ` David Carlton
2002-10-02 13:02       ` Daniel Jacobowitz
2002-10-02 13:20         ` David Carlton
2002-10-02 13:25           ` Daniel Jacobowitz
2002-10-02 13:43     ` Daniel Berlin
2002-10-02 14:03       ` Daniel Jacobowitz
2002-10-02 16:10         ` Daniel Berlin [this message]
2002-10-02 16:19           ` Setting the demangling style Daniel Jacobowitz
2002-10-02 11:04 ` RFA: Search for symbol names the same way they're hashed Daniel Jacobowitz
2002-10-02 12:10   ` David Carlton
2002-10-07 16:19   ` David Carlton
2002-10-07 16:38     ` Daniel Jacobowitz
     [not found] <1033595444.9324.ezmlm@sources.redhat.com>
2002-10-02 17:49 ` Jim Ingham
2002-10-02 18:16   ` Daniel Jacobowitz
2002-10-02 18:25     ` Jim Ingham
2002-10-03  8:15       ` Daniel Berlin

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=Pine.LNX.4.44.0210021856210.4265-100000@dberlin.org \
    --to=dberlin@dberlin.org \
    --cc=carlton@math.stanford.edu \
    --cc=drow@mvista.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=jimb@redhat.com \
    /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