This is the mail archive of the
mailing list for the GDB project.
Re: [rfa] allocate_objfile(NULL, 0)
On Fri, 10 Jan 2003 19:05:00 -0500, Elena Zannoni <firstname.lastname@example.org> said:
> David Carlton writes:
>> The function allocate_objfile takes some care to return a useful
>> objfile if its first argument (the bfd) is NULL. But it doesn't set
>> objfile-> name in that case; there is code in GDB that loops over
>> all the objfiles and examines their names, which breaks in this
>> case. (See, for example, symbol_add_stub.)
>> I ran into this problem when imitating the dynamics objfile in
>> jv-lang.c. So I'm pretty sure that, currently, if anybody tries to
>> debug Java code that requires that objfile to exist, GDB will seg
> Can you expand a bit? Would it be possible to create a test case?
I'm no Java expert, but here's the situation as I understand it. When
evaluating Java code, sometimes you have to generate new Java classes
in an unpredictable manner. When this happens, there isn't any file
around to get debug info from. So jv-lang.c generates a symbol for
those classes; it has to store it in a global block somewhere so the
symbol gets searched, so it creates an objfile that isn't associated
to any physical file, just for the purpose of storing a symtab in it
to put these symbols. This is the code in the first part of jv-lang.c
When I tried to imitate this on a branch for my own nefarious
purposes, GDB started to segfault, and this was the reason. I assume
that it could also segfault in the Java case, at least if you could
convince symbol_add_stub to run after one of these dynamic classes was
generated. Alas, I don't know enough Java to be able to create a test
>> The enclosed patch modifies allocate_objfile to set the name to
>> "<<anonymous objfile>>" in that situation. It removes the seg fault
>> that I saw. I ran the test suite on i686-pc-linux-gnu/GCC 3.1/DWARF-2
>> and saw no new regressions.
>> Is this patch okay? I don't know offhand who the appropriate
>> maintainer is.
> I don't know about the '<<' '>>' usage. I wonder if gdb already
> has some other cases like this one. Maybe 'nameless'?
My reasoning behind the <<>> is that I wanted to pick a string that
was unlikely to look like an actual filename. That way, people
wouldn't accidentally get an anonymous objfile when they were looking
for an objfile associated to an actual file. But I'm certainly
flexible; whatever you think is best.
>> David Carlton
>> 2003-01-10 David Carlton <email@example.com>
>> * objfiles.c (allocate_objfile): Always set name.
> You are missing the copyright year.
Whoops! Good catch, thanks.