From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eli Zaretskii To: kettenis@wins.uva.nl Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA]: Convert the last FP opcode saved by FSAVE into a full opcode Date: Fri, 09 Feb 2001 06:58:00 -0000 Message-id: <200102091458.JAA00860@indy.delorie.com> References: <200102081828.NAA25535@indy.delorie.com> X-SW-Source: 2001-02/msg00151.html > From: Mark Kettenis > Date: 09 Feb 2001 14:27:02 +0100 > > Hmm, right now, in i387-tdep.c:i387_float_info() we have the following > code: > > printf_filtered ("Opcode: %s\n", > local_hex_string_custom (fop ? (fop | 0xd800) : 0, "04")); > > So I don't understand why you're missing those bits in the output of > "info float". I guess that you want "p $fop" to print the full opcode > too (without the missing bits). That's one reason, yes. Also, what about the platforms/configurations which don't use CLI? Do they all go through i387_float_info and printf_filtered? > I'm also somewhat concerned > about consistency between the various x86 targets. If we apply your > patch, targets that don't use the functions from i387-nat.c still > won't include the extra bits. We could fix those targets as well, can't we? > That said, I'm open to discussion. If other x86 maintainers prefer $fop to > contain the full opcode your change would in principle be fine with > me. Yes, please speak up your minds. > But even then, there still might be something wrong with your > patch. On UNIX, the kernel typically returns a dummy FSAVE/FXSAVE > state if the program didn't use the FPU (yet), where the opcode is all > zeroes. In that case I don't think that we want to add the 0xd800. I think my patch explicitly guards agains this. Here's the relevant snippet: + if (val) + val |= 0xd800; In other words, if the opcode is zero, it is left unaltered, exactly like in i387-tdep.c.