Re: Build RISC-V 32-bit UEFI target fails with kernel.org riscv64 toolchain
On Fri, Mar 27, 2020 at 10:51 PM Daniel Kiper wrote: > > Adding Alex... > > On Fri, Mar 27, 2020 at 03:01:15PM +0800, Bin Meng wrote: > > Hi, > > > > I tried to build RISC-V 32-bit UEFI target using kernel.org riscv64 > > toolchain: > > https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/7.3.0/x86_64-gcc-7.3.0-nolibc_riscv64-linux.tar.xz > > > > $ ./configure --target=riscv32 --with-platform=efi CC=gcc > > TARGET_CC=/share/toolchains/gcc-7.3.0-nolibc/riscv64-linux/bin/riscv64-linux-gcc > > TARGET_OBJCOPY=/share/toolchains/gcc-7.3.0-nolibc/riscv64-linux/bin/riscv64-linux-objcopy > > TARGET_STRIP=/share/toolchains/gcc-7.3.0-nolibc/riscv64-linux/bin/riscv64-linux-strip > > TARGET_NM=/share/toolchains/gcc-7.3.0-nolibc/riscv64-linux/bin/riscv64-linux-nm > > TARGET_RANLIB=/share/toolchains/gcc-7.3.0-nolibc/riscv64-linux/bin/riscv64-linux-ranlib;make > > > > It failed with the following message: > > > > cat syminfo.lst | sort | gawk -f ./genmoddep.awk > moddep.lst || (rm > > -f moddep.lst; exit 1) > > __ashldi3 in affs is not defined > > __ashldi3 in afs is not defined > > __lshrdi3 in afs is not defined > > __ashldi3 in bfs is not defined > > __lshrdi3 in bfs is not defined > > __ucmpdi2 in btrfs is not defined > > __ashldi3 in crc64 is not defined > > __ashldi3 in cryptodisk is not defined > > __lshrdi3 in cryptodisk is not defined > > __ashldi3 in ctz_test is not defined > > __ctzsi2 in ctz_test is not defined > > __ashldi3 in disk is not defined > > __lshrdi3 in disk is not defined > > grub_divmod64s in div_test is not defined > > __ashldi3 in exfat is not defined > > __lshrdi3 in exfat is not defined > > __ashldi3 in ext2 is not defined > > __lshrdi3 in ext2 is not defined > > __ashldi3 in fat is not defined > > __lshrdi3 in fat is not defined > > __ashldi3 in fshelp is not defined > > __lshrdi3 in fshelp is not defined > > __ashldi3 in jfs is not defined > > __lshrdi3 in jfs is not defined > > __ashldi3 in minix is not defined > > __ashldi3 in minix2 is not defined > > __ashldi3 in minix2_be is not defined > > __ashldi3 in minix3 is not defined > > __ashldi3 in minix3_be is not defined > > __ashldi3 in minix_be is not defined > > __ashldi3 in mmap is not defined > > __lshrdi3 in mmap is not defined > > __ashldi3 in mul_test is not defined > > __ashldi3 in net is not defined > > __lshrdi3 in net is not defined > > __lshrdi3 in nilfs2 is not defined > > __ashldi3 in ntfs is not defined > > __lshrdi3 in ntfs is not defined > > __ashldi3 in ntfscomp is not defined > > __lshrdi3 in ntfscomp is not defined > > __ashldi3 in part_gpt is not defined > > __ashldi3 in part_msdos is not defined > > __ashldi3 in sfs is not defined > > __ashldi3 in shift_test is not defined > > __ashrdi3 in shift_test is not defined > > __lshrdi3 in shift_test is not defined > > __lshrdi3 in squash4 is not defined > > __ashldi3 in udf is not defined > > __lshrdi3 in udf is not defined > > __ashldi3 in ufs1 is not defined > > __lshrdi3 in ufs1 is not defined > > __ashldi3 in ufs1_be is not defined > > __lshrdi3 in ufs1_be is not defined > > __ashldi3 in ufs2 is not defined > > __lshrdi3 in ufs2 is not defined > > __ashldi3 in xfs is not defined > > __ashrdi3 in xfs is not defined > > __lshrdi3 in xfs is not defined > > __ashldi3 in xzio is not defined > > __lshrdi3 in xzio is not defined > > __ashldi3 in zfs is not defined > > __lshrdi3 in zfs is not defined > > __lshrdi3 in zfscrypt is not defined > > __ashldi3 in zstd is not defined > > Makefile:47234: recipe for target 'moddep.lst' failed > > > > If I switched to kernel.org riscv32 toolchain, the problem went away. > > https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/7.3.0/x86_64-gcc-7.3.0-nolibc_riscv32-linux.tar.xz > > > > $ ./configure --target=riscv32 --with-platform=efi CC=gcc > > TARGET_CC=/share/toolchains/gcc-7.3.0-nolibc/riscv32-linux/bin/riscv32-linux-gcc > > TARGET_OBJCOPY=/share/toolchains/gcc-7.3.0-nolibc/riscv32-linux/bin/riscv32-linux-objcopy > > TARGET_STRIP=/share/toolchains/gcc-7.3.0-nolibc/riscv32-linux/bin/riscv32-linux-strip > > TARGET_NM=/share/toolchains/gcc-7.3.0-nolibc/riscv32-linux/bin/riscv32-linux-nm > > TARGET_RANLIB=/share/toolchains/gcc-7.3.0-nolibc/riscv32-linux/bin/riscv32-linux-ranlib;make > > Are you sure that above mentioned riscv64 compiler supports riscv32 targets? > I think so. It looks the missing symbols are from libgcc, but I see both riscv64 and riscv32 toolchains ship 32-bit and 64-bit libgcc libraries. Not sure why grub build complains. The same 64-bit toolchain can be used to cross-compile 32-bit U-Boot and Linux. Regards, Bin ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] grub.d: Use linuxefi and initrdefi commands if platform is efi
On Fri, Mar 27, 2020 at 10:44:09AM -0400, Konrad Rzeszutek Wilk wrote: > On Wed, Mar 25, 2020 at 06:38:54PM +0100, Daniel Kiper wrote: > > On Mon, Mar 23, 2020 at 07:53:15PM +0800, Tianjia Zhang wrote: > > > When the platform is EFI platform, use 'linuxefi' and 'initrdefi' > > > commands instead of 'linux' and 'initrd'. > > > > > > Signed-off-by: Jia Zhang > > > Signed-off-by: Tianjia Zhang > > > > Sorry, NAK! We do not want more "linuxefi" kinda commands in the GRUB > > upstream. > > Are you saying that the existing 'linux' and 'initrd' should be fixed > to work under EFI? Exactly, this is the plan for after 2.06 release. Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v4 1/2] lvm: add lvm cache logical volume handling
On Thu, Mar 19, 2020 at 01:56:13PM +0800, Michael Chang wrote: > The lvm cache logical volume is the logical volume consisting of the original > and the cache pool logical volume. The original is usually on a larger and > slower storage device while the cache pool is on a smaller and faster one. The > performance of the original volume can be improved by storing the frequently > used data on the cache pool to utilize the greater performance of faster > device. > > The default cache mode "writethrough" ensures that any data written will be > stored both in the cache and on the origin LV, therefore grub can be straight > to read the original lv as no data loss is guarenteed. > > The second cache mode is "writeback", which delays writing from the cache pool > back to the origin LV to have increased performance. The drawback is potential > data loss if losing the associated cache device. > > During the boot time grub reads the LVM offline i.e. LVM volumes are not > activated and mounted, hence it should be fine to read directly from original > lv since all cached data should have been flushed back in the process of > taking > it offline. > > It is also not much helpful to the situation by adding fsync calls to the > install code. The fsync did not force to write back dirty cache to the > original > device and rather it would update associated cache metadata to complete the > write transaction with the cache device. IOW the writes to cached blocks still > go only to the cache device. > > To write back dirty cache, as lvm cache did not support dirty cache flush per > block range, there'no way to do it for file. On the other hand the "cleaner" > policy is implemented and can be used to write back "all" dirty blocks in a > cache, which effectively drain all dirty cache gradually to attain and last in > the "clean" state, which can be useful for shrinking or decommissioning a > cache. The result and effect is not what we are looking for here. > > In conclusion, as it seems no way to enforce file writes to the original > device, grub may suffer from power failure as it cannot assemble the cache > device and read the dirty data from it. However since the case is only > applicable to writeback mode which is sensitive to data lost in nature, I'd > still like to propose my (relatively simple) patch and treat reading dirty > cache as improvement. > > Signed-off-by: Michael Chang Reviewed-by: Daniel Kiper Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: fs/ntfscomp.c:82:11: error: ‘flg’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
On 3/27/20 7:45 AM, Daniel Kiper wrote: >> _is_ a 'clear' env expected/recommended/required for a grub2 build? > > You control your own build environment. So, if you add options which are > not supported by the GRUB then there is pretty good chance that the > build or generated output will fall apart at some point. However, if you > think a given compiler option should be supported by the GRUB or even > used by default please provide a patch with good explanation why we > should take it. sure. builds using opensuse buildservice online are currently failing using 'default' build env. atm, that appears to be just to due to the patches, discussed here, not yet landing in release used. i can't yet say what, if anything, of the default _flags_ in use cause a problem -- need to check again if optimization, as causing a problem here, is among them. >> if so, does this need to be handled at config time? > > I am not sure what do you mean by that. just a simple check at 'configure' ... e.g. if optimization is set, raise an error. thx ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Build RISC-V 32-bit UEFI target fails with kernel.org riscv64 toolchain
Adding Alex... On Fri, Mar 27, 2020 at 03:01:15PM +0800, Bin Meng wrote: > Hi, > > I tried to build RISC-V 32-bit UEFI target using kernel.org riscv64 toolchain: > https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/7.3.0/x86_64-gcc-7.3.0-nolibc_riscv64-linux.tar.xz > > $ ./configure --target=riscv32 --with-platform=efi CC=gcc > TARGET_CC=/share/toolchains/gcc-7.3.0-nolibc/riscv64-linux/bin/riscv64-linux-gcc > TARGET_OBJCOPY=/share/toolchains/gcc-7.3.0-nolibc/riscv64-linux/bin/riscv64-linux-objcopy > TARGET_STRIP=/share/toolchains/gcc-7.3.0-nolibc/riscv64-linux/bin/riscv64-linux-strip > TARGET_NM=/share/toolchains/gcc-7.3.0-nolibc/riscv64-linux/bin/riscv64-linux-nm > TARGET_RANLIB=/share/toolchains/gcc-7.3.0-nolibc/riscv64-linux/bin/riscv64-linux-ranlib;make > > It failed with the following message: > > cat syminfo.lst | sort | gawk -f ./genmoddep.awk > moddep.lst || (rm > -f moddep.lst; exit 1) > __ashldi3 in affs is not defined > __ashldi3 in afs is not defined > __lshrdi3 in afs is not defined > __ashldi3 in bfs is not defined > __lshrdi3 in bfs is not defined > __ucmpdi2 in btrfs is not defined > __ashldi3 in crc64 is not defined > __ashldi3 in cryptodisk is not defined > __lshrdi3 in cryptodisk is not defined > __ashldi3 in ctz_test is not defined > __ctzsi2 in ctz_test is not defined > __ashldi3 in disk is not defined > __lshrdi3 in disk is not defined > grub_divmod64s in div_test is not defined > __ashldi3 in exfat is not defined > __lshrdi3 in exfat is not defined > __ashldi3 in ext2 is not defined > __lshrdi3 in ext2 is not defined > __ashldi3 in fat is not defined > __lshrdi3 in fat is not defined > __ashldi3 in fshelp is not defined > __lshrdi3 in fshelp is not defined > __ashldi3 in jfs is not defined > __lshrdi3 in jfs is not defined > __ashldi3 in minix is not defined > __ashldi3 in minix2 is not defined > __ashldi3 in minix2_be is not defined > __ashldi3 in minix3 is not defined > __ashldi3 in minix3_be is not defined > __ashldi3 in minix_be is not defined > __ashldi3 in mmap is not defined > __lshrdi3 in mmap is not defined > __ashldi3 in mul_test is not defined > __ashldi3 in net is not defined > __lshrdi3 in net is not defined > __lshrdi3 in nilfs2 is not defined > __ashldi3 in ntfs is not defined > __lshrdi3 in ntfs is not defined > __ashldi3 in ntfscomp is not defined > __lshrdi3 in ntfscomp is not defined > __ashldi3 in part_gpt is not defined > __ashldi3 in part_msdos is not defined > __ashldi3 in sfs is not defined > __ashldi3 in shift_test is not defined > __ashrdi3 in shift_test is not defined > __lshrdi3 in shift_test is not defined > __lshrdi3 in squash4 is not defined > __ashldi3 in udf is not defined > __lshrdi3 in udf is not defined > __ashldi3 in ufs1 is not defined > __lshrdi3 in ufs1 is not defined > __ashldi3 in ufs1_be is not defined > __lshrdi3 in ufs1_be is not defined > __ashldi3 in ufs2 is not defined > __lshrdi3 in ufs2 is not defined > __ashldi3 in xfs is not defined > __ashrdi3 in xfs is not defined > __lshrdi3 in xfs is not defined > __ashldi3 in xzio is not defined > __lshrdi3 in xzio is not defined > __ashldi3 in zfs is not defined > __lshrdi3 in zfs is not defined > __lshrdi3 in zfscrypt is not defined > __ashldi3 in zstd is not defined > Makefile:47234: recipe for target 'moddep.lst' failed > > If I switched to kernel.org riscv32 toolchain, the problem went away. > https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/7.3.0/x86_64-gcc-7.3.0-nolibc_riscv32-linux.tar.xz > > $ ./configure --target=riscv32 --with-platform=efi CC=gcc > TARGET_CC=/share/toolchains/gcc-7.3.0-nolibc/riscv32-linux/bin/riscv32-linux-gcc > TARGET_OBJCOPY=/share/toolchains/gcc-7.3.0-nolibc/riscv32-linux/bin/riscv32-linux-objcopy > TARGET_STRIP=/share/toolchains/gcc-7.3.0-nolibc/riscv32-linux/bin/riscv32-linux-strip > TARGET_NM=/share/toolchains/gcc-7.3.0-nolibc/riscv32-linux/bin/riscv32-linux-nm > TARGET_RANLIB=/share/toolchains/gcc-7.3.0-nolibc/riscv32-linux/bin/riscv32-linux-ranlib;make Are you sure that above mentioned riscv64 compiler supports riscv32 targets? Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: fs/ntfscomp.c:82:11: error: ‘flg’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
On Thu, Mar 26, 2020 at 04:10:05AM -0700, PGNet Dev wrote: > On 3/26/20 1:39 AM, Paul Menzel wrote: > > > I am unable to reproduce this with > > 1st sanity re-check: > > > > I _am_ able to reproduce this consistently, with same error. > > > > I've tested now on multiple machines; not identical, but all similarly > opensuse + GCC10 dev envs ... > > > > > > Here is the code in question: > > snip > > > Why is it complaining complaining in line 82 and not 78, where `flg` is > > already accessed? > > On 3/26/20 3:39 AM, Michael Chang wrote: > > Looking into build log, the build option seems to have been overridden > > with CFLAGS settings like this. > > > > CFLAGS="-O3 -Wall -fstack-protector-strong -funwind-tables > > -fasynchronous-unwind-tables -fmessage-length=0 -grecord-gcc-switches > > -march=native -mtune=native" > > > > I'm not sure if -O3 is considered as supported since that will result > > in larger binaries we are striving to reduce all the time. Also the > > optimization it brings would require careful review if we don't enable > > it by default. > > > > In addition, -fstack-protector-strong breaks the build even harder with > > a lot of __stack_chk_fail undefined symbol in the modules. > > > > If going with default build option, I also don't have this compliation > > error. > > > indeed. > > building with > > unset CC CPP > + unset LD CFLAGS CPPFLAGS CXXFLAGS > > ./bootstrap > ./autogen.sh > > ./configure \ > --prefix=/usr/local/grub-build-test > > make V=1 > > completes without error, and installs, > > > /usr/local/grub-build-test/bin/grub-mkrescue --version > /usr/local/grub-build-test/bin/grub-mkrescue (GRUB) 2.05 > > > which I can certainly manage easily enough for local build. > > > If going with default build option > > _is_ a 'clear' env expected/recommended/required for a grub2 build? You control your own build environment. So, if you add options which are not supported by the GRUB then there is pretty good chance that the build or generated output will fall apart at some point. However, if you think a given compiler option should be supported by the GRUB or even used by default please provide a patch with good explanation why we should take it. > if so, does this need to be handled at config time? I am not sure what do you mean by that. Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] grub.d: Use linuxefi and initrdefi commands if platform is efi
On Wed, Mar 25, 2020 at 06:38:54PM +0100, Daniel Kiper wrote: > On Mon, Mar 23, 2020 at 07:53:15PM +0800, Tianjia Zhang wrote: > > When the platform is EFI platform, use 'linuxefi' and 'initrdefi' > > commands instead of 'linux' and 'initrd'. > > > > Signed-off-by: Jia Zhang > > Signed-off-by: Tianjia Zhang > > Sorry, NAK! We do not want more "linuxefi" kinda commands in the GRUB > upstream. Are you saying that the existing 'linux' and 'initrd' should be fixed to work under EFI? Thanks. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] efi: add missed space in GRUB_EFI_GLOBAL_VARIABLE_GUID
On Fri, Mar 27, 2020 at 12:50:31PM +, Flavio Suligoi wrote:
> Hi Vladimir and Adrian,
>
> > On 3/27/20 1:11 PM, Vladimir 'phcoder' Serbinenko wrote:
> > > Could you explain why we would need this patch? It changes nothing
> > AFAICT
> >
> > It's a cosmetic change, there is one space character missing before the
> > last
> > value in the curly braces:
>
> Exactly, this is a cosmetic patch only.
> I'm working on a new EFI feature for our custom boards and I noticed this
> missed space.
>
> > >> #define GRUB_EFI_GLOBAL_VARIABLE_GUID \
> > >> - { 0x8BE4DF61, 0x93CA, 0x11d2, { 0xAA, 0x0D, 0x00, 0xE0, 0x98, 0x03,
> > >> 0x2B,0x8C }}
> > >> + { 0x8BE4DF61, 0x93CA, 0x11d2, { 0xAA, 0x0D, 0x00, 0xE0, 0x98, 0x03,
> > >> 0x2B, 0x8C }}
I will take this cleanup patch...
Reviewed-by: Daniel Kiper
Daniel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
RE: [PATCH] efi: add missed space in GRUB_EFI_GLOBAL_VARIABLE_GUID
Hi Vladimir and Adrian,
>
> On 3/27/20 1:11 PM, Vladimir 'phcoder' Serbinenko wrote:
> > Could you explain why we would need this patch? It changes nothing
> AFAICT
>
> It's a cosmetic change, there is one space character missing before the
> last
> value in the curly braces:
Exactly, this is a cosmetic patch only.
I'm working on a new EFI feature for our custom boards and I noticed this
missed space.
>
> >> #define GRUB_EFI_GLOBAL_VARIABLE_GUID \
> >> - { 0x8BE4DF61, 0x93CA, 0x11d2, { 0xAA, 0x0D, 0x00, 0xE0, 0x98, 0x03,
> >> 0x2B,0x8C }}
> >> + { 0x8BE4DF61, 0x93CA, 0x11d2, { 0xAA, 0x0D, 0x00, 0xE0, 0x98, 0x03,
> >> 0x2B, 0x8C }}
> Adrian
>
> --
> .''`. John Paul Adrian Glaubitz
> : :' : Debian Developer - glaub...@debian.org
> `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
> `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] efi: add missed space in GRUB_EFI_GLOBAL_VARIABLE_GUID
On 3/27/20 1:11 PM, Vladimir 'phcoder' Serbinenko wrote:
> Could you explain why we would need this patch? It changes nothing AFAICT
It's a cosmetic change, there is one space character missing before the last
value in the curly braces:
>> #define GRUB_EFI_GLOBAL_VARIABLE_GUID \
>> - { 0x8BE4DF61, 0x93CA, 0x11d2, { 0xAA, 0x0D, 0x00, 0xE0, 0x98, 0x03,
>> 0x2B,0x8C }}
>> + { 0x8BE4DF61, 0x93CA, 0x11d2, { 0xAA, 0x0D, 0x00, 0xE0, 0x98, 0x03,
>> 0x2B, 0x8C }}
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] efi: add missed space in GRUB_EFI_GLOBAL_VARIABLE_GUID
Could you explain why we would need this patch? It changes nothing AFAICT
On Fri, Mar 27, 2020, 12:01 Flavio Suligoi wrote:
> Signed-off-by: Flavio Suligoi
> ---
> include/grub/efi/api.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/grub/efi/api.h b/include/grub/efi/api.h
> index d6f4de1..937058d 100644
> --- a/include/grub/efi/api.h
> +++ b/include/grub/efi/api.h
> @@ -1295,7 +1295,7 @@ struct grub_efi_runtime_services
>(*convert_pointer) (grub_efi_uintn_t debug_disposition, void **address);
>
> #define GRUB_EFI_GLOBAL_VARIABLE_GUID \
> - { 0x8BE4DF61, 0x93CA, 0x11d2, { 0xAA, 0x0D, 0x00, 0xE0, 0x98, 0x03,
> 0x2B,0x8C }}
> + { 0x8BE4DF61, 0x93CA, 0x11d2, { 0xAA, 0x0D, 0x00, 0xE0, 0x98, 0x03,
> 0x2B, 0x8C }}
>
>
>grub_efi_status_t
> --
> 2.7.4
>
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] efi: add missed space in GRUB_EFI_GLOBAL_VARIABLE_GUID
Signed-off-by: Flavio Suligoi
---
include/grub/efi/api.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/grub/efi/api.h b/include/grub/efi/api.h
index d6f4de1..937058d 100644
--- a/include/grub/efi/api.h
+++ b/include/grub/efi/api.h
@@ -1295,7 +1295,7 @@ struct grub_efi_runtime_services
(*convert_pointer) (grub_efi_uintn_t debug_disposition, void **address);
#define GRUB_EFI_GLOBAL_VARIABLE_GUID \
- { 0x8BE4DF61, 0x93CA, 0x11d2, { 0xAA, 0x0D, 0x00, 0xE0, 0x98, 0x03,
0x2B,0x8C }}
+ { 0x8BE4DF61, 0x93CA, 0x11d2, { 0xAA, 0x0D, 0x00, 0xE0, 0x98, 0x03, 0x2B,
0x8C }}
grub_efi_status_t
--
2.7.4
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Build RISC-V 32-bit UEFI target fails with kernel.org riscv64 toolchain
Hi, I tried to build RISC-V 32-bit UEFI target using kernel.org riscv64 toolchain: https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/7.3.0/x86_64-gcc-7.3.0-nolibc_riscv64-linux.tar.xz $ ./configure --target=riscv32 --with-platform=efi CC=gcc TARGET_CC=/share/toolchains/gcc-7.3.0-nolibc/riscv64-linux/bin/riscv64-linux-gcc TARGET_OBJCOPY=/share/toolchains/gcc-7.3.0-nolibc/riscv64-linux/bin/riscv64-linux-objcopy TARGET_STRIP=/share/toolchains/gcc-7.3.0-nolibc/riscv64-linux/bin/riscv64-linux-strip TARGET_NM=/share/toolchains/gcc-7.3.0-nolibc/riscv64-linux/bin/riscv64-linux-nm TARGET_RANLIB=/share/toolchains/gcc-7.3.0-nolibc/riscv64-linux/bin/riscv64-linux-ranlib;make It failed with the following message: cat syminfo.lst | sort | gawk -f ./genmoddep.awk > moddep.lst || (rm -f moddep.lst; exit 1) __ashldi3 in affs is not defined __ashldi3 in afs is not defined __lshrdi3 in afs is not defined __ashldi3 in bfs is not defined __lshrdi3 in bfs is not defined __ucmpdi2 in btrfs is not defined __ashldi3 in crc64 is not defined __ashldi3 in cryptodisk is not defined __lshrdi3 in cryptodisk is not defined __ashldi3 in ctz_test is not defined __ctzsi2 in ctz_test is not defined __ashldi3 in disk is not defined __lshrdi3 in disk is not defined grub_divmod64s in div_test is not defined __ashldi3 in exfat is not defined __lshrdi3 in exfat is not defined __ashldi3 in ext2 is not defined __lshrdi3 in ext2 is not defined __ashldi3 in fat is not defined __lshrdi3 in fat is not defined __ashldi3 in fshelp is not defined __lshrdi3 in fshelp is not defined __ashldi3 in jfs is not defined __lshrdi3 in jfs is not defined __ashldi3 in minix is not defined __ashldi3 in minix2 is not defined __ashldi3 in minix2_be is not defined __ashldi3 in minix3 is not defined __ashldi3 in minix3_be is not defined __ashldi3 in minix_be is not defined __ashldi3 in mmap is not defined __lshrdi3 in mmap is not defined __ashldi3 in mul_test is not defined __ashldi3 in net is not defined __lshrdi3 in net is not defined __lshrdi3 in nilfs2 is not defined __ashldi3 in ntfs is not defined __lshrdi3 in ntfs is not defined __ashldi3 in ntfscomp is not defined __lshrdi3 in ntfscomp is not defined __ashldi3 in part_gpt is not defined __ashldi3 in part_msdos is not defined __ashldi3 in sfs is not defined __ashldi3 in shift_test is not defined __ashrdi3 in shift_test is not defined __lshrdi3 in shift_test is not defined __lshrdi3 in squash4 is not defined __ashldi3 in udf is not defined __lshrdi3 in udf is not defined __ashldi3 in ufs1 is not defined __lshrdi3 in ufs1 is not defined __ashldi3 in ufs1_be is not defined __lshrdi3 in ufs1_be is not defined __ashldi3 in ufs2 is not defined __lshrdi3 in ufs2 is not defined __ashldi3 in xfs is not defined __ashrdi3 in xfs is not defined __lshrdi3 in xfs is not defined __ashldi3 in xzio is not defined __lshrdi3 in xzio is not defined __ashldi3 in zfs is not defined __lshrdi3 in zfs is not defined __lshrdi3 in zfscrypt is not defined __ashldi3 in zstd is not defined Makefile:47234: recipe for target 'moddep.lst' failed If I switched to kernel.org riscv32 toolchain, the problem went away. https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/7.3.0/x86_64-gcc-7.3.0-nolibc_riscv32-linux.tar.xz $ ./configure --target=riscv32 --with-platform=efi CC=gcc TARGET_CC=/share/toolchains/gcc-7.3.0-nolibc/riscv32-linux/bin/riscv32-linux-gcc TARGET_OBJCOPY=/share/toolchains/gcc-7.3.0-nolibc/riscv32-linux/bin/riscv32-linux-objcopy TARGET_STRIP=/share/toolchains/gcc-7.3.0-nolibc/riscv32-linux/bin/riscv32-linux-strip TARGET_NM=/share/toolchains/gcc-7.3.0-nolibc/riscv32-linux/bin/riscv32-linux-nm TARGET_RANLIB=/share/toolchains/gcc-7.3.0-nolibc/riscv32-linux/bin/riscv32-linux-ranlib;make Regards, Bin ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
