This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA/Ada] suppress internally-generated symbols from "info locals"
- From: Daniel Jacobowitz <drow at false dot org>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Tue, 29 Jan 2008 13:14:03 -0500
- Subject: Re: [RFA/Ada] suppress internally-generated symbols from "info locals"
- References: <20080114053614.GE9324@adacore.com>
On Sun, Jan 13, 2008 at 09:36:14PM -0800, Joel Brobecker wrote:
> Hello,
>
> A customer reported that he was seeing strange symbols sometimes when
> using the "info locals" command. For instance:
>
> (gdb) info locals
> my_object = (prev => 0x0, next => 0x0, value => 42)
> <F1b> = (access system.finalization_root.root_controlled) 0xbfcc94d0
>
> This happens at -g3 only.
>
> The second entity should not be visible to the user. We normally always
> modify the compiler to stop generating debugging info for these entities,
> but we also add guards against them when we easily can to improve the life
> of our users who are stuck with an older compiler. In this case, the
> machinery was already in place, so it was easy. I think we also have
> other types of symbols that we need to suppress and yet need to be
> defined in the debugging info (renames for instance), but I can't
> construct a testcase that shows that.
>
> We introduced a new language function (la_symbol_printing_suppressed),
> and all languages except Ada have been set to never suppress any symbol.
> Ada uses the already defined ada_suppress_symbol_printing. We also
> defined a new SYMBOL_PRINTING_SUPPRESSED macro in symtab.h which is
> a convenient shortcut more than a symtab macro. The testcase in
> question also uncovered a bug in our ada-lang.c:is_suppressed_name
> function, which Paul fixed.
This sounds to me like it should be marked artificial. Any chance we
can do that during symbol reading?
(Yes, I realize we don't have an artificial flag on symbols, yet, just
on types and fields. But GCC does and it's a pretty obvious next step
from the ones we have.)
--
Daniel Jacobowitz
CodeSourcery