public inbox for archer@sourceware.org
 help / color / mirror / Atom feed
From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: Dodji Seketeli <dodji@redhat.com>
Cc: GDB/Archer list <archer@sourceware.org>
Subject: Re: [RFC] Proposal for a new DWARF name index section
Date: Mon, 10 Aug 2009 14:38:00 -0000	[thread overview]
Message-ID: <20090810143804.GA8671@host0.dyn.jankratochvil.net> (raw)
In-Reply-To: <4A7FE28D.4050901@redhat.com>

On Mon, 10 Aug 2009 11:04:13 +0200, Dodji Seketeli wrote:
> * Only public names are indexed.  However, historically GDB has
>   allowed users to inspect and break on private objects as well,
>   without specifying a scope.

I think this requirement should be discussed more.

Still I find the goal is that the expression evaluation in debugger should
match the expression evaluation in compiler.

In practice the results are tricky due to the static symbols resolution:
$ echo 'main(){}' >libm.c;cc -o libm libm.c -lm -g;gdb -q -ex start -ex 'p b' ./libm
...
$1 = {i = {0, 1068498944}, d = 0.0625}
$ nm /lib64/libm.so.6 |grep ' b$'
0000003bb1e4bad8 r b


There could be an option to support backward-compatible "slow" mode and use
the (possible DWARF) indexes only for the new compiler-compliant mode.


Including also a C++ overloading example at the bottom but it may be offtopic.


> * It is unclear from the standard whether enumerators should be listed
>   in .debug_pubnames.
+
> * There is no way to know whether if a name references an enumerator,
>   and object or a function. This makes it hard for debuggers to
>   implement lazy debug information loading schemes.

A fixup by http://dwarfstd.org/Issues.php looks as appropriate in each case.


> * There is no way to know whether if a name references an enumerator,
>   and object or a function. This makes it hard for debuggers to
>   implement lazy debug information loading schemes.
+
> * The .debug_pubtypes section does not encode whether a name is a
>   typedef or a struct, union, or enum tag.

Are there any serious consequences?  Occasional needless read of a CU to find
out the type should not be a real performance hit.


> * Compilers are not required to emit index entries for inlined
>   functions which have no concrete out-of-line instance.  This implies
>   that a command like "break function", if it is to work for an
>   inlined function, must read all the .debug_info sections even if it
>   turns out that no such function exists anywhere.

Both
	http://dwarf.freestandards.org/Dwarf3.pdf
	http://www.dwarfstd.org/doc/DWARF4-draft3-090522.pdf
say
	C++ member functions with a definition in the class declaration are
	definitions in every compilation unit containing the class
	declaration, but if there is no concrete out-of-line instance there is
	no need to have a .debug_pubnames entry for the member function.

"no need to have" (and you say "are not required") so GCC is free to emit such
index entries.  Excessive index entries hopefully should not break debuggers.

GDB could check DW_AT_producer against known GCC versions to skip the slow
reading of '.debug_info's and rely just on '.debug_pubnames' - to find out all
the inlined instances of a specified function.



Regards,
Jan


C++ example:

(set -ex; g++ -o main main.C other.C -Wall -ggdb2; ./main)
gdb ./main
(gdb) start
(gdb) p &c
$1 = (C *) 0x7fffffffd3df
(gdb) call c.main()
main-main
(gdb) call C::main()
main-main
(gdb) call c.other()
Couldn't find method C::other
(gdb) call C::other()
other-other
	# Isn't it wrong here?  C::other() comes from a different CU.
(gdb) 

C++ class with the same name should be probably always fully equivalent as all
the methods are global ("W" nm symbol class) by default.  Thus my example is
an invalid C++ program probably.  Automatically limiting the C++ scope only to
the current CU would not be able to call methods having instances in other CUs
and just accidentally missing at the current CU due to being unused.


==> main.C <==
#include <stdio.h>

class C
  {
  public:
    static void m (int x) { puts ("main-int"); }
//    static void m (long x) { puts ("main-long"); }
    static void main () { puts ("main-main"); }
  };

extern void other ();

int
main ()
{
  C c;

  c.m (1);
  c.m (1L);
  c.main ();

  other ();

  return 0;
}

==> other.C <==
#include <stdio.h>

class C
  {
  public:
//    static void m (int x) { puts ("other-int"); }
    static void m (long x) { puts ("other-long"); }
    static void other () { puts ("other-other"); }
  };

void
other ()
{
  C c;

  c.m (1);
  c.m (1L);
  c.other ();
}

  reply	other threads:[~2009-08-10 14:38 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-10  9:04 Dodji Seketeli
2009-08-10 14:38 ` Jan Kratochvil [this message]
2009-08-10 17:36   ` Tom Tromey
2009-08-10 18:21     ` Jan Kratochvil
2009-08-11  7:55       ` Dodji Seketeli
2009-08-11 17:45         ` Jan Kratochvil
2009-08-11 22:43           ` Tom Tromey
2009-08-12 19:20             ` Jan Kratochvil
2009-08-11 22:29       ` Tom Tromey
2009-08-20 17:31 ` Dodji Seketeli
2009-11-17 23:46   ` Cary Coutant
2009-11-20 17:25     ` Tom Tromey
2009-11-22  4:39       ` Daniel Jacobowitz
2009-11-23 19:51         ` Tom Tromey
2009-12-01 19:14       ` Tom Tromey
2009-12-02  5:17         ` Daniel Jacobowitz
2009-12-02 17:07           ` Tom Tromey
2009-12-02 17:35             ` Daniel Jacobowitz
2009-12-02 19:23               ` Tom Tromey
2009-12-02 19:39                 ` Daniel Jacobowitz
2009-12-03  1:46                   ` Paul Pluzhnikov
2009-12-04 23:13                     ` Tom Tromey
2009-12-06  3:41                       ` Tom Tromey
2009-12-07 21:32                         ` Tom Tromey
2009-12-02 16:11         ` Dodji Seketeli
2009-12-02 17:29           ` Tom Tromey
2009-12-11 23:56     ` Tom Tromey
2009-12-12  0:06       ` Daniel Jacobowitz
2009-12-12  0:13       ` Cary Coutant
2009-12-13  3:48       ` Dodji Seketeli
2009-12-14 15:32       ` Dodji Seketeli

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=20090810143804.GA8671@host0.dyn.jankratochvil.net \
    --to=jan.kratochvil@redhat.com \
    --cc=archer@sourceware.org \
    --cc=dodji@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).