On 29 April 2015 at 14:49, Leif Lindholm leif.lindholm@linaro.org wrote:
On 29 April 2015 at 12:48, Ard Biesheuvel ard.biesheuvel@linaro.org wrote:
In preparation of adding ARM support, this refactors the nochunk EFI param so that it does not populate the .data section, since that gets discarded on ARM.
Signed-off-by: Ard Biesheuvel ard.biesheuvel@linaro.org
drivers/firmware/efi/libstub/efi-stub-helper.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/firmware/efi/libstub/efi-stub-helper.c b/drivers/firmware/efi/libstub/efi-stub-helper.c index f07d4a67fa76..15c8b27121fd 100644 --- a/drivers/firmware/efi/libstub/efi-stub-helper.c +++ b/drivers/firmware/efi/libstub/efi-stub-helper.c @@ -30,7 +30,7 @@ */ #define EFI_READ_CHUNK_SIZE (1024 * 1024)
-static unsigned long __chunk_size = EFI_READ_CHUNK_SIZE; +bool __nochunk;
/*
- Allow the platform to override the allocation granularity: this allows
@@ -335,7 +335,7 @@ efi_status_t efi_parse_options(char *cmdline) while (*str) { if (!strncmp(str, "nochunk", 7)) { str += strlen("nochunk");
__chunk_size = -1UL;
__nochunk = true; } /* Group words together, delimited by "," */@@ -490,8 +490,8 @@ efi_status_t handle_cmdline_files(efi_system_table_t *sys_table_arg, size = files[j].size; while (size) { unsigned long chunksize;
if (size > __chunk_size)chunksize = __chunk_size;
if (!__nochunk && size > EFI_READ_CHUNK_SIZE)chunksize = EFI_READ_CHUNK_SIZE; else chunksize = size;-- 1.9.1
I have no issues with this patch, but I have a question: Can we assume that we never will need to have initialised data in the stub? If so, we should try to get that formally stated somewhere, or this will happen again.
Indeed. There was a similar issue with linux_banner, although that seems to have resolved itself.
Actually, when using 'hidden' visibility, there are no GOT related issues anymore since all global references will be PC relative. Only, Russell and his toolchain museum are never going to go for that :-(
If not, I did something fairly ugly (but functional) when I came across this issue last time I looked at bringing the old code up to date; I added a __stubdata storage type qualifier that was empty on all other archs and created a .stubdata section for this variable on ARM.
Yes, I noticed that. My pov is that if we are going to support .data, we could just as well put it in .data and not abuse .piggydata for that.