From: Pedro Alves <pedro_alves@portugalmail.pt>
To: Pierre Muller <muller@ics.u-strasbg.fr>
Cc: 'Mark Kettenis' <mark.kettenis@xs4all.nl>, gdb-patches@sourceware.org
Subject: Re: [RFC-v2] Enhance backtrace for microsoft system DLL calls
Date: Thu, 24 Jan 2008 00:52:00 -0000 [thread overview]
Message-ID: <4797E13B.6040408@portugalmail.pt> (raw)
In-Reply-To: <003101c85696$6f4d9e20$4de8da60$@u-strasbg.fr>
Pierre Muller wrote:
> I wrote a i386_skip_noop function.
> Tested on cygwin target, no regressions found.
> The patch allows to get the backtrace of the main thread of gdb
> to come up to the functions that called the systems DLL.
> If I use ./gdb ./gdb with 'set new-console on'
> and use Ctrl-C on the debuggee gdb window.
> Without the patch, the backtrace only shows
> 3 levels in ntdll.dll and kernel32.dll
>
[ I forgot to say before:
This is great, thanks for doing this! ]
> Questions:
> 1) Is the 'nop' test useful or should it be removed?
>
> 2) Should we add other possible no-ops?
It is my opinion that it isn't needed, and the function that
detects the mov %edi,%edi should be called i386_skip_msft_hotpatch,
or i386_skip_hotpatch. The nop is a 2 byte op for a reason,
plus, I don't see the point of detecting a lot of patterns if
we know they're never emitted. Plus, if we ever need to augment
this hot-patching support to another different form, of detect the
5 bytes slack before, this is the natural place to do it.
Plus not detecting for a 1 byte nop, you can read 2 bytes at once.
(ok, that is going extreme :-) )
> 3) this call is used for all i386 targets, but it
> is probably useless for all operating systems but Microsoft Windows,
> so should it be called only for that OS, and if yes, how should
> we code this?
>
The way to do it would be to put a flag in i386's gdbarch_tdep,
but Daniel didn't think we need to keep this MSFT specific.
(adding a flag would at least prevent a needless memory read
on non Windows platforms)
> 4) Any suggestions to make the comment clearer will be
> most appreciated.
Grabbing my own comment from upthread, how about:
/* Some Microsoft's system dll functions start with a
`mov %edi,%edi' instruction, which is effectively a two byte `nop'.
This instruction is used for hot patching support, together with 5
bytes of slack before the function. Later, when hot-patching, the 2
byte op can be replaced with a relative jump to 5 bytes back. The 5
bytes slack is large enough to hold a jump into anywhere in
the 32-bit address space. */
If you find it interesting, you can add:
/* A two byte nop is used to be sure that no thread is executing
the instruction at byte 1 of the function, so the patching can be
performed atomically. */
--
Pedro Alves
next prev parent reply other threads:[~2008-01-24 0:52 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-10 16:45 [RFC] " Pierre Muller
2007-12-10 17:37 ` Pedro Alves
2007-12-10 18:08 ` Daniel Jacobowitz
2007-12-10 18:41 ` Pedro Alves
2007-12-11 10:44 ` Mark Kettenis
2007-12-11 17:29 ` Pierre Muller
2008-01-14 10:16 ` [RFC-v2] " Pierre Muller
2008-01-24 0:52 ` Pedro Alves [this message]
2008-01-24 17:51 ` Mark Kettenis
2008-01-25 14:16 ` [RFA] i386-tdep.c: Add i386_skip_noop function Pierre Muller
2008-01-25 16:38 ` Joel Brobecker
2008-01-25 16:46 ` [RFA] i386-tdep.c: Add i386_skip_noop function; updated Pierre Muller
2008-01-25 17:05 ` Mark Kettenis
2008-01-25 17:26 ` Joel Brobecker
2008-01-25 18:50 ` Pierre Muller
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=4797E13B.6040408@portugalmail.pt \
--to=pedro_alves@portugalmail.pt \
--cc=gdb-patches@sourceware.org \
--cc=mark.kettenis@xs4all.nl \
--cc=muller@ics.u-strasbg.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