From: Daniel Jacobowitz <drow@false.org>
To: Joel Brobecker <brobecker@adacore.com>
Cc: gdb@sourceware.org
Subject: Re: failed assertion hit in check_typedef
Date: Tue, 27 Feb 2007 13:14:00 -0000 [thread overview]
Message-ID: <20070227120239.GB5164@caradoc.them.org> (raw)
In-Reply-To: <20070227071658.GB13159@adacore.com>
On Mon, Feb 26, 2007 at 11:16:58PM -0800, Joel Brobecker wrote:
> So one of the unfortunate effects is that we end up in a situation
> when we have a copy of that type definition in our DSO, and also
> another copy in the main executable (more than one actually, but
> one is already too many).
>
> As a result, we have a problem there (gdbtypes.c:check_typedef):
>
> else if (TYPE_STUB (type) && !currently_reading_symtab)
> {
> char *name = type_name_no_tag (type);
> [...]
> sym = lookup_symbol (name, 0, STRUCT_DOMAIN, 0, (struct symtab **) NULL);
> if (sym)
> make_cv_type (is_const, is_volatile, SYMBOL_TYPE (sym), &type);
> }
>
> the lookup_symbol routine finds the first one which, bad luck,
> just happens to be the definition from the main exectuable.
Maybe we really want a lookup_symbol call which looks just in the
correct objfile... well, I guess that wouldn't always help.
> /* [repeat the comment already there (the one just above),
> and explain that we avoid the overwrite if the two types are
> not stored in the same obstack. Add explanation as to when
> this can happen]. */
> if (typeptr && *typeptr != NULL
> && TYPE_OBJFILE (*typeptr) != TYPE_OBJFILE (type))
> typeptr = NULL;
>
> It takes quite a long while to run the testsuite on mips-irix,
> so I was wondering if I could get some feedback before I go too
> far into this route...
How about doing it in the caller? If you go to check_typedef, you'll
see that there's already an example of the same thing. If this is
DWARF2 and only started happening recently it may be the fault of your
recent fixes for what empty types constitute a declaration.
--
Daniel Jacobowitz
CodeSourcery
prev parent reply other threads:[~2007-02-27 12:02 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-27 11:02 Joel Brobecker
2007-02-27 13:14 ` Daniel Jacobowitz [this message]
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=20070227120239.GB5164@caradoc.them.org \
--to=drow@false.org \
--cc=brobecker@adacore.com \
--cc=gdb@sourceware.org \
/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