From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6509 invoked by alias); 11 Aug 2009 17:45:13 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 6473 invoked by uid 22791); 11 Aug 2009 17:45:09 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_44,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Date: Tue, 11 Aug 2009 17:45:00 -0000 From: Jan Kratochvil To: Dodji Seketeli Cc: Tom Tromey , GDB/Archer list Subject: Re: [RFC] Proposal for a new DWARF name index section Message-ID: <20090811174448.GA17263@host0.dyn.jankratochvil.net> References: <4A7FE28D.4050901@redhat.com> <20090810143804.GA8671@host0.dyn.jankratochvil.net> <20090810182136.GA25301@host0.dyn.jankratochvil.net> <4A8123C9.3030209@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4A8123C9.3030209@redhat.com> User-Agent: Mutt/1.5.19 (2009-01-05) X-SW-Source: 2009-q3/txt/msg00114.txt.bz2 On Tue, 11 Aug 2009 09:54:49 +0200, Dodji Seketeli wrote: > Le 10/08/2009 20:21, Jan Kratochvil a écrit : > > Still when thinking about it: > > * I do not find the symbols reading much slow myself (working _on_ small GDB). > > I agree this is hard to assess precisely. In my experience, debugging large > c++ applications made of lots of dynamic libraries (like mozilla or any > webkit based app) triggers lots of disk access. How much of that is due to > debug info reading ? Most of the time (like >95%, did not measure now), you can try: --readnever Do not read symbol files. > FWIW, I think implementing this new section stuff is not really complex on > the gcc side. ... > I'd say it really depends on the user. If I am used to the code base I am > debugging, I will tend to set quite some breakpoints by name, because > opening $file, then clicking on the right line takes more time than doing > ctrl-b (assuming that's the shortcut to set a breakpoint) and typing the > name of the known function I want to break in. The debugger opens the file > and scrolls down to where the breakpoint is set. Much faster. Even better > if the debugger can provide me with _fast_ name completion when typing the > function name. OK, so the static out-of-scope breakpoint-by-name make sense for large apps. > > We have concluded the currently missing information is for: > > * static functions (are they really needed for the file:line IDE usecases?) > > I think they aren't needed for that exact use case. But as I said earlier, > I think there are other use cases that should be faster, are useful for > regular debugger users, and that are unfortunately not as faster as they > ought to be today. And we can address those, can't we ? Yes, GDB can address the non-static use cases with the DWARF indexes already. > > IMO not for: > > * static non-function symbols are deprecated (backward GDB compatibility only) > > Sorry, I am not sure to fully understand this. Due to this existing GDB behavior: On Mon, 10 Aug 2009 16:38:04 +0200, Jan Kratochvil wrote: # 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 > Do global variables and > enumerator constants fall into this "deprecated" category ? Global variables are a part of .debug_pubnames and they are not "deprecated" as they are globally visible in the C language. enumerator constants are not globally visible, they create no ELF symbols, they need to be #included for each CU, they are like static functions, therefore they should not be a part of .debug_pubnames. As you wrote: On Mon, 10 Aug 2009 11:04:13 +0200, Dodji Seketeli wrote: # * It is unclear from the standard whether enumerators should be listed # in .debug_pubnames. I think the DWARF spec is right and intentionally not listing them for .debug_pubnames/.debug_pubtypes. > 1/ There are "basic" usage cases that you won't be able to speedup, e.g. > imagine there is a global variable named 'foobar'. The user wants to break > in a function at some point and types "break foobar". I think the debugger > ought to know if there is a visible function named foobar in which it could > set the breakpoint. If not, it should gracefully display an error to the > user (possibly proposing the name of another function, close to foobar, > into which to break ?) without having to hit the disk to scan possibly > zillions of objects. `foobar' will be found in local CU and then in .debug_pubnames. But if the out-of-scope static function names should be reachable then we need some new index, yes. > So based on 2/ and 3/ maybe it can be worth it to just throw out > .debug_pubname and .debug_pubtypes and think about something more "solid" > that we can build on ? Yes, the new index would be useful for: * static functions in out of the language (compiler) scope * any inlined functions (so that no '.debug_line's need to be read for putting a breakpoint-by-name). (dropping the IMO-"deprecated" out-of-scope static data symbols lookups) I hope these mails were useful for both sides, at least for me. Thanks, Jan