This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] bug fixes for varobj.c
- From: Andrew Cagney <ac131313 at cygnus dot com>
- To: "Martin M. Hunt" <hunt at redhat dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Wed, 12 Jun 2002 22:24:35 -0400
- Subject: Re: [RFA] bug fixes for varobj.c
- References: <200206102308.40570.hunt@redhat.com>
Anything using varobj is randomly corrupting memory and will cause crashes in
Insight or anything using mi varobjs. This patch fixes that and some other
minor problems.
Hmm, I'm not seeing MI test failures. Would you, by chance, have
something reproduceable for an MI testcase?
Anyway, separating out the changes:
I consider the sprintf() -> xasprintf() transformations:
(varobj_gen_name): Use xasprintf.
(create_child): Use xasprintf.
to be ``obvious'' and can, separatly, go straight in (only ~300 other
calls to go ...).
The frame_id stuff:
/* Save the selected stack frame, since we will need to change it
in order to evaluate expressions. */
- old_fi = selected_frame;
+ get_frame_id (selected_frame, &old_fid);
is fine except I'm not sure about:
- var->root->frame = (CORE_ADDR) -1;
+ var->root->frame.base = (CORE_ADDR) -1;
+ var->root->frame.pc = (CORE_ADDR) -1;
The function:
frame_find_by_id (struct frame_id id)
has:
/* ZERO denotes the null frame, let the caller decide what to do
about it. Should it instead return get_current_frame()? */
if (id.base == 0 && id.pc == 0)
return NULL;
(see find_frame_addr_in_frame_chain for where this came from) so I think
zero would be better.
For the indentation changes, the way to do this is to (separate patch /
commit) run the file through gdb_indent.sh. BTW, the script would not
re-indent:
-{
- v_public = 0, v_private, v_protected
-};
+ {
+ v_public = 0, v_private, v_protected
+ };
Andrew