grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] fs: remove implicit compiler calls to memset/memcpy


From: Pete Batard
Subject: Re: [PATCH] fs: remove implicit compiler calls to memset/memcpy
Date: Mon, 18 Apr 2016 12:13:30 +0200
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2

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 the MSVC compiler error (if needed, I could create a compatible aliasing lib with gcc). But that's something I'd prefer to avoid because it's never that simple in the MSVC world, and I'm also compiling for multiple archs (x86 and ARM, possibly more in the future), which makes assembly workarounds an annoyance. Besides, I already have to patch the GRUB source anyway, with some MSVC specific quirks (some of which I doubt you guys would like [1]), so adding some more to my current patch series to remove the implicits is not exactly a big deal. But of course, I sure wouldn't mind minimizing the amount of code I need to patch to use GRUB in my scope, which is the whole point of this submission.

Where implicit memcpy is inserted is pretty much unpredictable

You're missing the purpose of my request. I'm not asking the GRUB project to do anything about predicting where memset/memcpy are going inserted, or even attempt to be preemptive about that in the future. I'm simply asking it to address the ones that were isolated with 100% accuracy (compiler flag to generate assembly with source + grep on said assembly) from using the current GRUB source in the specific context that I have. There's no "predictive" component in what I am requesting here, not even an implied one.

So, in case that is the crux of the issue, should this patch be integrated, I am not asking any GRUB contributor to try to keep conscious of or try to identify potential implicits as they go about modifying fs or any other parts of the code. It is in fact of little consequence if someone comes in and breaks the applied implicits removal the day after it is applied, as I am using GRUB as a git submodule, therefore it'll remain tied to the specific git rev where it isn't broken. And if I try to update the submodule, and identify breakage, I will of course submit a new patch to this list as needed.

and we're
not going to maintain memcpy-free environment because of this

Again, this is not what I am asking. This is a simple "you scratch my back, I'll scratch yours" request, that, in a way, is pretty much akin to asking the GRUB project to add extra parenthesis in _very specific_ parts of source, to make it more palatable when these specific parts are used with compilers that are not officially supported by the project, and as a one-off thing (i.e. without asking for anyone to be tasked to maintaining that new parenthesis layout going forward).

If you want to say: "Well, we don't official support MSVC, so we're not going to pick a patch that is essentially aimed at improving MSVC support, especially if only applies to a limited set of sources", that's fine with me. But please don't try to imply that the patch has a much larger scope than it actually does, as your justification for rejection, or that it is going to require any extra work/maintainance from GRUB contributors once applied.

Regards,

/Pete

[1] https://github.com/pbatard/efifs/blob/master/0001-GRUB-fixes-for-MSVC-compilation-part-1.patch#L366-L410



reply via email to

[Prev in Thread] Current Thread [Next in Thread]