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] |
There are other calls to val_print in this function.
It seems like they should all be wrapped.
If cp_free_statmem_stack must be called, then you need a cleanup.
However, does it really need to be called? IMO it is ok to keep a
little data on this obstack in between calls as long as it is cleared at
the next call (so that we don't leak an unbounded amount over time).
It isn't clear to me from this patch or the explanation that
cp_initialise_statmem_stack is called at every relevant entry point.
In fact it would be better not to have to do that, because auditing this call hierarchy is tricky.
E.g., m2-valprint.c has a call to cp_print_value_fields. Does that
matter?
I didn't read the old code in depth; is there a way to make this
self-initializing?
Chris> - first_dont_print Chris> - = (CORE_ADDR *) obstack_base (&dont_print_statmem_obstack); Chris> - i = (CORE_ADDR *) obstack_next_free (&dont_print_statmem_obstack) Chris> - - first_dont_print; Chris> + first_dont_print = Chris> + (CORE_ADDR *)obstack_base (&dont_print_statmem_obstack); Chris> + i = Chris> + obstack_object_size (&dont_print_statmem_obstack) / sizeof(CORE_ADDR);
The formatting is weird here; the first statement doesn't appear to have changed, but has gratuitous formatting changes,
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |