This is the mail archive of the mailing list for the Archer project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Proposal for a new DWARF name index section

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/ |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

> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]