From: Elena Zannoni <ezannoni@redhat.com>
To: David Carlton <carlton@math.stanford.edu>
Cc: Elena Zannoni <ezannoni@redhat.com>, gdb-patches@sources.redhat.com
Subject: Re: [rfa] allocate_objfile(NULL, 0)
Date: Tue, 04 Feb 2003 18:04:00 -0000 [thread overview]
Message-ID: <15936.437.642918.181857@localhost.redhat.com> (raw)
In-Reply-To: <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
next prev parent reply other threads:[~2003-02-04 18:04 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-10 23:41 David Carlton
2003-01-11 0:00 ` Elena Zannoni
2003-01-11 0:12 ` David Carlton
2003-01-17 23:32 ` Tom Tromey
2003-02-04 18:02 ` Elena Zannoni
2003-02-04 18:07 ` Tom Tromey
2003-02-04 18:04 ` Elena Zannoni [this message]
2003-02-04 22:21 ` David Carlton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=15936.437.642918.181857@localhost.redhat.com \
--to=ezannoni@redhat.com \
--cc=carlton@math.stanford.edu \
--cc=gdb-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox