Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Fred Fish <fnf@fishpond.ninemoons.com>
To: gdb-patches@sources.redhat.com
Cc: fnf@ninemoons.com
Subject: [PATCH] temporary fix for bogus language check
Date: Sun, 11 Nov 2001 04:26:00 -0000	[thread overview]
Message-ID: <200111251921.fAPJLP323371@fishpond.ninemoons.com> (raw)
Message-ID: <20011111042600.IdIVhMp4QbbRYLtEzONftsQJI4s0s1Ia2tfi4mblX8E@z> (raw)

In lookup_symbol(), gdb checks the current language and if it is C++,
trys to demangle the symbol name before looking it up.  This works
fine if we are both looking up a C++ symbol and the current language
is C++.  However it breaks down if we are trying to lookup a C++
symbol and the current language is not C++, such as when stopped
inside a C function (perhaps a C library call for example).

Consider decode_line_1 in linespec.c, which is called when you do
something like "br PCReader::work".  This function calls
find_methods(), which later calls lookup_symbol() with the mangled
name "work__8PCReader".  If the current language is C++,
lookup_symbol() demangles it to "PCReader::work(void)" and calls
lookup_symbol_aux with the demangled name, which succeeds.  If however
you try to set the same breakpoint when stopped at a C function
setting the breakpoint fails.

The following patch works around the problem by always attempting to
demangle the symbol to be looked up.  We could fix this problem by
eliminating the test of the current language, but then every gdb
session would incur the additional overhead of attempting to demangle
every symbol regardless of whether or not any C++ symbols were
present.  Another option is to set some global flag whenever symbols
for a C++ function are read in, and then do the current language test
unconditionally once we know that there might be C++ symbols
somewhere.  Yet another option is to add a parameter to lookup_symbol
that says whether to consider the possibility that the symbol to be
looked up is a C++ symbol, set that appropriately when calling
lookup_symbol, and use that value to decide whether or not to try
demangling the symbol.

Suggestions?

-Fred

Index: symtab.c
===================================================================
RCS file: /cvs/src/src/gdb/symtab.c,v
retrieving revision 1.48
diff -u -r1.48 symtab.c
--- symtab.c	2001/11/13 16:42:50	1.48
+++ symtab.c	2001/11/25 18:49:46
@@ -528,8 +528,11 @@
       modified_name = (char *) name;
 
   /* If we are using C++ language, demangle the name before doing a lookup, so
-     we can always binary search. */
-  if (current_language->la_language == language_cplus)
+     we can always binary search.
+     NOTE: We need to always try to demangle since the current_language might
+     be something other than C++ at the point when we are trying to set a
+     breakpoint in C++ code.  -fnf */
+  if (1 || (current_language->la_language == language_cplus))
     {
       modified_name2 = cplus_demangle (modified_name, DMGL_ANSI | DMGL_PARAMS);
       if (modified_name2)


             reply	other threads:[~2001-11-25 19:26 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-25 11:26 Fred Fish [this message]
2001-11-11  4:26 ` Fred Fish
2001-11-11 10:50 ` Eli Zaretskii
2001-11-25 23:56   ` Eli Zaretskii
2001-11-12 11:34 ` Elena Zannoni
2001-11-26  9:47   ` Elena Zannoni
2001-11-25 11:53 ` Daniel Berlin
2001-11-11  8:42   ` 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=200111251921.fAPJLP323371@fishpond.ninemoons.com \
    --to=fnf@fishpond.ninemoons.com \
    --cc=fnf@ninemoons.com \
    --cc=gdb-patches@sources.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