allocate_objfile (NULL, 0)

[David Carlton <carlton@math.stanford.edu>]

I'm in a situation where I want to create an artificial block to store
some artificial symbols.  I've followed the lead of jv-lang.c (which
needs a block to store symbols associated to dynamic classes); that
code creates an object file via this call:

      dynamics_objfile = allocate_objfile (NULL, 0);

and then creates a symtab within it, creates global and static blocks
for that symtab, and stuffs stuff into the global block.

The problem with this is that the resulting objfile doesn't have a
name, and there is code within GDB that assumes that objfile->name is
non-NULL.  I ran into this problem in solib.c's symbol_add_stub, but
there may well be other places that make that assumption.

So something should be fixed.  It seems that the three possible
options are:

1) Not allow code to assume that objfile->name is always non-NULL.

2) Modify allocate_objfile to set the allocated objfile's name to the
   empty string in the case where its first argument is NULL.

3) Fix jv-lang.c to set objfile->name explicitly.

I'll be happy to submit a patch that does one of these, but I wanted
to poll people to see which option they prefer.  My vote is for option
number 2: the code in solib.c seems reasonable enough, so I don't like
option number 1, and allocate_objfile seems to go to some length to
work well when its first argument is NULL, so it wouldn't hurt for it
to handle this issue as well.  It would, of course, be possible to do
both options 2 and 3: assuming that we agree that option 2 is good,
then it would be up to the Java maintainers as to whether they wanted
to follow option 3 as well.

David Carlton
carlton@math.stanford.edu