Re: [uml-user] [PATCH v2] um: Avoid longjmp/setjmp symbol clashes with libpthread.a
Florian, Am 29.06.2017 um 00:40 schrieb Florian Fainelli: >> Hehe, yes. >> This patch is good, I like it. :) >> It will part of the next pull request. > > Humm okay, did you apply the patch in one of your kernel trees on > git.kernel.org or somewhere else? Will happen soon since the merge window is near where I will post a pull request... Thanks, //richard -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ User-mode-linux-user mailing list User-mode-linux-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
Re: [uml-user] [PATCH v2] um: Avoid longjmp/setjmp symbol clashes with libpthread.a
On 06/05/2017 12:34 PM, Richard Weinberger wrote:
> Florian,
>
> Am 05.06.2017 um 21:32 schrieb Florian Fainelli:
>> On 05/23/2017 05:32 PM, Florian Fainelli wrote:
>>> Building a statically linked UML kernel on a Centos 6.9 host resulted in
>>> the following linking failure (GCC 4.4, glibc-2.12):
>>>
>>> /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/libpthread.a(libpthread.o):
>>> In function `siglongjmp':
>>> (.text+0x8490): multiple definition of `longjmp'
>>> arch/x86/um/built-in.o:/local/users/fainelli/openwrt/trunk/build_dir/target-x86_64_musl/linux-uml/linux-4.4.69/arch/x86/um/setjmp_64.S:44:
>>> first defined here
>>> /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/libpthread.a(libpthread.o):
>>> In function `sem_open':
>>> (.text+0x77cd): warning: the use of `mktemp' is dangerous, better use
>>> `mkstemp'
>>> collect2: ld returned 1 exit status
>>> make[4]: *** [vmlinux] Error 1
>>>
>>> Adopt a solution similar to the one done for vmap where we define
>>> longjmp/setjmp to be kernel_longjmp/setjmp. In the process, make sure we
>>> do rename the functions in arch/x86/um/setjmp_*.S accordingly.
>>>
>>> Fixes: a7df4716d195 ("um: link with -lpthread")
>>> Signed-off-by: Florian Fainelli
>>
>> Richard, we are kind of hijacking this thread now that was originally
>> about statically linking UML, is this particular patch okay?
>
> Hehe, yes.
> This patch is good, I like it. :)
> It will part of the next pull request.
Humm okay, did you apply the patch in one of your kernel trees on
git.kernel.org or somewhere else?
--
Florian
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
User-mode-linux-user mailing list
User-mode-linux-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
Re: [uml-user] [PATCH v2] um: Avoid longjmp/setjmp symbol clashes with libpthread.a
Florian,
Am 05.06.2017 um 21:32 schrieb Florian Fainelli:
> On 05/23/2017 05:32 PM, Florian Fainelli wrote:
>> Building a statically linked UML kernel on a Centos 6.9 host resulted in
>> the following linking failure (GCC 4.4, glibc-2.12):
>>
>> /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/libpthread.a(libpthread.o):
>> In function `siglongjmp':
>> (.text+0x8490): multiple definition of `longjmp'
>> arch/x86/um/built-in.o:/local/users/fainelli/openwrt/trunk/build_dir/target-x86_64_musl/linux-uml/linux-4.4.69/arch/x86/um/setjmp_64.S:44:
>> first defined here
>> /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/libpthread.a(libpthread.o):
>> In function `sem_open':
>> (.text+0x77cd): warning: the use of `mktemp' is dangerous, better use
>> `mkstemp'
>> collect2: ld returned 1 exit status
>> make[4]: *** [vmlinux] Error 1
>>
>> Adopt a solution similar to the one done for vmap where we define
>> longjmp/setjmp to be kernel_longjmp/setjmp. In the process, make sure we
>> do rename the functions in arch/x86/um/setjmp_*.S accordingly.
>>
>> Fixes: a7df4716d195 ("um: link with -lpthread")
>> Signed-off-by: Florian Fainelli
>
> Richard, we are kind of hijacking this thread now that was originally
> about statically linking UML, is this particular patch okay?
Hehe, yes.
This patch is good, I like it. :)
It will part of the next pull request.
Thanks,
//richard
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
User-mode-linux-user mailing list
User-mode-linux-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
Re: [uml-user] [PATCH v2] um: Avoid longjmp/setjmp symbol clashes with libpthread.a
On 05/23/2017 05:32 PM, Florian Fainelli wrote:
> Building a statically linked UML kernel on a Centos 6.9 host resulted in
> the following linking failure (GCC 4.4, glibc-2.12):
>
> /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/libpthread.a(libpthread.o):
> In function `siglongjmp':
> (.text+0x8490): multiple definition of `longjmp'
> arch/x86/um/built-in.o:/local/users/fainelli/openwrt/trunk/build_dir/target-x86_64_musl/linux-uml/linux-4.4.69/arch/x86/um/setjmp_64.S:44:
> first defined here
> /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/libpthread.a(libpthread.o):
> In function `sem_open':
> (.text+0x77cd): warning: the use of `mktemp' is dangerous, better use
> `mkstemp'
> collect2: ld returned 1 exit status
> make[4]: *** [vmlinux] Error 1
>
> Adopt a solution similar to the one done for vmap where we define
> longjmp/setjmp to be kernel_longjmp/setjmp. In the process, make sure we
> do rename the functions in arch/x86/um/setjmp_*.S accordingly.
>
> Fixes: a7df4716d195 ("um: link with -lpthread")
> Signed-off-by: Florian Fainelli
Richard, we are kind of hijacking this thread now that was originally
about statically linking UML, is this particular patch okay?
> ---
> Changes in v2:
> - fix typo introduced on longjmp
>
> arch/um/Makefile| 4
> arch/x86/um/setjmp_32.S | 16
> arch/x86/um/setjmp_64.S | 16
> 3 files changed, 20 insertions(+), 16 deletions(-)
>
> diff --git a/arch/um/Makefile b/arch/um/Makefile
> index 0ca46ededfc7..6ca4f66085c1 100644
> --- a/arch/um/Makefile
> +++ b/arch/um/Makefile
> @@ -59,10 +59,14 @@ KBUILD_CPPFLAGS += -I$(srctree)/$(HOST_DIR)/um
> # Same things for in6addr_loopback and mktime - found in libc. For these two
> we
> # only get link-time error, luckily.
> #
> +# -Dlongjmp=kernel_longjmp prevents anything from referencing the
> libpthread.a
> +# embedded copy of longjmp, same thing for setjmp.
> +#
> # These apply to USER_CFLAGS to.
>
> KBUILD_CFLAGS += $(CFLAGS) $(CFLAGS-y) -D__arch_um__ \
> $(ARCH_INCLUDE) $(MODE_INCLUDE) -Dvmap=kernel_vmap \
> + -Dlongjmp=kernel_longjmp -Dsetjmp=kernel_setjmp \
> -Din6addr_loopback=kernel_in6addr_loopback \
> -Din6addr_any=kernel_in6addr_any -Dstrrchr=kernel_strrchr
>
> diff --git a/arch/x86/um/setjmp_32.S b/arch/x86/um/setjmp_32.S
> index b766792c9933..39053192918d 100644
> --- a/arch/x86/um/setjmp_32.S
> +++ b/arch/x86/um/setjmp_32.S
> @@ -16,9 +16,9 @@
>
> .text
> .align 4
> - .globl setjmp
> - .type setjmp, @function
> -setjmp:
> + .globl kernel_setjmp
> + .type kernel_setjmp, @function
> +kernel_setjmp:
> #ifdef _REGPARM
> movl %eax,%edx
> #else
> @@ -35,13 +35,13 @@ setjmp:
> movl %ecx,20(%edx) # Return address
> ret
>
> - .size setjmp,.-setjmp
> + .size kernel_setjmp,.-kernel_setjmp
>
> .text
> .align 4
> - .globl longjmp
> - .type longjmp, @function
> -longjmp:
> + .globl kernel_longjmp
> + .type kernel_longjmp, @function
> +kernel_longjmp:
> #ifdef _REGPARM
> xchgl %eax,%edx
> #else
> @@ -55,4 +55,4 @@ longjmp:
> movl 16(%edx),%edi
> jmp *20(%edx)
>
> - .size longjmp,.-longjmp
> + .size kernel_longjmp,.-kernel_longjmp
> diff --git a/arch/x86/um/setjmp_64.S b/arch/x86/um/setjmp_64.S
> index 45f547b4043e..c56942e1a38c 100644
> --- a/arch/x86/um/setjmp_64.S
> +++ b/arch/x86/um/setjmp_64.S
> @@ -18,9 +18,9 @@
>
> .text
> .align 4
> - .globl setjmp
> - .type setjmp, @function
> -setjmp:
> + .globl kernel_setjmp
> + .type kernel_setjmp, @function
> +kernel_setjmp:
> pop %rsi # Return address, and adjust the stack
> xorl %eax,%eax # Return value
> movq %rbx,(%rdi)
> @@ -34,13 +34,13 @@ setjmp:
> movq %rsi,56(%rdi) # Return address
> ret
>
> - .size setjmp,.-setjmp
> + .size kernel_setjmp,.-kernel_setjmp
>
> .text
> .align 4
> - .globl longjmp
> - .type longjmp, @function
> -longjmp:
> + .globl kernel_longjmp
> + .type kernel_longjmp, @function
> +kernel_longjmp:
> movl %esi,%eax # Return value (int)
> movq (%rdi),%rbx
> movq 8(%rdi),%rsp
> @@ -51,4 +51,4 @@ longjmp:
> movq 48(%rdi),%r15
> jmp *56(%rdi)
>
> - .size longjmp,.-longjmp
> + .size kernel_longjmp,.-kernel_longjmp
>
--
Florian
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
User-mode-linux-user mailing list
User-mode-linux-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
Re: [uml-user] [PATCH v2] um: Avoid longjmp/setjmp symbol clashes with libpthread.a
Am 01.06.2017 um 22:15 schrieb Florian Fainelli: > On 06/01/2017 01:11 PM, Richard Weinberger wrote: >> Florian, >> >> Am 01.06.2017 um 21:38 schrieb Florian Fainelli: Presumably because we are not using the same glibc version? The one I have installed on this machine is glibc-2.12, do you want me to attach a copy of it? >>> >>> Richard, what do we do with this? >> >> I'd like to see the issues that Thomas sees also get addressed. > > Sure, but that seems orthogonal? In the absence of an answer from Eli, > either you could take my patch or just send reverts of Eli's two > commits, whichever you prefer. Or you and Thomas could investigate. :-) Thanks, //richard -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ User-mode-linux-user mailing list User-mode-linux-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
Re: [uml-user] [PATCH v2] um: Avoid longjmp/setjmp symbol clashes with libpthread.a
On 06/01/2017 01:11 PM, Richard Weinberger wrote: > Florian, > > Am 01.06.2017 um 21:38 schrieb Florian Fainelli: >>> Presumably because we are not using the same glibc version? The one I >>> have installed on this machine is glibc-2.12, do you want me to attach a >>> copy of it? >> >> Richard, what do we do with this? > > I'd like to see the issues that Thomas sees also get addressed. Sure, but that seems orthogonal? In the absence of an answer from Eli, either you could take my patch or just send reverts of Eli's two commits, whichever you prefer. -- Florian -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ User-mode-linux-user mailing list User-mode-linux-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
Re: [uml-user] [PATCH v2] um: Avoid longjmp/setjmp symbol clashes with libpthread.a
Florian, Am 01.06.2017 um 21:38 schrieb Florian Fainelli: >> Presumably because we are not using the same glibc version? The one I >> have installed on this machine is glibc-2.12, do you want me to attach a >> copy of it? > > Richard, what do we do with this? I'd like to see the issues that Thomas sees also get addressed. Thanks, //richard -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ User-mode-linux-user mailing list User-mode-linux-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
Re: [uml-user] [PATCH v2] um: Avoid longjmp/setjmp symbol clashes with libpthread.a
On 05/24/2017 09:19 AM, Florian Fainelli wrote: > On 05/24/2017 12:02 AM, Richard Weinberger wrote: >> Florian, >> >> Am 24.05.2017 um 02:32 schrieb Florian Fainelli: >>> Building a statically linked UML kernel on a Centos 6.9 host resulted in >>> the following linking failure (GCC 4.4, glibc-2.12): >>> >>> /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/libpthread.a(libpthread.o): >>> In function `siglongjmp': >>> (.text+0x8490): multiple definition of `longjmp' >>> arch/x86/um/built-in.o:/local/users/fainelli/openwrt/trunk/build_dir/target-x86_64_musl/linux-uml/linux-4.4.69/arch/x86/um/setjmp_64.S:44: >>> first defined here >>> /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/libpthread.a(libpthread.o): >>> In function `sem_open': >>> (.text+0x77cd): warning: the use of `mktemp' is dangerous, better use >>> `mkstemp' >>> collect2: ld returned 1 exit status >>> make[4]: *** [vmlinux] Error 1 >>> >>> Adopt a solution similar to the one done for vmap where we define >>> longjmp/setjmp to be kernel_longjmp/setjmp. In the process, make sure we >>> do rename the functions in arch/x86/um/setjmp_*.S accordingly. >> >> What is not so clear to me, why are you facing this build issue and other >> users, including me, >> not? > > Presumably because we are not using the same glibc version? The one I > have installed on this machine is glibc-2.12, do you want me to attach a > copy of it? Richard, what do we do with this? -- Florian -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ User-mode-linux-user mailing list User-mode-linux-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
Re: [uml-user] [PATCH v2] um: Avoid longjmp/setjmp symbol clashes with libpthread.a
On 05/24/2017 12:02 AM, Richard Weinberger wrote: > Florian, > > Am 24.05.2017 um 02:32 schrieb Florian Fainelli: >> Building a statically linked UML kernel on a Centos 6.9 host resulted in >> the following linking failure (GCC 4.4, glibc-2.12): >> >> /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/libpthread.a(libpthread.o): >> In function `siglongjmp': >> (.text+0x8490): multiple definition of `longjmp' >> arch/x86/um/built-in.o:/local/users/fainelli/openwrt/trunk/build_dir/target-x86_64_musl/linux-uml/linux-4.4.69/arch/x86/um/setjmp_64.S:44: >> first defined here >> /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/libpthread.a(libpthread.o): >> In function `sem_open': >> (.text+0x77cd): warning: the use of `mktemp' is dangerous, better use >> `mkstemp' >> collect2: ld returned 1 exit status >> make[4]: *** [vmlinux] Error 1 >> >> Adopt a solution similar to the one done for vmap where we define >> longjmp/setjmp to be kernel_longjmp/setjmp. In the process, make sure we >> do rename the functions in arch/x86/um/setjmp_*.S accordingly. > > What is not so clear to me, why are you facing this build issue and other > users, including me, > not? Presumably because we are not using the same glibc version? The one I have installed on this machine is glibc-2.12, do you want me to attach a copy of it? -- Florian -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ User-mode-linux-user mailing list User-mode-linux-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
Re: [uml-user] [PATCH v2] um: Avoid longjmp/setjmp symbol clashes with libpthread.a
Florian, Am 24.05.2017 um 02:32 schrieb Florian Fainelli: > Building a statically linked UML kernel on a Centos 6.9 host resulted in > the following linking failure (GCC 4.4, glibc-2.12): > > /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/libpthread.a(libpthread.o): > In function `siglongjmp': > (.text+0x8490): multiple definition of `longjmp' > arch/x86/um/built-in.o:/local/users/fainelli/openwrt/trunk/build_dir/target-x86_64_musl/linux-uml/linux-4.4.69/arch/x86/um/setjmp_64.S:44: > first defined here > /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/libpthread.a(libpthread.o): > In function `sem_open': > (.text+0x77cd): warning: the use of `mktemp' is dangerous, better use > `mkstemp' > collect2: ld returned 1 exit status > make[4]: *** [vmlinux] Error 1 > > Adopt a solution similar to the one done for vmap where we define > longjmp/setjmp to be kernel_longjmp/setjmp. In the process, make sure we > do rename the functions in arch/x86/um/setjmp_*.S accordingly. What is not so clear to me, why are you facing this build issue and other users, including me, not? Thanks, //richard -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ User-mode-linux-user mailing list User-mode-linux-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
