This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB 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: RFA: shrink main_type


>>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:

Daniel> If you're going to do this anyway, why not make them individual
Daniel> bitfields?  Would that be too disruptive?

It would not be too bad.  I count 69 uses of TYPE_FLAGS, that isn't a
huge number.  The other uses are hidden by the accessor macros.

I will make this change.

FWIW I only looked at this struct since it is marked as being
space-critical, and I saw a way to shrink it a bit.

Daniel> I don't think it's particularly useful to change the type of this to
Daniel> the enum since we don't put enum values in it, just bitwise
Daniel> combination of them.  (Isn't that invalid in C++?)

Yes, it is invalid C++.  Though... currently if you build gdb with
g++, you will get thousands of errors.  One more wouldn't make that
project significantly harder IMO :)

Daniel> And if you want to repack the upper/lower bounds fields, I bet they
Daniel> can move into type_specific.

I looked at this.  I am not so sure about moving these fields -- they
are referenced by pretty much every language.  I didn't look at why
this was so (i.e., could be dead code, or bad cut-and-paste, or
whatever).

I was thinking that perhaps the vptr stuff could go in type_specific.
Or, we could do like GCC and have different structures depending on
the code, so that non-struct types don't have to carry around unused
fields.  I didn't try to measure how much this would save.  These are
bigger changes; this particular patch was just an easy way to save
some memory.

Tom


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