From: Hui Zhu <teawater@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>, msnyder@vmware.com
Cc: gdb-patches@sourceware.org
Subject: Re: Bug in i386_process_record?
Date: Mon, 24 Aug 2009 03:15:00 -0000 [thread overview]
Message-ID: <daef60380908231700i47c2b1e7kae31369237b419b4@mail.gmail.com> (raw)
In-Reply-To: <daef60380908231642h1d85f7b5r70a5856647335f4c@mail.gmail.com>
On Mon, Aug 24, 2009 at 07:42, Hui Zhu<teawater@gmail.com> wrote:
> If I am right, this is from the old memory manager -- segment manager.
> X86 is a old arch and support it.
>
> Now, most of OS include Linux, they don't use this MM, they use page
> manager that X86 support it too (X86 is crazy). So they set the value
> of segment reg to 0.
>
> For the gdb, the value of segment reg is not the really value.
> cs 0x73 115
> ss 0x7b 123
> ds 0x7b 123
> es 0x7b 123
> fs 0x0 0
> gs 0x33 51
> I have tried some insn that use segment reg such as string ops insn.
> I found that the value of this segment reg cannot affect anything.
>
> And prec just support Linux now. I have move
> "set_gdbarch_process_record (gdbarch, i386_process_record);" to
> i386-linux-tdep.c.
>
> This patch doesn't add any more thing, just fix the bug. And this bug
> seems affect a lot of program (for example, Oza's fp example). I
> suggest let it in first. After that, we can find a good way to handle
> the segment reg better.
>
> What do you think about it?
>
> Thanks,
> Hui
>
> On Mon, Aug 24, 2009 at 02:24, Eli Zaretskii <eliz@gnu.org> wrote:
>>
>> > From: Hui Zhu <teawater@gmail.com>
>> > Date: Sun, 23 Aug 2009 12:29:33 +0800
>> > Cc: gdb-patches ml <gdb-patches@sourceware.org>
>> >
>> > read_register (I386_ES_REGNUM)
>> > This value is not the value of ES. This is number of TLB.
>>
>> On what OS?
>
Please let me show a example for it.
cat memrange-reverse.c
/* This testcase is part of GDB, the GNU debugger.
Copyright 2009 Free Software Foundation, Inc.
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>. */
#include <string.h>
#define SIZE_BLOB1 1024
#define SIZE_BLOB2 256
char blob1[SIZE_BLOB1], blob2[SIZE_BLOB2];
int main ()
{
int i;
memset (blob1, 'a', sizeof (blob1));
blob1[sizeof (blob1) - 1] = '\0';
memset (blob2, 'b', sizeof (blob2));
blob2[sizeof (blob2) - 1] = '\0';
for (i = 2; i < 8; i++)
{
memcpy (blob1 + (sizeof (blob1) / i), blob2, sizeof (blob2));
}
return 0; /* end of main */
}
gcc -g memrange-reverse.c
gdb ./a.out
GNU gdb (GDB) 6.8.50.20090807-cvs
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
(gdb) start
Temporary breakpoint 1 at 0x80483b5: file memrange-reverse.c, line 29.
Starting program: /home/teawater/Desktop/a.out
Temporary breakpoint 1, main () at memrange-reverse.c:29
29 memset (blob1, 'a', sizeof (blob1));
(gdb) x blob1
0x8049660 <blob1>: 0x00000000
#This address is what we really want to set.
(gdb) b *0xb7eec4e7
Breakpoint 2 at 0xb7eec4e7
(gdb) set disassemble-next-line on
(gdb) c
Continuing.
Breakpoint 2, 0xb7eec4e7 in memset () from /lib/tls/i686/cmov/libc.so.6
0xb7eec4e7 <memset+55>: f3 ab rep stos %eax,%es:(%edi)
#This is the code that will set the blob1
(gdb) disassemble
Dump of assembler code for function memset:
0xb7eec4b0 <memset+0>: cld
0xb7eec4b1 <memset+1>: push %edi
0xb7eec4b2 <memset+2>: mov 0x8(%esp),%edx
0xb7eec4b6 <memset+6>: mov 0x10(%esp),%ecx
0xb7eec4ba <memset+10>: movzbl 0xc(%esp),%eax
0xb7eec4bf <memset+15>: jecxz 0xb7eec4ed <memset+61>
0xb7eec4c1 <memset+17>: mov %edx,%edi
0xb7eec4c3 <memset+19>: and $0x3,%edx
0xb7eec4c6 <memset+22>: je 0xb7eec4d9 <memset+41>
0xb7eec4c8 <memset+24>: jp 0xb7eec4ce <memset+30>
0xb7eec4ca <memset+26>: stos %al,%es:(%edi)
0xb7eec4cb <memset+27>: dec %ecx
0xb7eec4cc <memset+28>: je 0xb7eec4ed <memset+61>
0xb7eec4ce <memset+30>: stos %al,%es:(%edi)
0xb7eec4cf <memset+31>: dec %ecx
0xb7eec4d0 <memset+32>: je 0xb7eec4ed <memset+61>
0xb7eec4d2 <memset+34>: xor $0x1,%edx
0xb7eec4d5 <memset+37>: jne 0xb7eec4d9 <memset+41>
0xb7eec4d7 <memset+39>: stos %al,%es:(%edi)
0xb7eec4d8 <memset+40>: dec %ecx
0xb7eec4d9 <memset+41>: mov %ecx,%edx
0xb7eec4db <memset+43>: shr $0x2,%ecx
0xb7eec4de <memset+46>: and $0x3,%edx
0xb7eec4e1 <memset+49>: imul $0x1010101,%eax,%eax
0xb7eec4e7 <memset+55>: rep stos %eax,%es:(%edi)
0xb7eec4e9 <memset+57>: mov %edx,%ecx
0xb7eec4eb <memset+59>: rep stos %al,%es:(%edi)
0xb7eec4ed <memset+61>: mov 0x8(%esp),%eax
0xb7eec4f1 <memset+65>: pop %edi
0xb7eec4f2 <memset+66>: ret
End of assembler dump.
(gdb) info reg $edi
edi 0x8049660 134518368
(gdb) info reg $es
es 0x7b 123
#rep stos %eax,%es:(%edi)
$edi + 0 = 0x8049660 blob1
$edi + $es != 0x8049660 blob1
Thanks,
Hui
next prev parent reply other threads:[~2009-08-24 0:01 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4A7BA1DE.6010103@vmware.com>
2009-08-10 9:33 ` Hui Zhu
2009-08-10 22:12 ` Michael Snyder
2009-08-11 6:20 ` Hui Zhu
2009-08-11 18:31 ` Hui Zhu
2009-08-16 16:12 ` Hui Zhu
2009-08-18 5:35 ` Michael Snyder
2009-08-18 11:52 ` Hui Zhu
2009-08-21 3:23 ` Hui Zhu
2009-08-23 3:15 ` Michael Snyder
2009-08-23 3:33 ` Hui Zhu
2009-08-23 4:13 ` Michael Snyder
2009-08-23 9:04 ` Hui Zhu
2009-08-23 17:37 ` Hui Zhu
2009-08-23 18:23 ` Michael Snyder
2009-08-23 18:32 ` Eli Zaretskii
2009-08-23 23:53 ` Hui Zhu
2009-08-23 23:56 ` Daniel Jacobowitz
2009-08-24 0:01 ` Hui Zhu
2009-08-24 7:46 ` Eli Zaretskii
2009-08-24 3:15 ` Hui Zhu [this message]
2009-08-24 19:20 ` Eli Zaretskii
2009-08-25 5:04 ` Hui Zhu
2009-08-25 18:45 ` Eli Zaretskii
2009-08-26 3:19 ` Hui Zhu
2009-08-26 3:27 ` Eli Zaretskii
2009-08-26 7:20 ` Hui Zhu
2009-08-26 17:37 ` Eli Zaretskii
2009-08-27 0:05 ` Michael Snyder
2009-08-27 0:32 ` Michael Snyder
2009-08-27 1:50 ` Hui Zhu
2009-08-27 15:35 ` Hui Zhu
2009-08-28 1:44 ` Michael Snyder
2009-08-28 2:14 ` Hui Zhu
2009-08-28 6:16 ` Michael Snyder
2009-08-28 8:46 ` Hui Zhu
2009-08-30 1:12 ` Michael Snyder
2009-08-27 1:44 ` Hui Zhu
2009-08-29 6:51 ` Hui Zhu
2009-08-24 20:31 ` Eli Zaretskii
2009-08-25 6:53 ` Hui Zhu
2009-08-23 18:24 ` Eli Zaretskii
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=daef60380908231700i47c2b1e7kae31369237b419b4@mail.gmail.com \
--to=teawater@gmail.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--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