Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Michael Snyder <msnyder@vmware.com>
To: Hui Zhu <teawater@gmail.com>
Cc: paawan oza <paawan1982@yahoo.com>,
	  "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
	 Mark Kettenis <mark.kettenis@xs4all.nl>
Subject: Re: final i386.floating.record.patch
Date: Sun, 23 Aug 2009 03:00:00 -0000	[thread overview]
Message-ID: <4A909B3E.9080304@vmware.com> (raw)
In-Reply-To: <daef60380908221813l7c0fc1e7q8cd089b33d169eb6@mail.gmail.com>

We just need a copyright assignment, and then one of us can check it in.

Oza, have you sent in your copyright assignment?
If not, see the file src/gdb/CONTRIBUTE.


Hui Zhu wrote:
> I think this patch is OK.  How do we continue?
> 
> Thanks,
> Hui
> 
> On Sat, Aug 22, 2009 at 00:30, paawan oza<paawan1982@yahoo.com> wrote:
>> Hu Hui,
>> please find the ChageLog and floating point patch attached as you suggested.
>> Sorry for not pasting it in email-body becasue of space and tabs issues.
>> Do we need to update wiki?
>> Regards,
>> Oza.
>>
>> --- On Wed, 8/19/09, Hui Zhu <teawater@gmail.com> wrote:
>>
>>> From: Hui Zhu <teawater@gmail.com>
>>> Subject: Re: final i386.floating.record.patch
>>> To: "paawan oza" <paawan1982@yahoo.com>
>>> Cc: "Michael Snyder" <msnyder@vmware.com>, "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>, "Mark Kettenis" <mark.kettenis@xs4all.nl>
>>> Date: Wednesday, August 19, 2009, 7:47 AM
>>> Oops, this is not the bug in fp
>>> patch.  Sorry for it.
>>>
>>> After patch http://sourceware.org/ml/gdb-patches/2009-08/msg00272.html
>>>
>>> Everything is OK.
>>>
>>> I post a new patch that remove space in the tail.
>>> I think you need write a changelog.  You can get a
>>> example from
>>> src/ChangeLog.  Please Let each line doesn't bigger
>>> than 72.
>>>
>>> Thanks,
>>> Hui
>>>
>>> On Wed, Aug 19, 2009 at 09:13, Hui Zhu<teawater@gmail.com>
>>> wrote:
>>>> Could you try cvs-head?
>>>>
>>>> On Tue, Aug 18, 2009 at 21:48, paawan oza<paawan1982@yahoo.com>
>>> wrote:
>>>>> Hi,
>>>>>
>>>>> Another analysis and observation is:
>>>>>
>>>>> I used gdb-6.8.50.20090803 and everything seemed
>>> okay.
>>>>> Hui used gdb-6.8.50.20090817 and patch was still
>>> the same and gdb threw these error.
>>>>> was there any thing major changed in gdb ?
>>>>>
>>>>> and gdb throws error in
>>>>> ../../src/gdb/utils.c:1200:
>>>>>
>>>>> which looks like somebody has allocated memory too
>>> much or something has gone wrong in error checking.
>>>>>
>>>>> the floating-point-patch is still the same, if it
>>> works fine with gdb-6.8.50.20090803, it is high unlikely
>>> that why should it throw memory allocation error with
>>> gdb-6.8.50.20090817 (unless system is dangerously low in
>>> virtual memory, swap space is full).
>>>>> Regards,
>>>>> Oza.
>>>>>
>>>>>
>>>>>
>>>>> --- On Mon, 8/17/09, paawan oza <paawan1982@yahoo.com>
>>> wrote:
>>>>>> From: paawan oza <paawan1982@yahoo.com>
>>>>>> Subject: Re: final i386.floating.record.patch
>>>>>> To: "Michael Snyder" <msnyder@vmware.com>,
>>> "Hui Zhu" <teawater@gmail.com>
>>>>>> Cc: "gdb-patches@sourceware.org"
>>> <gdb-patches@sourceware.org>,
>>> "Mark Kettenis" <mark.kettenis@xs4all.nl>
>>>>>> Date: Monday, August 17, 2009, 9:40 PM
>>>>>> Hi Hui,
>>>>>>
>>>>>> I test the same and it seems working fine.
>>> Another thing I
>>>>>> observe is, vertual memory is low problem and
>>> may be gdb's
>>>>>> virtual address space gets exhausted or any
>>> other limit!
>>>>>> highly unlikely though.
>>>>>>
>>>>>> please see the atached log.
>>>>>>
>>>>>>
>>> linux-p94d:/home/oza/mk_patch/take_diff/gdb_current/gdb-6.8.50.20090803/gdb
>>>>>> # ./gdb ./test_floats
>>>>>> GNU gdb (GDB) 6.8.50.20090803
>>>>>> 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/>...
>>>>>> Setting up the environment for debugging gdb.
>>>>>> Function "internal_error" not defined.
>>>>>> Make breakpoint pending on future shared
>>> library load? (y
>>>>>> or [n]) [answered N; input not from terminal]
>>>>>> Function "info_command" not defined.
>>>>>> Make breakpoint pending on future shared
>>> library load? (y
>>>>>> or [n]) [answered N; input not from terminal]
>>>>>>
>>> /home/oza/mk_patch/take_diff/gdb_current/gdb-6.8.50.20090803/gdb/.gdbinit:8:
>>>>>> Error in sourced command file:
>>>>>> No breakpoint number 0.
>>>>>> (gdb) start
>>>>>> Temporary breakpoint 1 at 0x8048c94: file
>>> ./test_floats.c,
>>>>>> line 196.
>>>>>> Starting program:
>>>>>>
>>> /home/oza/mk_patch/take_diff/gdb_current/gdb-6.8.50.20090803/gdb/test_floats
>>>>>> Temporary breakpoint 1, main () at
>>> ./test_floats.c:196
>>>>>> 196         init_floats();
>>>>>> (gdb) record
>>>>>> (gdb) c
>>>>>> Continuing.
>>>>>> result is 369.438751
>>>>>> result is 10.320001
>>>>>> result is 23.008301
>>>>>> result is 0.000000
>>>>>> result is 10.450000
>>>>>> result is 10.776012
>>>>>> result is 495830.968750
>>>>>> result is -181.778748
>>>>>> result is 12.525923
>>>>>> result is 2.195619
>>>>>> result is 5.055601
>>>>>> result is inf
>>>>>> result is inf
>>>>>> result is -0.988032
>>>>>> result is 0.154251
>>>>>> result is -6.405331
>>>>>> result is 1.537475
>>>>>> The next instruction is syscall exit_group.
>>> It will
>>>>>> make the program exit.  Do you want to stop
>>> the
>>>>>> program?([y] or n) y
>>>>>> Process record: inferior program stopped.
>>>>>>
>>>>>> Program received signal SIGTRAP,
>>> Trace/breakpoint trap.
>>>>>> 0xffffe405 in __kernel_vsyscall ()
>>>>>> (gdb)
>>>>>>
>>>>>> Regards,
>>>>>> Oza.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --- On Mon, 8/17/09, Hui Zhu <teawater@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> From: Hui Zhu <teawater@gmail.com>
>>>>>>> Subject: Re: final
>>> i386.floating.record.patch
>>>>>>> To: "Michael Snyder" <msnyder@vmware.com>
>>>>>>> Cc: "paawan oza" <paawan1982@yahoo.com>,
>>>>>> "gdb-patches@sourceware.org"
>>>>>> <gdb-patches@sourceware.org>,
>>>>>> "Mark Kettenis" <mark.kettenis@xs4all.nl>
>>>>>>> Date: Monday, August 17, 2009, 12:06 PM
>>>>>>> Get some error with this patch.
>>>>>>> cat fp.c
>>>>>>> #include <stdio.h>
>>>>>>> #include <math.h>
>>>>>>> #include <stdlib.h>
>>>>>>>
>>>>>>> /* the test intends to test following
>>> insns.
>>>>>>> flds faddp fstps fstpl fldl fxch fabs
>>> fdivrp fmulp
>>>>>> fsubrp
>>>>>>> fucomp fnstsw fsqrt
>>>>>>> fchs f2xm1 fyl2x fxtract fprem1 fld
>>> fdecstp fld1
>>>>>> fldl2t
>>>>>>> fldl2e FLDPI
>>>>>>> FLDLG2 FLDLN2
>>>>>>> FLDZ fincstp ffree fptan fpatan fincstp
>>> fsincos
>>>>>> frndint
>>>>>>> fscale fsin fcos fcmovb
>>>>>>> fcmovbe fcmove fcmovu fcmovnb fcmovnbe
>>> fsave frstor
>>>>>> fstsw
>>>>>>> */
>>>>>>>
>>>>>>> float no1,no2,no3,no4,no5,no6,no7;
>>>>>>> double x = 100.345, y = 25.7789;
>>>>>>> long double ldx =
>>> 88888888888888888888.88, ldy =
>>>>>>> 9999999999999999999.99;
>>>>>>> float result,resultd,resultld;
>>>>>>> float *float_memory;
>>>>>>>
>>>>>>> /* initialization of floats */
>>>>>>> void init_floats()
>>>>>>> {
>>>>>>>  no1 = 10.45;
>>>>>>>  no2 = 20.77;
>>>>>>>  no3 = 156.89874646;
>>>>>>>  no4 = 14.56;
>>>>>>>  no5 = 11.11;
>>>>>>>  no6 = 66.77;
>>>>>>>  no7 = 88.88;
>>>>>>>  float_memory = malloc(sizeof(float) *
>>> 4);
>>>>>>>  *float_memory = 256.256;
>>>>>>>  *(float_memory + 1) = 356.356;
>>>>>>>  *(float_memory + 2) = 456.456;
>>>>>>>  *(float_memory + 3) = 556.556;
>>>>>>> }
>>>>>>>
>>>>>>> /* marks FPU stack as empty */
>>>>>>> void empty_fpu_stack()
>>>>>>> {
>>>>>>>  asm ("ffree %st(1) \n\t"
>>>>>>>       "ffree %st(2) \n\t"
>>>>>>>       "ffree %st(3) \n\t"
>>>>>>>       "ffree %st(4) \n\t"
>>>>>>>       "ffree %st(5) \n\t"
>>>>>>>       "ffree %st(6) \n\t"
>>>>>>>       "ffree %st(7)");
>>>>>>> }
>>>>>>>
>>>>>>> /* tests floating point arithmatic */
>>>>>>> void test_arith_floats()
>>>>>>> {
>>>>>>>  result = no1 + no2 + no3 + no4 + no5 +
>>> no6 +
>>>>>> no7;
>>>>>>>  printf("result is %f\n",result);
>>>>>>>
>>>>>>>  result = fmodf(no2,no1);
>>>>>>>  printf("result is %f\n",result);
>>>>>>>
>>>>>>>  resultd = fmod(x,y);
>>>>>>>  printf("result is %f\n",resultd);
>>>>>>>
>>>>>>>  resultld = fmodl(ldy,ldy);
>>>>>>>  printf("result is %f\n",resultld);
>>>>>>>
>>>>>>>  result = fabsf(no1);
>>>>>>>  printf("result is %f\n",result);
>>>>>>>
>>>>>>>  result = no3 / no4;
>>>>>>>  printf("result is %f\n",result);
>>>>>>>
>>>>>>>  result = no1 * no2 * no3 * no4;
>>>>>>>  printf("result is %f\n",result);
>>>>>>>
>>>>>>>  result = no1 - no2 - no3 - no4;
>>>>>>>  printf("result is %f\n",result);
>>>>>>>
>>>>>>>
>>>>>>>  asm ("fld %0" : :"m"(*float_memory));
>>>>>>>  asm ("fchs");
>>>>>>>
>>>>>>>  /* test for f2xm1 */
>>>>>>>  asm ("fld %0" : :"m"(*float_memory));
>>>>>>>  asm ("f2xm1");
>>>>>>>
>>>>>>>  asm ("fyl2x");
>>>>>>>
>>>>>>>  asm ("fld %0" : :"m"(*float_memory));
>>>>>>>  asm ("fxtract");
>>>>>>>
>>>>>>>  asm ("fld %0" : :"m"(*float_memory));
>>>>>>>  asm ("fprem1");
>>>>>>>
>>>>>>>  /* decrement fpu stack pointer only
>>> status
>>>>>> register should
>>>>>>> get affected */
>>>>>>>  asm ("fld %0" : :"m"(*float_memory));
>>>>>>>
>>>>>>>  empty_fpu_stack();
>>>>>>>
>>>>>>>  asm ("fld1");
>>>>>>>  asm ("fldl2t");
>>>>>>>  asm ("fldl2e");
>>>>>>>  asm ("fldpi");
>>>>>>>  asm ("fldlg2");
>>>>>>>  asm ("fldln2");
>>>>>>>  asm ("fldz");
>>>>>>>
>>>>>>>  empty_fpu_stack();
>>>>>>>  /* finishing emptying the stack */
>>>>>>>
>>>>>>>  result = sqrt(no3);
>>>>>>>  printf("result is %f\n",result);
>>>>>>> }
>>>>>>>
>>>>>>> void test_log_exp_floats()
>>>>>>> {
>>>>>>>  result = log10(no3);
>>>>>>>  printf("result is %f\n",result);
>>>>>>>
>>>>>>>  result = log(no3);
>>>>>>>  printf("result is %f\n",result);
>>>>>>>
>>>>>>>  result = exp10(no3);
>>>>>>>  printf("result is %f\n",result);
>>>>>>>
>>>>>>>  result = exp(no3);
>>>>>>>  printf("result is %f\n",result);
>>>>>>> }
>>>>>>>
>>>>>>> void test_trigo_floats()
>>>>>>> {
>>>>>>>  result = sin(30);
>>>>>>>  printf("result is %f\n",result);
>>>>>>>
>>>>>>>  result = cos(30);
>>>>>>>  printf("result is %f\n",result);
>>>>>>>
>>>>>>>  result = tan(30);
>>>>>>>  printf("result is %f\n",result);
>>>>>>>
>>>>>>>  result = atan(30);
>>>>>>>  printf("result is %f\n",result);
>>>>>>>
>>>>>>>  asm ("fld %0" : :"m"(*float_memory));
>>>>>>>  asm ("fptan");
>>>>>>>
>>>>>>>  /* changes st1 and popping register
>>> stack */
>>>>>>>  asm ("fpatan");
>>>>>>>
>>>>>>>  asm("fincstp");
>>>>>>>  asm ("fld %0" : :"m"(float_memory));
>>>>>>>  asm ("fsincos");
>>>>>>>
>>>>>>>  asm ("fld %0" : :"m"(*float_memory));
>>>>>>>  asm ("frndint");
>>>>>>>
>>>>>>>  asm ("fld %0" : :"m"(*float_memory));
>>>>>>>  asm ("fld %0" :
>>> :"m"(*(float_memory+1)));
>>>>>>>  asm ("fscale");
>>>>>>>
>>>>>>>  empty_fpu_stack();
>>>>>>>
>>>>>>>  asm ("fld %0" : :"m"(*float_memory));
>>>>>>>  asm ("fsin");
>>>>>>>  asm ("fcos");
>>>>>>>
>>>>>>>  /* currently we assume condition likely
>>> and
>>>>>> always record
>>>>>>> the registers
>>>>>>>  code could be optimized only if the
>>> flag is set
>>>>>> then
>>>>>>> record */
>>>>>>>  asm ("fld %0" : :"m"(*float_memory));
>>>>>>>  asm ("fld %0" :
>>> :"m"(*(float_memory+1)));
>>>>>>>  asm ("fcmovb %st(1), %st");
>>>>>>>  asm ("fcmovbe %st(1), %st");
>>>>>>>  asm ("fcmove %st(1), %st");
>>>>>>>  asm ("fcmovu %st(1), %st");
>>>>>>>  asm ("fcmovnb %st(1), %st");
>>>>>>>  asm ("fcmovnbe %st(1), %st");
>>>>>>>
>>>>>>>  empty_fpu_stack();
>>>>>>>  /* finished emtyping the stack */
>>>>>>> }
>>>>>>>
>>>>>>> void test_compare_floats()
>>>>>>> {
>>>>>>>    ldy = 88888888888888888888.88;
>>>>>>>    if (ldx == ldy)
>>>>>>>      ldy =
>>>>>>> 7777777777777777777777777777.777;
>>>>>>>    else
>>>>>>>      ldy =
>>>>>>> 666666666666666666666666666.666;
>>>>>>> }
>>>>>>>
>>>>>>> /* test loading and saving of FPU
>>> environment */
>>>>>>> void test_fpu_env()
>>>>>>> {
>>>>>>>  asm ("fsave %0" : "=m"(*float_memory) :
>>> );
>>>>>>>  asm ("frstor %0" : :
>>> "m"(*float_memory));
>>>>>>>  asm ("fstsw %ax");
>>>>>>> }
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>>    init_floats();
>>>>>>>    test_arith_floats();
>>>>>>>    test_log_exp_floats();
>>>>>>>    test_trigo_floats();
>>>>>>>    test_compare_floats();
>>>>>>>    test_fpu_env();
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ./gdb ./a.out
>>>>>>> GNU gdb (GDB) 6.8.50.20090817-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/>...
>>>>>>> Setting up the environment for debugging
>>> gdb.
>>>>>>> Function "internal_error" not defined.
>>>>>>> Make breakpoint pending on future shared
>>> library load?
>>>>>> (y
>>>>>>> or [n])
>>>>>>> [answered N; input not from terminal]
>>>>>>> Function "info_command" not defined.
>>>>>>> Make breakpoint pending on future shared
>>> library load?
>>>>>> (y
>>>>>>> or [n])
>>>>>>> [answered N; input not from terminal]
>>>>>>> /home/teawater/gdb/bgdbno/gdb/.gdbinit:8:
>>> Error in
>>>>>> sourced
>>>>>>> command file:
>>>>>>> No breakpoint number 0.
>>>>>>> (gdb) start
>>>>>>> During symbol reading, DW_AT_name missing
>>> from
>>>>>>> DW_TAG_base_type.
>>>>>>> Temporary breakpoint 1 at 0x8048c74: file
>>> fp.c, line
>>>>>> 196.
>>>>>>> Starting program:
>>> /home/teawater/gdb/bgdbno/gdb/a.out
>>>>>>> Temporary breakpoint 1, main () at
>>> fp.c:196
>>>>>>> 196       init_floats();
>>>>>>> (gdb) record
>>>>>>> (gdb) c
>>>>>>> Continuing.
>>>>>>> ../../src/gdb/utils.c:1200:
>>> internal-error: virtual
>>>>>> memory
>>>>>>> exhausted.
>>>>>>> A problem internal to GDB has been
>>> detected,
>>>>>>> further debugging may prove unreliable.
>>>>>>> Quit this debugging session? (y or n) n
>>>>>>> ../../src/gdb/utils.c:1200:
>>> internal-error: virtual
>>>>>> memory
>>>>>>> exhausted.
>>>>>>> A problem internal to GDB has been
>>> detected,
>>>>>>> further debugging may prove unreliable.
>>>>>>> Create a core file of GDB? (y or n) n
>>>>>>>
>>>>>>> Program received signal SIGTRAP,
>>> Trace/breakpoint
>>>>>> trap.
>>>>>>> 0xb7eba9bc in memcpy () from
>>>>>> /lib/tls/i686/cmov/libc.so.6
>>>>>>> (gdb) quit
>>>>>>> A debugging session is active.
>>>>>>>
>>>>>>>     Inferior 1 [process 15657] will
>>> be
>>>>>>> killed.
>>>>>>>
>>>>>>> Quit anyway? (y or n) y
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Hui
>>>>>>>
>>>>>>> On Mon, Aug 17, 2009 at 05:16, Michael
>>> Snyder<msnyder@vmware.com>
>>>>>>> wrote:
>>>>>>>> paawan oza wrote:
>>>>>>>>> Hi Hui & Michael,
>>>>>>>>> Now we revert status registers
>>> also.
>>>>>>>>> please find the patch attached.
>>>>>>>>> I am sorry, if I am not pasting
>>> the patch in
>>>>>>> email-body due to tabs&spaces
>>>>>>>>> problem faced by Michael last
>>> time.
>>>>>>>>> Regards,
>>>>>>>>> Oza.
>>>>>>>> Looking good!
>>>>>>>>
>>>>>>>> There were some conflicts between
>>> your changes
>>>>>> and a
>>>>>>> check-in that
>>>>>>>> happened after your submission  --
>>>  I've taken
>>>>>> the
>>>>>>> liberty of merging
>>>>>>>> your changes with the cvs head,
>>> fixing up the
>>>>>>> conflicts.  Hope you
>>>>>>>> don't mind  --  merged patch
>>> attached.
>>>>>>>> I'll review your tests next.
>>>>>>>>
>>>>>>>> Can you write up a change log entry
>>> for this
>>>>>> patch?
>>>>>>>> Hui, Mark, any more comments?
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Michael
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>
>>


  reply	other threads:[~2009-08-23  1:32 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-21 16:59 paawan oza
2009-08-23  1:32 ` Hui Zhu
2009-08-23  3:00   ` Michael Snyder [this message]
2009-08-23  9:04     ` paawan oza
2009-08-23  9:29     ` paawan oza
2009-09-09  0:19 ` Michael Snyder
2009-09-10  1:13   ` paawan oza
2009-09-26  9:33   ` paawan oza
2009-12-10  7:55 ` Hui Zhu
  -- strict thread matches above, loose matches on Subject: below --
2009-08-18 15:22 paawan oza
2009-08-19  2:17 ` Hui Zhu
2009-08-19  2:44   ` Hui Zhu
2009-08-07  7:25 paawan oza
2009-08-07 15:50 ` Hui Zhu
2009-08-16 21:41 ` Michael Snyder
2009-08-17  9:17   ` Hui Zhu
2009-08-17 16:16     ` paawan oza
2009-08-04 13:06 paawan oza
2009-08-04 13:58 ` Hui Zhu
2009-08-04 14:18   ` paawan oza
2009-08-04 14:26   ` paawan oza
2009-08-04 14:43     ` Hui Zhu
2009-08-04 17:59       ` paawan oza
2009-08-05  1:29         ` Hui Zhu
2009-08-05  1:34         ` Michael Snyder
2009-08-05 13:48           ` paawan oza
2009-08-03 14:56 paawan oza
2009-08-03 20:04 ` Michael Snyder
2009-08-04  3:20 ` Hui Zhu
2009-08-04 13:03   ` paawan oza
2009-07-29 18:34 paawan oza
2009-07-30  6:24 ` Michael Snyder
2009-07-30 18:09   ` paawan oza
2009-08-03 14:59   ` paawan oza
2009-08-03 20:07     ` Michael Snyder
2009-07-27  1:09 i386.record.floating.point.patch : with more testing and assurity Michael Snyder
2009-07-29 18:30 ` final i386.floating.record.patch paawan oza
2009-07-29 22:01   ` Michael Snyder
2009-07-30  0:44     ` Michael Snyder
2009-07-30 18:00       ` paawan oza
2009-07-30 21:13         ` Michael Snyder

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=4A909B3E.9080304@vmware.com \
    --to=msnyder@vmware.com \
    --cc=gdb-patches@sourceware.org \
    --cc=mark.kettenis@xs4all.nl \
    --cc=paawan1982@yahoo.com \
    --cc=teawater@gmail.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