I recommend changing the convention such that Descriptor is a pointer to the 
pointer -- this way the functions can remain one-liners and not introduce 
register side-effects (especially since you're choosing ebx -- trashing a 
nonvolatile).

On 2009-12-30, at 11:46 AM, Jose Catena wrote:

> -----Original Message-----
> From: ros-dev-boun...@reactos.org [mailto:ros-dev-boun...@reactos.org] On
> Behalf Of KJK::Hyperion
> 
>> Post them on bugzilla, assign them to me and Cc sginsb...@reactos.org
> 
> 
> Well, I submitted my first bug & patch to bugzilla.
> Before I submit more, I'd like to know if I did it correctly. I have many
> and I'll wait to know if should submit them this way.
> Couldn't cc to sginsb...@reactos.org, bugzilla doesn't know him.
> Based on the large amount and severity of bugs in the msvc build perhaps
> nobody is using it but me, plz let me know if you don't want any fixes to
> msvc build submitted.
> 
> The submitted bug & patch is as follows:
> 
> Bug# 5071 intrin_i.h: sgdt & lgdt fixed for msvc
> 
> In intrin_i.h there are two inline functions that are defined differently
> based on __GNUC__ or _MSV_VER. The _MSC_VER ones make ntoskrnl crash early
> on boot.
> As these functions were written, sgd & lgdt stored and loaded the gdt
> to/from the pointer variable passed instead of the location the pointer
> points to.
> Fixed and tested.
> Patch follows:
> 
> intrin_i.h
> 
> Ke386GetGlobalDescriptorTable(OUT PVOID Descriptor)
> {
> -     __asm sgdt [Descriptor]
> +     __asm {
> +             mov ebx, Descriptor
> +             sgdt [ebx];
> +     }
> }
> 
> Ke386SetGlobalDescriptorTable(IN PVOID Descriptor)
> {
> -     __asm lgdt [Descriptor]
> +     __asm {
> +             mov ebx, Descriptor;
> +             lgdt [ebx];
> +     }
> }
> 
> Jose Catena
> DIGIWAVES S.L.
> 
> 
> 
> _______________________________________________
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev

Best regards,
Alex Ionescu


_______________________________________________
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Reply via email to