Re: (patch) hpjyg03: (buildsym|language).[ch]

[Jimmy Guo <guo at cup dot hp dot com>]

>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.

The other code (hp-symtab-read.c (hpread_read_function_type)) uses a
'local_list' to add fparam to.  If the routine is called just to get the
function type (instead of for creating a new block), this local_list
does not get 'freed', but should be.  Looking at the code again I agree
that the free_pendings list should probably stay local and let a
specific function to manage additions to the list.  I will revise the
patch to reflect your input!

>>         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?

Good question.  The fix was related to a HP-UX 11.0 test failure about a
year ago, related to HP aCC support.  Since 1) the test involved is no
longer available (duh) 2) there are tons of failures right now with
Cygnus GDB when it comes to HP aCC support, I'm going to postpone
merging this particular piece of code until we are at a stage where I
can be better positioned to triage a failure that could be related to
this to provide a real answer :)  For now, I think this change is nice
to have (although I'd just put in a 'subfiles = NULL' after the loop
instead), but could shadow a real problem / issue somewhere else where
subfiles is referenced after end_symtab().

Stay tuned for a revision of the patch.  Thanks for the comments, Jim!

- Jimmy Guo, guo@cup.hp.com