Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Hui Zhu <teawater@gmail.com>
To: paawan oza <paawan1982@yahoo.com>
Cc: Michael Snyder <msnyder@vmware.com>,
	Mark Kettenis <mark.kettenis@xs4all.nl>,
	 	"pedro@codesourcery.com" <pedro@codesourcery.com>,
	 	"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: i386.record.floating.point.patch : with more testing and assurity
Date: Sun, 05 Jul 2009 10:15:00 -0000	[thread overview]
Message-ID: <daef60380907050315s6426209cx2b184445fc213b8a@mail.gmail.com> (raw)
In-Reply-To: <210466.48533.qm@web112501.mail.gq1.yahoo.com>

Hi Paawan,

1.  gcc -g -O2   -I. -I../../src/gdb -I../../src/gdb/common
-I../../src/gdb/config -DLOCALEDIR="\"/usr/local/share/locale\""
-DHAVE_CONFIG_H -I../../src/gdb/../include/opcode
-I../../src/gdb/../readline/.. -I../bfd -I../../src/gdb/../bfd
-I../../src/gdb/../include -I../libdecnumber
-I../../src/gdb/../libdecnumber  -I../../src/gdb/gnulib -Ignulib
-DMI_OUT=1 -DTUI=1  -Wall -Wdeclaration-after-statement
-Wpointer-arith -Wformat-nonliteral -Wno-pointer-sign -Wno-unused
-Wno-switch -Wno-char-subscripts -Werror -c -o i386-tdep.o -MT
i386-tdep.o -MMD -MP -MF .deps/i386-tdep.Tpo ../../src/gdb/i386-tdep.c
cc1: warnings being treated as errors
../../src/gdb/i386-tdep.c: In function 'i386_process_record':
../../src/gdb/i386-tdep.c:4985: warning: implicit declaration of
function 'paddr_nz'
../../src/gdb/i386-tdep.c:4985: warning: format '%s' expects type
'char *', but argument 2 has type 'int'
make[2]: *** [i386-tdep.o] Error 1
make[2]: Leaving directory `/media/disk/gdb/bgdb/gdb'
make[1]: *** [all-gdb] Error 2
make[1]: Leaving directory `/media/disk/gdb/bgdb'
make: *** [all] Error 2

paddr_nz was removed.  Please update your patch follow cvs-head.

2. +#define I386_SAVE_FPU_REGS		0xFFFD
+#define I386_SAVE_FPU_ENV		0xFFFE
+#define I386_SAVE_FPU_ENV_REG_STACK	0xFFFF

They just used in prec right?  Maybe you can move them close to record
code in i386-tedp.c.

