From: Hui Zhu <teawater@gmail.com>
To: Mark Kettenis <mark.kettenis@xs4all.nl>,
Michael Snyder <msnyder@vmware.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFA/prec] Make i386 handle segment register better
Date: Sun, 06 Sep 2009 15:06:00 -0000 [thread overview]
Message-ID: <daef60380909060805w4e0f499dgf229541b35f81af3@mail.gmail.com> (raw)
In-Reply-To: <daef60380909052352t2852d99avb4f3283a5eedf836@mail.gmail.com>
On Sun, Sep 6, 2009 at 14:52, Hui Zhu<teawater@gmail.com> wrote:
> Hi guys,
>
> Sorry I didn't do more test for this patch on amd64 before I check it in.
>
> But this patch really work not very good in amd64.
>
> For example:
>
> Process record: i386_process_record addr = 0x7ffff7b13cc9 signal = 0
> Process record: add mem addr = 0xffffffffffffffa8 len = 4 to record list.
> Process record: error reading memory at addr = 0xffffffffffffffa8 len = 4.
> Process record: failed to record execution log.
>
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x00007ffff7b13cc9 in pause () from /lib/libc.so.6
> (gdb) disassemble
> Dump of assembler code for function pause:
> 0x00007ffff7b13c70 <pause+0>: cmpl $0x0,0x2c93d1(%rip) # 0x7ffff7ddd048
> 0x00007ffff7b13c77 <pause+7>: jne 0x7ffff7b13c89 <pause+25>
> 0x00007ffff7b13c79 <pause+9>: mov $0x22,%eax
> 0x00007ffff7b13c7e <pause+14>: syscall
> 0x00007ffff7b13c80 <pause+16>: cmp $0xfffffffffffff001,%rax
> 0x00007ffff7b13c86 <pause+22>: jae 0x7ffff7b13cbd <pause+77>
> 0x00007ffff7b13c88 <pause+24>: retq
> 0x00007ffff7b13c89 <pause+25>: sub $0x18,%rsp
> 0x00007ffff7b13c8d <pause+29>: callq 0x7ffff7b60770
> 0x00007ffff7b13c92 <pause+34>: mov %rax,(%rsp)
> 0x00007ffff7b13c96 <pause+38>: mov $0x22,%eax
> 0x00007ffff7b13c9b <pause+43>: syscall
> 0x00007ffff7b13c9d <pause+45>: mov (%rsp),%rdi
> 0x00007ffff7b13ca1 <pause+49>: mov %rax,0x8(%rsp)
> 0x00007ffff7b13ca6 <pause+54>: callq 0x7ffff7b60740
> 0x00007ffff7b13cab <pause+59>: mov 0x8(%rsp),%rax
> 0x00007ffff7b13cb0 <pause+64>: add $0x18,%rsp
> 0x00007ffff7b13cb4 <pause+68>: cmp $0xfffffffffffff001,%rax
> 0x00007ffff7b13cba <pause+74>: jae 0x7ffff7b13cbd <pause+77>
> 0x00007ffff7b13cbc <pause+76>: retq
> 0x00007ffff7b13cbd <pause+77>: mov 0x2c42cc(%rip),%rcx #
> 0x7ffff7dd7f90
> 0x00007ffff7b13cc4 <pause+84>: xor %edx,%edx
> 0x00007ffff7b13cc6 <pause+86>: sub %rax,%rdx
> 0x00007ffff7b13cc9 <pause+89>: mov %edx,%fs:(%rcx)
> 0x00007ffff7b13ccc <pause+92>: or $0xffffffffffffffff,%rax
> 0x00007ffff7b13cd0 <pause+96>: jmp 0x7ffff7b13cbc <pause+76>
> End of assembler dump.
> (gdb) info reg
> rax 0xfffffffffffffffc -4
> rbx 0x4007c0 4196288
> rcx 0xffffffffffffffa8 -88
> rdx 0x4 4
> rsi 0x0 0
> rdi 0x1 1
> rbp 0x7fffffffe2e0 0x7fffffffe2e0
> rsp 0x7fffffffe2b8 0x7fffffffe2b8
> r8 0x7fffffffe210 140737488347664
> r9 0x7fffffffe170 140737488347504
> r10 0x7fffffffe040 140737488347200
> r11 0x346 838
> r12 0x400640 4195904
> r13 0x7fffffffe3b0 140737488348080
> r14 0x0 0
> r15 0x0 0
> rip 0x7ffff7b13cc9 0x7ffff7b13cc9 <pause+89>
> eflags 0x313 [ CF AF TF IF ]
> cs 0x33 51
> ss 0x2b 43
> ds 0x0 0
> es 0x0 0
> fs 0x0 0
> gs 0x0 0
> fctrl 0x37f 895
> fstat 0x0 0
> ftag 0xffff 65535
> fiseg 0x0 0
> fioff 0x0 0
> foseg 0x0 0
> fooff 0x0 0
> fop 0x0 0
> mxcsr 0x1f80 [ IM DM ZM OM UM PM ]
> (gdb) record stop
> Delete recorded log and stop recording?(y or n) y
> Process record: record_close
> (gdb) set disassemble-next-line on
> (gdb) si
> 0x00007ffff7b13ccc in pause () from /lib/libc.so.6
> 0x00007ffff7b13ccc <pause+92>: 48 83 c8 ff or $0xffffffffffffffff,%rax
> (gdb) info registers
> rax 0xfffffffffffffffc -4
> rbx 0x4007c0 4196288
> rcx 0xffffffffffffffa8 -88
> rdx 0x4 4
> rsi 0x0 0
> rdi 0x1 1
> rbp 0x7fffffffe2e0 0x7fffffffe2e0
> rsp 0x7fffffffe2b8 0x7fffffffe2b8
> r8 0x7fffffffe210 140737488347664
> r9 0x7fffffffe170 140737488347504
> r10 0x7fffffffe040 140737488347200
> r11 0x346 838
> r12 0x400640 4195904
> r13 0x7fffffffe3b0 140737488348080
> r14 0x0 0
> r15 0x0 0
> rip 0x7ffff7b13ccc 0x7ffff7b13ccc <pause+92>
> eflags 0x313 [ CF AF TF IF ]
> cs 0x33 51
> ss 0x2b 43
> ds 0x0 0
> es 0x0 0
> fs 0x0 0
> gs 0x0 0
> fctrl 0x37f 895
> fstat 0x0 0
> ftag 0xffff 65535
> fiseg 0x0 0
> fioff 0x0 0
> foseg 0x0 0
> fooff 0x0 0
> fop 0x0 0
> mxcsr 0x1f80 [ IM DM ZM OM UM PM ]
> (gdb) x 0x7ffff7dd7f90
> 0x7ffff7dd7f90: 0xffffffa8
> (gdb) x 0xffffffa8
> 0xffffffa8: Cannot access memory at address 0xffffffa8
> (gdb) x 0xffffffffffffffa8
> 0xffffffffffffffa8: Cannot access memory at address 0xffffffffffffffa8
> (gdb)
>
>
> The fs is same with gs, but "mov %edx,%fs:(%rcx)" is not same with
> "mov %edx,(%rcx)".
>
> I think remove this patch from gdb-cvs-head before 7.0 branch and
> make the segment reg clear is better.
>
> What do you think about it?
>
> Thanks,
> Hui
>
I make a patch for it. Please help me review it.
Thanks,
Hui
2009-09-06 Hui Zhu <teawater@gmail.com>
* i386-tdep.c (i386_record_check_override): Deleted.
(i386_record_lea_modrm): Ditto.
(i386_process_record): Ditto.
---
i386-tdep.c | 37 +++++++++++--------------------------
1 file changed, 11 insertions(+), 26 deletions(-)
--- a/i386-tdep.c
+++ b/i386-tdep.c
@@ -3148,26 +3148,6 @@ no_rm:
return 0;
}
-static int
-i386_record_check_override (struct i386_record_s *irp)
-{
- if (irp->override >= 0 && irp->override != X86_RECORD_DS_REGNUM)
- {
- ULONGEST orv, ds;
-
- regcache_raw_read_unsigned (irp->regcache,
- irp->regmap[irp->override],
- &orv);
- regcache_raw_read_unsigned (irp->regcache,
- irp->regmap[X86_RECORD_DS_REGNUM],
- &ds);
- if (orv != ds)
- return 1;
- }
-
- return 0;
-}
-
/* Record the value of the memory that willbe changed in current instruction
to "record_arch_list".
Return -1 if something wrong. */
@@ -3178,7 +3158,7 @@ i386_record_lea_modrm (struct i386_recor
struct gdbarch *gdbarch = irp->gdbarch;
uint64_t addr;
- if (i386_record_check_override (irp))
+ if (irp->override >= 0)
{
warning (_("Process record ignores the memory change "
"of instruction at address %s because it "
@@ -4060,7 +4040,7 @@ reswitch:
/* mov EAX */
case 0xa2:
case 0xa3:
- if (i386_record_check_override (&ir))
+ if (ir.override >= 0)
{
warning (_("Process record ignores the memory change "
"of instruction at address 0x%s because "
@@ -4478,8 +4458,13 @@ reswitch:
ir.regmap[X86_RECORD_REDI_REGNUM],
&tmpulongest);
- ir.override = X86_RECORD_ES_REGNUM;
- if (ir.aflag && i386_record_check_override (&ir))
+ regcache_raw_read_unsigned (ir.regcache,
+ ir.regmap[X86_RECORD_ES_REGNUM],
+ &es);
+ regcache_raw_read_unsigned (ir.regcache,
+ ir.regmap[X86_RECORD_DS_REGNUM],
+ &ds);
+ if (ir.aflag && (es != ds))
{
/* addr += ((uint32_t) read_register (I386_ES_REGNUM)) << 4; */
warning (_("Process record ignores the memory "
@@ -5103,7 +5088,7 @@ reswitch:
opcode = opcode << 8 | ir.modrm;
goto no_support;
}
- if (i386_record_check_override (&ir))
+ if (ir.override >= 0)
{
warning (_("Process record ignores the memory "
"change of instruction at "
@@ -5154,7 +5139,7 @@ reswitch:
else
{
/* sidt */
- if (i386_record_check_override (&ir))
+ if (ir.override >= 0)
{
warning (_("Process record ignores the memory "
"change of instruction at "
next prev parent reply other threads:[~2009-09-06 15:06 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-29 16:12 Hui Zhu
2009-08-29 21:34 ` Michael Snyder
2009-08-30 3:21 ` Hui Zhu
2009-09-05 2:42 ` Michael Snyder
2009-09-05 8:15 ` Mark Kettenis
2009-09-05 15:38 ` Hui Zhu
2009-09-06 6:52 ` Hui Zhu
2009-09-06 15:06 ` Hui Zhu [this message]
2009-09-07 0:07 ` Michael Snyder
2009-09-07 11:17 ` Hui Zhu
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=daef60380909060805w4e0f499dgf229541b35f81af3@mail.gmail.com \
--to=teawater@gmail.com \
--cc=gdb-patches@sourceware.org \
--cc=mark.kettenis@xs4all.nl \
--cc=msnyder@vmware.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