On 2016.04.18 12:49, Vladimir 'phcoder' Serbinenko wrote:
In any case it's
not 2.02 material, so I put it lower in my priority list
Thanks for considering it further - much appreciated.
I should point out that there's obviously nothing blocking for me, so
I'm fine with any delay.
On 2016.04
Le 18 avr. 2016 20:36, "Andrei Borzenkov" a écrit :
>
> On Mon, Apr 18, 2016 at 1:13 PM, Pete Batard wrote:
> > On 2016.04.18 07:50, Vladimir 'phcoder' Serbinenko wrote:
> >>
> >> You can use asm to get around msvc limitations. Sth like
> >>
> >> .global memcpy
> >> memcpy:
> >>jmp grub_m
On Mon, Apr 18, 2016 at 1:13 PM, Pete Batard wrote:
> On 2016.04.18 07:50, Vladimir 'phcoder' Serbinenko wrote:
>>
>> You can use asm to get around msvc limitations. Sth like
>>
>> .global memcpy
>> memcpy:
>>jmp grub_memcpy
>
>
> Yes I'm well aware I could try to create my own library (or
On 2016.04.18 07:50, Vladimir 'phcoder' Serbinenko wrote:
You can use asm to get around msvc limitations. Sth like
.global memcpy
memcpy:
jmp grub_memcpy
Yes I'm well aware I could try to create my own library (or equivalent)
that redefines memcpy/memset, using some workaround to avoid
You can use asm to get around msvc limitations. Sth like
.global memcpy
memcpy:
jmp grub_memcpy
Where implicit memcpy is inserted is pretty much unpredictable and we're
not going to maintain memcpy-free environment because of this
Le Mon, Apr 11, 2016 à 1:50 AM, Pete Batard a écrit :
> O
On 2016.04.10 16:30, Vladimir 'phcoder' Serbinenko wrote:
Why is the same solution not suitable for you?
That's the first thing I attempted, but the MSVC compiler is uncooperative.
If you try to redefine memset/memcpy, you get the following compiler error:
error C2169: '_memcpy' : Intrinsic f
Le dim. 10 avr. 2016 15:53, Pete Batard a écrit :
> Hi,
>
> I am using the GRUB codebase to build generic read-only EFI file system
> drivers [1] and during that process, I found that some compilers (e.g.
> MSVC, but most likely others) may insert implicit calls to memset/memcpy
> when initializi
