[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Minios-devel] [PATCH 1/2] Makefile.uk: Fix link issues on arm64
Hi Costin > -----Original Message----- > From: Costin Lupu <costin.lupu@xxxxxxxxx> > Sent: Thursday, December 19, 2019 7:09 PM > To: Justin He <Justin.He@xxxxxxx>; minios-devel@xxxxxxxxxxxxxxxxxxxx; > Simon Kuenzer <simon.kuenzer@xxxxxxxxx>; Santiago.Pagani@xxxxxxxxx > Cc: Felipe Huici <felipe.huici@xxxxxxxxx>; Kaly Xin <Kaly.Xin@xxxxxxx>; > Julien Grall <Julien.Grall@xxxxxxx>; Sharan.Santhanam@xxxxxxxxx > Subject: Re: [Minios-devel] [PATCH 1/2] Makefile.uk: Fix link issues on arm64 > > Hi Justin, > > Please see inline. > > On 12/19/19 11:23 AM, Jia He wrote: > > Without this patch, when starting helloworld app with newlib on arm > > kvm plat, it will report a link error as follows: > > iapps/helloworld.newlib/build/helloworld_kvm-arm64.o: In function > `wcstold_l': > > apps/helloworld.newlib/build/libnewlibc/origin/newlib- > 2.5.0.20170922/newlib/libc/stdlib/wcstold.c:77: undefined reference to > `strtold_l' > > apps/helloworld.newlib/build/libnewlibc/origin/newlib- > 2.5.0.20170922/newlib/libc/stdlib/wcstold.c:77:(.text+0x7c4e4): relocation > truncated to fit: R_AARCH64_CALL26 against undefined symbol `strtold_l' > > > > I once did configure and build of newlib from uptream, this macro is > > defined on my Thunderx2 armv8a server (Unbuntu 18.04 + gcc version 7.4.0) > > > > Signed-off-by: Jia He <justin.he@xxxxxxx> > > --- > > Makefile.uk | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/Makefile.uk b/Makefile.uk > > index 17d8d7a..54efe1a 100644 > > --- a/Makefile.uk > > +++ b/Makefile.uk > > @@ -85,9 +85,9 @@ LIBNEWLIB_GLOBAL_FLAGS-y += - > DMISSING_SYSCALL_NAMES -DMALLOC_PROVIDED > > LIBNEWLIB_GLOBAL_FLAGS-y += -D_POSIX_REALTIME_SIGNALS > > LIBNEWLIB_GLOBAL_FLAGS- > $(CONFIG_LIBNEWLIBC_WANT_IO_C99_FORMATS) += - > D_WANT_IO_C99_FORMATS > > LIBNEWLIB_GLOBAL_FLAGS- > $(CONFIG_LIBNEWLIBC_LINUX_ERRNO_EXTENSIONS) += - > D__LINUX_ERRNO_EXTENSIONS__ > > +LIBNEWLIB_GLOBAL_FLAGS-y += -D_HAVE_LONG_DOUBLE > > I don't think it's safe to define this for all architectures. Besides How about adding ifdef (X86 || ARM64) ? > that, when I introduced this flag I didn't check whether this is > actually true, i.e. whether sizeof(double) and sizeof(long double) are > the same. And they are not, sizeof(double) == 8 while sizeof(long > double) == 16. Therefore we have to force the compiler to make them > equal in size using `-mlong-double-64` (this means updating global > CFLAGS and CXXFLAGS). On my ThundX2 (armv8a) host, sizeof(double) == 8 while sizeof(long double) == 16. And `-mlong-double-64` is not recognized on arm64 ([1], X86 only) Besides, I try the configure test .c code: #include <float.h> #if defined(LDBL_MANT_DIG) #define _HAVE_LONG_DOUBLE #else #error "LDBL != DBL" #endif long double test() { long double ld = 0.0L; return ld; } The error "LDBL != DBL" is NOT prompted. Hence _HAVE_LONG_DOUBLE is defined. [1] https://gcc.gnu.org/onlinedocs/gcc/Option-Index.html > > Now, my question to you is: do these 2 types have the same size? Even if > they have, you should set this flag only for your architecture. If not, Seems I should add the ifdef (ARM64)... -- Cheers, Justin (Jia He) > can you force the compiler to make the equal in size? > > > ifeq ($(CONFIG_ARCH_X86_64),y) > > LIBNEWLIB_GLOBAL_FLAGS-y += -D_LDBL_EQ_DBL > > -LIBNEWLIB_GLOBAL_FLAGS-y += -D_HAVE_LONG_DOUBLE > > endif > > > > CFLAGS-y += $(LIBNEWLIB_GLOBAL_FLAGS-y) > > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ Minios-devel mailing list Minios-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/minios-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |