From: Mark Kettenis <kettenis@chello.nl>
To: cagney@gnu.org
Cc: gdb-patches@sources.redhat.com
Subject: Re: [PATCH] Multi-arch SKIP_SOLIB_RESOLVER
Date: Mon, 10 Nov 2003 21:49:00 -0000 [thread overview]
Message-ID: <200311102149.hAALnli4000481@elgar.kettenis.dyndns.org> (raw)
In-Reply-To: <3FAEA5BA.2050805@gnu.org> (message from Andrew Cagney on Sun, 09 Nov 2003 15:38:18 -0500)
Date: Sun, 09 Nov 2003 15:38:18 -0500
From: Andrew Cagney <cagney@gnu.org>
> Hmm. So the "f" conversions are no longer considered obvious? The
> problem with "m" and "M" is that they no longer define the macro that
> we're replacing. That means things become a bit more complicated. Do
> you want me to replace SKIP_SOLIB_RESOLVER with a truly multi-arched
> function?
Yep. More generally, I'd prefer to see people try to consolidate
existing methods, or create a new "gdbarch has-a" relationship(1),
rather than add yet another architecture method. The architecture
vector contains so much redundancy that it is depressing.
gdbarch has-a shared library architecture. Yes, we defenitely need
that. I have some thoughts on it. But I want to finish SPARC and the
corefile stuff first...
Any way, for your case, make the default something like:
CORE_ADDR
cannot_skip_solib_resolver (struct gdbarch *gdbarch, CORE_ADDR pc)
{
#ifdef SKIP_SOLIB_RESOLVER
/* Ok the function's name is a lie. This is here to prop up old
architectures and should be deleted. */
return SKIP_SOLIB_RESOLVER(...);
#else
return 0;
#endif
}
Then the macro can be deprecated.
I'll get rid of the SKIP_SOLIB_RESOLVER macro completely, but
unfortunately I won't have time to do this before friday.
Mark
prev parent reply other threads:[~2003-11-10 21:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-09 12:07 Mark Kettenis
2003-11-09 13:39 ` Andrew Cagney
2003-11-09 17:41 ` Mark Kettenis
2003-11-09 20:38 ` Andrew Cagney
2003-11-10 21:49 ` Mark Kettenis [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=200311102149.hAALnli4000481@elgar.kettenis.dyndns.org \
--to=kettenis@chello.nl \
--cc=cagney@gnu.org \
--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