|
From: Eric P. <eri...@or...> - 2011-04-16 07:47:12
Attachments:
vg-wine64.001.tgz
|
Hi Folks,
following bug entry #253657, here's another proposal to let wine run
under valgrind on amd64
processors
wine still requires segment support on amd64 as the thread information
under windows is
accessed through %gs segment override (it's through %fs on x86 <g>)
anyway, here's a patch-set to enhance valgrind support in the following way:
+ patches numbered VEX-[01-5]-*
- added support in VEX for all segment registers (including mov,
push/pop, iret insns which
are used in wine)
- added support in VEX for all fs & gs segment override
+ patches numbered 01*, 02*
- in coregrind, init properly the VEX states
- rework arch_prctl wrapper so that the real fs_base & gs_base are
actually set in kernel
+ patches numbered 03* VEX2*
- get rid of assume-fs-is-zero trick
+ patch numbered 04
- added some small test for segment override
the regression tests are run unmodified on my box
I do have however a couple of comments / questions:
- I added a dirty helper for changing the segment value. this will be
fully needed if one day
one implements idt/gdt/support (which isn't needed yet for wine, as
we only need to change
the gs_base value). most of the linux & darwin code currently also
only use this feature.
However, as this segment base value can be changed/used in kernel, I
add also to change
the real segment value in the helper (and also to force reset to 0 or
its ldt.entry32 value).
That's rather kludgey... comments welcome
- in VEX2* patch, I didn't renumbered all the fields after removal of
guest_FS_ZERO field in
guest_amd64 structure. I suppose I should :-(
- I didn't write the darwin modification (especially for getting rid of
the gs_0x60 hack). As I don't
have a test bed handy, I'd be happy to get in touch with a darwin64
dev where we could
test & experiment
A+
--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)
|
|
From: Julian S. <js...@ac...> - 2011-04-16 08:34:08
|
Eric, please can you open a bug report (if one doesn't already exist) and attach the patches to the bug? Patches on mailing list tend to get forgotten about. One tech question: how closely does your new segment support follow the x86 implementation of it? (You know that the 32-bit side does have segment register support, yes?) J On Saturday, April 16, 2011, Eric Pouech wrote: > Hi Folks, > > following bug entry #253657, here's another proposal to let wine run > under valgrind on amd64 > processors > wine still requires segment support on amd64 as the thread information > under windows is > accessed through %gs segment override (it's through %fs on x86 <g>) > > anyway, here's a patch-set to enhance valgrind support in the following > way: + patches numbered VEX-[01-5]-* > - added support in VEX for all segment registers (including mov, > push/pop, iret insns which > are used in wine) > - added support in VEX for all fs & gs segment override > + patches numbered 01*, 02* > - in coregrind, init properly the VEX states > - rework arch_prctl wrapper so that the real fs_base & gs_base are > actually set in kernel > + patches numbered 03* VEX2* > - get rid of assume-fs-is-zero trick > + patch numbered 04 > - added some small test for segment override > > the regression tests are run unmodified on my box > > I do have however a couple of comments / questions: > - I added a dirty helper for changing the segment value. this will be > fully needed if one day > one implements idt/gdt/support (which isn't needed yet for wine, as > we only need to change > the gs_base value). most of the linux & darwin code currently also > only use this feature. > However, as this segment base value can be changed/used in kernel, I > add also to change > the real segment value in the helper (and also to force reset to 0 or > its ldt.entry32 value). > That's rather kludgey... comments welcome > - in VEX2* patch, I didn't renumbered all the fields after removal of > guest_FS_ZERO field in > guest_amd64 structure. I suppose I should :-( > - I didn't write the darwin modification (especially for getting rid of > the gs_0x60 hack). As I don't > have a test bed handy, I'd be happy to get in touch with a darwin64 > dev where we could > test & experiment > > A+ |
|
From: Eric P. <eri...@or...> - 2011-04-16 08:56:37
|
Hi Julian Le 16/04/2011 10:26, Julian Seward a écrit : > Eric, please can you open a bug report (if one doesn't already > exist) and attach the patches to the bug? Patches on mailing > list tend to get forgotten about. well, I already got that answer from you more than a year ago on the very first version of the patch, and nothing happened <g>. not even a single comment on the web site (where several new PR about missing seg support on amd64 appeared, and got also ignored) to me, kde bugs site looks like a nice sink <g> > One tech question: how closely does your new segment support > follow the x86 implementation of it? (You know that the 32-bit > side does have segment register support, yes?) as I wrote, there is no ldt/gdt/idt support for now amd64 segment support slighty differs from x86: - es, ss, ds values are simply ignored. so they are seen are simple 16bit slots - fs & gs (in segment override) get their virtual address base from another CPU MST (fs_base & gs_base) => this is really different from x86 where the virtual address base is gotten from gdt/idt/ldt. it's only when fs & gs are changed, that the fs_base (resp gs_base) are intialiazed to the corresponding ldt/gdt/idt base address (note this can only be a 32bit value, whereas fs_base and gs_base use 64bit) => therefore the reasonable of seg override in amd64 is not to change the fs or gs values, it's more linked to changing their corresponding fs_base and gs_base MSR - I did nothing on cs (assuming that's is not going to change) - the pop and mov code is simply derived from x86 - the iret code has been changed (as the stack layout is not the same), but spirit remains - for the dirty_helper implementation, the x86 and amd64 are not supposed to go the same job - in x86 case, it computes the base address from the selector out of the gdt/idt/ldt - in amd64 case, it's used to change the value of a segment in order to force the recomputation of fs_base and gs_base. I hope the technical side is clearer A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams) |