This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [rfa] allocate_objfile(NULL, 0)


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]