This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [rfa] allocate_objfile(NULL, 0)
- From: Elena Zannoni <ezannoni at redhat dot com>
- To: David Carlton <carlton at math dot stanford dot edu>
- Cc: Elena Zannoni <ezannoni at redhat dot com>, gdb-patches at sources dot redhat dot com
- Date: Tue, 4 Feb 2003 13:08:53 -0500
- Subject: Re: [rfa] allocate_objfile(NULL, 0)
- References: <ro1hecgd149.fsf@jackfruit.Stanford.EDU><15903.24492.446475.747803@localhost.redhat.com><ro1y95sbl4c.fsf@jackfruit.Stanford.EDU>
David Carlton writes:
> On Fri, 10 Jan 2003 19:05:00 -0500, Elena Zannoni <ezannoni@redhat.com> 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
> >> fault.
>
> > 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
> case.
>
> >> 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.
I cannot come up with anything better at the moment, so OK, but...
could you add comments? Kind of summarize your mail and Tom's mail.
elena
>
> >> David Carlton
> >> carlton@math.stanford.edu
> >>
> >> 2003-01-10 David Carlton <carlton@math.stanford.edu>
> >>
> >> * objfiles.c (allocate_objfile): Always set name.
>
> > You are missing the copyright year.
>
> Whoops! Good catch, thanks.
>
> David Carlton
> carlton@math.stanford.edu