This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [rfa/dwarf] Use objfile_data mechanism for per-objfile data
- From: Daniel Jacobowitz <drow at false dot org>
- To: Jim Blandy <jimb at redhat dot com>
- Cc: gdb-patches at sources dot redhat dot com, ezannoni at redhat dot com
- Date: Thu, 1 Apr 2004 16:06:08 -0500
- Subject: Re: [rfa/dwarf] Use objfile_data mechanism for per-objfile data
- References: <20040401171557.GA17948@nevyn.them.org> <vt2ekr7a02b.fsf@zenia.home>
On Thu, Apr 01, 2004 at 03:57:16PM -0500, Jim Blandy wrote:
>
> Wonderful! So it turns out 'struct dwarf2_pinfo' has only one real
> member, huh? :)
On my branch it has two - I added a per-psymtab hash table in some
cases.
> I have to say, 'dwarf2_per_objfile_data', 'struct
> dwarf2_per_objfile_data', and 'dwarf2_per_objfile' are not my favorite
> cluster of names. It took me a few passes to get it straight. (Yes,
> I should have gotten more sleep, but I suspect there are others who
> work under the same conditions...)
>
> How about:
> - 'dwarf2_objfile_data_key' for the 'struct objfile_data', and
> - 'struct dwarf2_objfile' and 'dwarf2_objfile' for the actual
> per-objfile datatype and the global pointer to the current instance?
>
> (Is that any better? I think suffixes like "_data" really only belong
> on things whose type is unspecified at the point where the name
> appears, like 'void *' pointers, or objects related to them. I mean,
> everything is "data"; if you're going to give something a
> generic-sounding name, that should be because you're emphasizing the
> genericness of it.)
I don't think that's any better. "dwarf2_objfile" implies that it's a
kind of objfile. But I'm willing to use your names :)
> The lower-case implicit-parameter macros bug me. But I assume they're
> going away soon, and upper-casing them would make the patch huge,
> right?
I didn't have a particular plan in either direction. Doing either
would be an easy follow-on. Replacing them with their expansions would
be noisy indentation-wise, but otherwise trivial - that may be best.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer