This is the mail archive of the
mailing list for the GDB project.
Re: (patch) hpjyg03: (buildsym|language).[ch]
Thanks! I have some questions, though:
> + 1999-10-29 Jimmy Guo <firstname.lastname@example.org>
> + * buildsym.h (free_pendings): Declare.
> + * buildsym.c: Make free_pendings global, and misc. fixes.
> + (make_blockvector): 32x64 fix using longest_local_hex_string().
> + (start_subfile): initialize variable 'subfile'.
> + (end_symtab): fix bug freeing 'subfiles' list element, when it's
> + the list head to be freed.
> *** gdb/buildsym.h
> --- gdb/buildsym.h Thu Oct 28 18:11:31 1999
> *** 109,114 ****
> --- 109,118 ----
> struct symbol *symbol[PENDINGSIZE];
> + /* List of free `struct pending' structures for reuse. */
> + EXTERN struct pending *free_pendings;
> /* Here are the three lists that symbols are put on. */
> /* static at top level, and types */
What are you planning to do with free_pendings elsewhere in GDB?
If you make a variable externally visible, that opens it up for
arbitrary use anywhere else in GDB. People will see that extern
declaration and figure it's okay to do whatever they please.
Depending on what the other code needs to do, it might be better
instead to export a function from buildsym.c that does one specific
operation on free_pendings. That way, it's easier for someone reading
buildsym.c to see what kind of interactions to expect from outside.
> *** 998,1003 ****
> --- 991,998 ----
> nextsub = subfile->next;
> + if (subfiles == subfile)
> + subfiles = nextsub;
> free ((void *) subfile);
Could you explain this change a little more? I understand that the
list of subfiles is being freed here, so without this, subfiles ends
up being a dangling pointer. But it looks to me like the loop frees
the entire list of subfiles. So subfiles will always end up being
zero. And it doesn't look to me like subfiles is ever used while the
loop is running.
So, who is attempting to use subfiles after calling end_symtab without
calling start_symtab first to reinitialize things?