From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: brobecker@adacore.com
Cc: pierre.muller@ics-cnrs.unistra.fr, gdb-patches@sourceware.org
Subject: Re: [RFC] Improve amd64 prologue analysis
Date: Wed, 15 Dec 2010 23:07:00 -0000 [thread overview]
Message-ID: <201012152306.oBFN6x6N019463@glazunov.sibelius.xs4all.nl> (raw)
In-Reply-To: <20101214070535.GO2596@adacore.com> (message from Joel Brobecker on Tue, 14 Dec 2010 11:05:35 +0400)
> Date: Tue, 14 Dec 2010 11:05:35 +0400
> From: Joel Brobecker <brobecker@adacore.com>
>
> Hi Mark,
>
> > I think that your code does indeed catch some
> > instructions that are not covered by my patch,
> > especially in Windows DLL.
>
> If Pierre were to submit a patch that merges both our changes,
> do you think it would have a chance of being included?
>
> The alternative is to start working on a pdata/xdata unwinder,
> but I don't see myself having the time to look into that anytime
> soon (not within the next 12 months).
>
> You mentioned that, if we have prologue instruction parsers, they should
> be Windows-specific. But I would think that this extra level of
> precaution is unnecessary, since the prologue analyzer should almost
> never be used on the other platforms where we have the DWARF frame info.
> Is that wishful thinking?
Many years ago we realized that prologue analyzers are a dead end.
Compilers will continue to invent silly new ways to set up a stack
frame and save registers, and we'll forever play catch up. Then amd64
showed up and the folks who designed the ABI actually had the insight
to make unwind information pretty much mandatory. As a result we
survived very well without an amd64 prologue analyzer. I hope you'll
understand my reluctance to add one after managing 7 years or so
without. So if support for pdata/xdata gets added I would expect that
the prologue analyzer won't be needed on 64-bit Windows either. At
that point the prologue analyzer will become dead code and we should
remove it again. By not adding the prologue analyzer to other
platforms we'll increase the chance that will indeed be possible.
The fact that this is for a an OS that in my view should never have
been supported by GDB, that has a 64-bit ABI that I consider horribly
broken doesn't help. If you stick it somewhere where I don't need to
look at it, I won't care as much.
next prev parent reply other threads:[~2010-12-15 23:07 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-15 17:28 Pierre Muller
2010-11-18 17:22 ` Joel Brobecker
2010-11-19 8:15 ` Pierre Muller
2010-11-19 17:20 ` Joel Brobecker
2010-11-19 22:50 ` Pierre Muller
2010-12-14 7:05 ` Joel Brobecker
2010-12-14 9:58 ` Pedro Alves
2010-12-15 23:07 ` Mark Kettenis [this message]
2010-12-16 4:15 ` Joel Brobecker
2010-11-24 21:19 ` Mark Kettenis
2010-11-24 22:15 ` Joel Brobecker
2010-11-24 22:26 ` Joel Brobecker
2010-11-25 13:39 ` Mark Kettenis
2010-11-25 16:30 ` Joel Brobecker
2010-11-25 19:19 ` Kai Tietz
2010-11-24 22:17 ` Joel Brobecker
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=201012152306.oBFN6x6N019463@glazunov.sibelius.xs4all.nl \
--to=mark.kettenis@xs4all.nl \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=pierre.muller@ics-cnrs.unistra.fr \
/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