3. +static int i386_record_floats(struct i386_record_s *ir, uint32_t iregnum)
+{
+  int i;
+
+  /* Oza : push/pop of fpu stack is going to happen
+     currently we store st0-st7 registers, but we need not store all
registers all the time.
+     using fstatus, we use 11-13 bits which gives us stack top and
hence we optimize our storage.
+     alternatively we can use ftag register too */
+  if (I386_SAVE_FPU_REGS == iregnum)
+    {
+      for (i=I386_ST0_REGNUM;i<=I386_ST0_REGNUM+7;i++)
+        {
+          if (record_arch_list_add_reg (ir->regcache,i))
+            return -1;
+        }
+    }
About the number of fp regs.  Please use the code:
#define I387_ST0_REGNUM(tdep) ((tdep)->st0_regnum)
#define I387_NUM_XMM_REGS(tdep) ((tdep)->num_xmm_regs)
#define I387_MM0_REGNUM(tdep) ((tdep)->mm0_regnum)

#define I387_FCTRL_REGNUM(tdep) (I387_ST0_REGNUM (tdep) + 8)
#define I387_FSTAT_REGNUM(tdep) (I387_FCTRL_REGNUM (tdep) + 1)
#define I387_FTAG_REGNUM(tdep) (I387_FCTRL_REGNUM (tdep) + 2)
#define I387_FISEG_REGNUM(tdep) (I387_FCTRL_REGNUM (tdep) + 3)
#define I387_FIOFF_REGNUM(tdep) (I387_FCTRL_REGNUM (tdep) + 4)
#define I387_FOSEG_REGNUM(tdep) (I387_FCTRL_REGNUM (tdep) + 5)
#define I387_FOOFF_REGNUM(tdep) (I387_FCTRL_REGNUM (tdep) + 6)
#define I387_FOP_REGNUM(tdep) (I387_FCTRL_REGNUM (tdep) + 7)
#define I387_XMM0_REGNUM(tdep) (I387_ST0_REGNUM (tdep) + 16)
#define I387_MXCSR_REGNUM(tdep) \
  (I387_XMM0_REGNUM (tdep) + I387_NUM_XMM_REGS (tdep))

They are in i387-tdep.h.

And maybe you can try function i387_supply_fsave and i387_collect_fsave.


4.  Your code's format is not very well.  Please make it like the code in cvs.



Thanks,
Hui




On Sat, Jul 4, 2009 at 13:19, paawan oza<paawan1982@yahoo.com> wrote:
>
> Hi,
>
> Actually, the initial patch which I submitted were using them.
> but as I have incorporated Hui's comments I have removed those constants completely.
> in the sense I have no longer extended the enumration.
>
> but of course, those registers are recorded as and when required.
> e.g. (ffree insn changes FTAG register, so we record it)
>
> Regards,
> Oza.
>
> --- On Sat, 7/4/09, Michael Snyder <msnyder@vmware.com> wrote:
>
>> From: Michael Snyder <msnyder@vmware.com>
>> Subject: Re: i386.record.floating.point.patch : with more testing and assurity
>> To: "paawan oza" <paawan1982@yahoo.com>
>> Cc: "Mark Kettenis" <mark.kettenis@xs4all.nl>, "pedro@codesourcery.com" <pedro@codesourcery.com>, "teawater@gmail.com" <teawater@gmail.com>, "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
>> Date: Saturday, July 4, 2009, 3:19 AM
>> paawan oza wrote:
>> > Hi,
>> >
>> > In My understanding the point was like below.
>> > in the patch there were following register extended in
>> enumeration in i386-tdep.h
>> >
>> > I386_FSTAT,
>> > I386_FTAG,       I386_FISEG,
>> > I386_FIOFF,
>> > I386_FOSEG,
>> > I386_FOOFF,
>> > I386_FOP
>> >
>> >
>> > According to Hui in some of his previous mails...his
>> idea was
>> >> FCTRL, FOP and so on are the fp reg of
>> amd64.  For now, prec is still
>> >> not support amd64 And amd64's support are in
>> amd64-tedp.... files.  >Change i386_regnum is not a
>> good idea. I suggest you divide fp patch to 2 >parts. One
>> is for i386, the other for amd64. For now, just send i386
>> patch >for review.  And send amd64 patch when prec
>> support amd64"
>> >
>> >
>> > while, my idea/understanding is:
>> > FCTRL, FOP registers are not only a part of amd64, but
>> also part of i386 (x87 FPU unit) also.
>> > so according to me these registers are part of i386
>> also and it needed to be also in i386-tdep.h.
>> >
>> > Regards,
>> > Oza.
>>
>> I'm not sure why you want to add those constants to
>> i386-tdep.h,
>> when the rest of your patch does not seem to use them.
>>
>>
>
>
>
>


  reply	other threads:[~2009-07-05 10:15 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-04  5:19 paawan oza
2009-07-05 10:15 ` Hui Zhu [this message]
     [not found] <992589.56162.qm@web112513.mail.gq1.yahoo.com>
2009-07-26 19:10 ` Mark Kettenis
  -- strict thread matches above, loose matches on Subject: below --
2009-07-26 14:27 paawan oza
2009-07-26 22:51 ` Michael Snyder
2009-07-27  1:09 ` Michael Snyder
2009-07-27  2:33 ` Samuel Bronson
2009-07-06 19:09 paawan oza
2009-07-06 19:05 paawan oza
2009-07-08  9:00 ` Hui Zhu
2009-07-12  9:52 ` Michael Snyder
2009-07-12 18:12   ` Michael Snyder
2009-07-06 19:03 paawan oza
2009-07-06 19:01 paawan oza
2009-07-03 18:55 paawan oza
2009-07-03 21:52 ` Michael Snyder
2009-07-02  7:40 paawan oza
2009-07-02  3:39 paawan oza
2009-07-02  3:34 paawan oza
2009-07-01 16:17 paawan oza
2009-07-05 18:33 ` Mark Kettenis
2009-07-01 16:02 paawan oza
2009-07-01 16:14 ` Mark Kettenis
2009-07-01 16:01 paawan oza
2009-07-01 15:59 paawan oza
2009-07-02  2:02 ` Hui Zhu
2009-06-30 15:05 paawan oza
2009-07-01  5:53 ` Hui Zhu
2009-07-12 11:12 ` Michael Snyder
2009-07-12 17:47   ` paawan oza
2009-07-13  0:38     ` Michael Snyder
2009-07-13 17:03       ` Hui Zhu
2009-07-13 20:16         ` Michael Snyder
2009-07-15  9:21           ` Hui Zhu
2009-07-19  3:27             ` paawan oza
2009-07-18 23:36           ` paawan oza
2009-06-30 13:23 paawan oza
2009-06-30 13:38 ` Pedro Alves
2009-06-30 13:42 ` Mark Kettenis
2009-06-04 14:50 paawan oza

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