This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] Support 64-bit constants/enums on 32-bit host [Re: [PATCH] Allow 64-bit enum values]
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: Siddhesh Poyarekar <siddhesh at redhat dot com>, gdb-patches at sourceware dot org
- Date: Tue, 17 Apr 2012 17:32:02 +0200
- Subject: Re: [patch] Support 64-bit constants/enums on 32-bit host [Re: [PATCH] Allow 64-bit enum values]
- References: <20120220132724.GB4753@spoyarek.pnq.redhat.com> <87d397syts.fsf@fleche.redhat.com> <20120229135148.GA32128@spoyarek.pnq.redhat.com> <20120301224428.GA30631@host2.jankratochvil.net> <20120305063542.GA30196@spoyarek.pnq.redhat.com> <20120305080512.GA12311@host2.jankratochvil.net> <20120321100630.GA14496@spoyarek.pnq.redhat.com> <20120417130833.GB15356@host2.jankratochvil.net> <20120417143219.GA25827@host2.jankratochvil.net> <87zkaav1i4.fsf@fleche.redhat.com>
On Tue, 17 Apr 2012 17:09:23 +0200, Tom Tromey wrote:
> Due to the way that struct symbol is packed, I think this would only
> save sizeof(general_symbol_info) - sizeof(void*) bytes (32 bytes per
> symbol on x86-64).
Personally I still do not think we should care too much about
one 'struct symbol'. There is more a problem we create
too many 'struct symbol' which are never used.
> This idea would make lazy CU expansion a bit faster, because you
> wouldn't have to re-scan the DIEs to make the symbol table.
I think this would be a win contrary to other disadvantages; I have sure no
technical arguments for that, other than accessing memory outside of the CPU
cache is terribly slow and several more bytes are worth the acceleration.
> and as you pointed out on irc, the result will
> still probably be slower than idb -- IOW, we're doing something really
> wrong, so why not start by finding that?
BTW without making some big decisions one should do some more serious test of
idb, or at least to be tested by a second person, I did just a quick test
myself (that GDB is 800%-times slower even with .gdb_index), I could make some
mistakes and I even no longer remember all the details how I specifically did
the test.
Thanks,
Jan