[RFA] Darwin: single step through sigreturn

[RFA] Darwin: single step through sigreturn

[Tristan Gingold]

Hi,

as other platform, single stepping through the sigreturn syscall is  
special: changing the cpu state
is useless as the context is restored.  The trace bit must be set in  
the to be restored context.

Tristan.

2008-12-04  Tristan Gingold  <gingold@adacore.com>

	* i386-darwin-nat.c (i386_darwin_sstep_at_sigreturn): New function.
	(amd64_darwin_sstep_at_sigreturn): New function.
	(darwin_set_sstep): The sigreturn is a special case: the trace flag
	must be set in the mcontext structure.

diff -c -p -r1.1 i386-darwin-nat.c
*** i386-darwin-nat.c	27 Nov 2008 09:23:01 -0000	1.1
--- i386-darwin-nat.c	4 Dec 2008 15:27:37 -0000
***************
*** 34,39 ****
--- 34,40 ----
   #include "i387-tdep.h"
   #include "gdbarch.h"
   #include "arch-utils.h"
+ #include "gdbcore.h"

   #include "darwin-nat.h"
   #include "i386-darwin-tdep.h"
*************** darwin_check_osabi (darwin_inferior *inf
*** 433,438 ****
--- 434,503 ----

   #define X86_EFLAGS_T 0x100UL

+ /* Returning from a signal trampoline is done by calling a
+    special system call (sigreturn).  This system call
+    restores the registers that were saved when the signal was
+    raised, including %eflags/%rflags.  That means that single-stepping
+    won't work.  Instead, we'll have to modify the signal context
+    that's about to be restored, and set the trace flag there.  */
+
+ static int
+ i386_darwin_sstep_at_sigreturn (x86_thread_state_t *regs)
+ {
+   static const gdb_byte darwin_syscall[] = { 0xcd, 0x80 }; /* int  
0x80 */
+   gdb_byte buf[sizeof (darwin_syscall)];
+
+   /* Check if PC is at a sigreturn system call.  */
+   if (target_read_memory (regs->uts.ts32.__eip, buf, sizeof (buf))  
== 0
+       && memcmp (buf, darwin_syscall, sizeof (darwin_syscall)) == 0
+       && regs->uts.ts32.__eax == 0xb8 /* SYS_sigreturn */)
+     {
+       ULONGEST uctx_addr;
+       ULONGEST mctx_addr;
+       ULONGEST flags_addr;
+       unsigned int eflags;
+
+       uctx_addr = read_memory_unsigned_integer (regs->uts.ts32.__esp  
+ 4, 4);
+       mctx_addr = read_memory_unsigned_integer (uctx_addr + 28, 4);
+
+       flags_addr = mctx_addr + 12 + 9 * 4;
+       read_memory (flags_addr, (gdb_byte *) &eflags, 4);
+       eflags |= X86_EFLAGS_T;
+       write_memory (flags_addr, (gdb_byte *) &eflags, 4);
+
+       return 1;
+     }
+   return 0;
+ }
+
+ static int
+ amd64_darwin_sstep_at_sigreturn (x86_thread_state_t *regs)
+ {
+   static const gdb_byte darwin_syscall[] = { 0x0f, 0x05 }; /*  
syscall */
+   gdb_byte buf[sizeof (darwin_syscall)];
+
+   /* Check if PC is at a sigreturn system call.  */
+   if (target_read_memory (regs->uts.ts64.__rip, buf, sizeof (buf))  
== 0
+       && memcmp (buf, darwin_syscall, sizeof (darwin_syscall)) == 0
+       && (regs->uts.ts64.__rax & 0xffffffff) == 0x20000b8 /*  
SYS_sigreturn */)
+     {
+       ULONGEST mctx_addr;
+       ULONGEST flags_addr;
+       unsigned int rflags;
+
+       mctx_addr = read_memory_unsigned_integer (regs->uts.ts64.__rdi  
+ 48, 8);
+       flags_addr = mctx_addr + 16 + 17 * 8;
+
+       /* AMD64 is little endian.  */
+       read_memory (flags_addr, (gdb_byte *) &rflags, 4);
+       rflags |= X86_EFLAGS_T;
+       write_memory (flags_addr, (gdb_byte *) &rflags, 4);
+
+       return 1;
+     }
+   return 0;
+ }
+
   void
   darwin_set_sstep (thread_t thread, int enable)
   {
*************** darwin_set_sstep (thread_t thread, int e
*** 448,459 ****
--- 513,527 ----
   			 kret, thread);
         return;
       }
+
     switch (regs.tsh.flavor)
       {
       case x86_THREAD_STATE32:
         {
   	__uint32_t bit = enable ? X86_EFLAGS_T : 0;
   	
+ 	if (enable && i386_darwin_sstep_at_sigreturn (&regs))
+ 	  return;
   	if ((regs.uts.ts32.__eflags & X86_EFLAGS_T) == bit)
   	  return;
   	regs.uts.ts32.__eflags = (regs.uts.ts32.__eflags & ~X86_EFLAGS_T)  
| bit;
*************** darwin_set_sstep (thread_t thread, int e
*** 466,471 ****
--- 534,541 ----
         {
   	__uint64_t bit = enable ? X86_EFLAGS_T : 0;

+ 	if (enable && amd64_darwin_sstep_at_sigreturn (&regs))
+ 	  return;
   	if ((regs.uts.ts64.__rflags & X86_EFLAGS_T) == bit)
   	  return;
   	regs.uts.ts64.__rflags = (regs.uts.ts64.__rflags & ~X86_EFLAGS_T)  
| bit;

Re: [RFA] Darwin: single step through sigreturn

[Mark Kettenis]

> From: Tristan Gingold <gingold@adacore.com>
> Date: Thu, 4 Dec 2008 16:28:25 +0100
> 
> Hi,
> 
> as other platform, single stepping through the sigreturn syscall is  
> special: changing the cpu state
> is useless as the context is restored.  The trace bit must be set in  
> the to be restored context.

Tristan,

It seems your mail client munges diffs (by wrapping lines).  Otherwise
it looks ok.

Mark

Re: [RFA] Darwin: single step through sigreturn

[Tristan Gingold]

On Dec 4, 2008, at 11:28 PM, Mark Kettenis wrote:

>> From: Tristan Gingold <gingold@adacore.com>
>> Date: Thu, 4 Dec 2008 16:28:25 +0100
>>
>> Hi,
>>
>> as other platform, single stepping through the sigreturn syscall is
>> special: changing the cpu state
>> is useless as the context is restored.  The trace bit must be set in
>> the to be restored context.
>
> Tristan,
>
> It seems your mail client munges diffs (by wrapping lines).

Argh, copy and cut issues.  Is it ok to attach the patches ?

>  Otherwise
> it looks ok.

Thanks, I have just committed it.

Re: [RFA] Darwin: single step through sigreturn

[Joel Brobecker]

> Argh, copy and cut issues.  Is it ok to attach the patches ?

Absolutely!

-- 
Joel

Re: [RFA] Darwin: single step through sigreturn

[Mark Kettenis]

> Date: Mon, 8 Dec 2008 18:48:05 +0100
> From: Joel Brobecker <brobecker@adacore.com>
> 
> > Argh, copy and cut issues.  Is it ok to attach the patches ?
> 
> Absolutely!

Not really.  Some MIME implementations do horrible things to diffs.

I'm probably fighting a losing battle here, but the preferred way to
send diffs is inline, using a sane mail client that doesn't add any
formatting of its own.

Re: [RFA] Darwin: single step through sigreturn

[Joel Brobecker]

> Not really.  Some MIME implementations do horrible things to diffs.

I'm really surprised. We had at least one instances in the past where
the diff was molested and thus impossible to apply (we asked the contributor
to fix, and he eventually did - not sure if he was using an attachement
or not, though). But otherwise, things have been working fine. And I was
always under the impression that the chances of having the diff be molested
was MUCH higher when sent inline. Maybe I'm wrong...

> I'm probably fighting a losing battle here, but the preferred way to
> send diffs is inline, using a sane mail client that doesn't add any
> formatting of its own.

I'm afraid you are right - I fought similar battles in the past and
lost them too...

-- 
Joel

Re: [RFA] Darwin: single step through sigreturn

[Daniel Jacobowitz]

On Mon, Dec 08, 2008 at 07:13:20PM +0100, Mark Kettenis wrote:
> > Date: Mon, 8 Dec 2008 18:48:05 +0100
> > From: Joel Brobecker <brobecker@adacore.com>
> > 
> > > Argh, copy and cut issues.  Is it ok to attach the patches ?
> > 
> > Absolutely!
> 
> Not really.  Some MIME implementations do horrible things to diffs.
> 
> I'm probably fighting a losing battle here, but the preferred way to
> send diffs is inline, using a sane mail client that doesn't add any
> formatting of its own.

Unfortunately, it's against the mail clients that we're losing the
battle...

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFA] Darwin: single step through sigreturn

[Joel Brobecker]

> Unfortunately, it's against the mail clients that we're losing the
> battle...

Would you prefer diffs as part of the email text if possible? I can
change my procedures, and I'm pretty sure my mailer won't muck things
up...

-- 
Joel

Re: [RFA] Darwin: single step through sigreturn

[Mark Kettenis]

> Date: Mon, 8 Dec 2008 21:44:10 +0100
> From: Joel Brobecker <brobecker@adacore.com>
> 
> > Unfortunately, it's against the mail clients that we're losing the
> > battle...
> 
> Would you prefer diffs as part of the email text if possible? I can
> change my procedures, and I'm pretty sure my mailer won't muck things
> up...

Thanks for the offer.  But the MIME attachments you send are fine
sinds they are text/plain and use a sane encoding (us-ascii).
Unfortunately some people's mailclients insist on using something
silly like quoted-printable or even base64.