[uml-devel] link error on recent kernels with CONFIG_STATIC_LINK=y

[uml-devel] link error on recent kernels with CONFIG_STATIC_LINK=y

[Stefan Traby]

hi!

I get
`.text.exit' referenced in section `.fini_array' of
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libc.a(sdlerror.o):
defined in discarded section `.text.exit' of
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libc.a(sdlerror.o)

on statically linking uml (dynamic linking works).
I use debian unstable.


running ../bisect.sh
Bisecting: 6495 revisions left to test after this (roughly 13 steps)
[c3486f5376696034d0fcbef8ba70c70cfcb26f51] mm, compaction: simplify contended compaction handling
running ../bisect.sh
Bisecting: 3075 revisions left to test after this (roughly 12 steps)
[9c1958fc326a0a0a533ec8e86ea6fa30977207de] Merge tag 'media/v4.8-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
running ../bisect.sh
Bisecting: 1688 revisions left to test after this (roughly 11 steps)
[7e4dc77b2869a683fc43c0394fca5441816390ba] Merge branch 'perf-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
running ../bisect.sh
Bisecting: 749 revisions left to test after this (roughly 10 steps)
[25a0dc4be86fc0d8c7e81bb5f8be8427022bf15f] Merge tag 'staging-4.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
running ../bisect.sh
Bisecting: 480 revisions left to test after this (roughly 9 steps)
[b403f230448ed687edcc460cd46de652bc686b12] Merge tag 'gfs2-4.7.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2
running ../bisect.sh
Bisecting: 237 revisions left to test after this (roughly 8 steps)
[33f4751e99601b7bfd1d66aedabd3ee9140922de] mm: thp: move pmd check inside ptl for freeze_page()
running ../bisect.sh
Bisecting: 118 revisions left to test after this (roughly 7 steps)
[4c2a8499a450b6582eb5637a8f0d472168355ddd] Merge tag 'configfs-for-4.7' of git://git.infradead.org/users/hch/configfs
running ../bisect.sh
Bisecting: 60 revisions left to test after this (roughly 6 steps)
[cfae7e3eb1334ff8035bb66f307f3d4010e65646] Merge tag 'for-linus-4.7b-rc6-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip
running ../bisect.sh
Bisecting: 30 revisions left to test after this (roughly 5 steps)
[f1b5e4fac164ff43b189d996e4f05f95cc57b984] Merge tag 'acpi-urgent-4.7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
running ../bisect.sh
Bisecting: 15 revisions left to test after this (roughly 4 steps)
[f97d10454e4da2aceb44dfa7c59bb43ba9f50199] Merge branches 'perf-urgent-for-linus' and 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
running ../bisect.sh
Bisecting: 7 revisions left to test after this (roughly 3 steps)
[ef722fd4a7592ddbfa42bcb3ad8a5caa598589b3] Revert "scripts/gdb: add documentation example for radix tree"
running ../bisect.sh
Bisecting: 3 revisions left to test after this (roughly 2 steps)
[e4568d3803852d00effd41dcdd489e726b998879] mm, meminit: always return a valid node from early_pfn_to_nid
running ../bisect.sh
Bisecting: 1 revision left to test after this (roughly 1 step)
[d02038f972538b93011d78c068f44514fbde0a8c] gcov: add support for gcc version >= 6
running ../bisect.sh
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[e41f501d391265ff568f3e49d6128cc30856a36f] vmlinux.lds: account for destructor sections
running ../bisect.sh
e41f501d391265ff568f3e49d6128cc30856a36f is the first bad commit
commit e41f501d391265ff568f3e49d6128cc30856a36f
Author: Dmitry Vyukov <dvyukov@google.com>
Date:   Thu Jul 14 12:07:29 2016 -0700

    vmlinux.lds: account for destructor sections
    
    If CONFIG_KASAN is enabled and gcc is configured with
    --disable-initfini-array and/or gold linker is used, gcc emits
    .ctors/.dtors and .text.startup/.text.exit sections instead of
    .init_array/.fini_array.  .dtors section is not explicitly accounted in
    the linker script and messes vvar/percpu layout.
    
    We want:
      ffffffff822bfd80 D _edata
      ffffffff822c0000 D __vvar_beginning_hack
      ffffffff822c0000 A __vvar_page
      ffffffff822c0080 0000000000000098 D vsyscall_gtod_data
      ffffffff822c1000 A __init_begin
      ffffffff822c1000 D init_per_cpu__irq_stack_union
      ffffffff822c1000 A __per_cpu_load
      ffffffff822d3000 D init_per_cpu__gdt_page
    
    We got:
      ffffffff8279a600 D _edata
      ffffffff8279b000 A __vvar_page
      ffffffff8279c000 A __init_begin
      ffffffff8279c000 D init_per_cpu__irq_stack_union
      ffffffff8279c000 A __per_cpu_load
      ffffffff8279e000 D __vvar_beginning_hack
      ffffffff8279e080 0000000000000098 D vsyscall_gtod_data
      ffffffff827ae000 D init_per_cpu__gdt_page
    
    This happens because __vvar_page and .vvar get different addresses in
    arch/x86/kernel/vmlinux.lds.S:
    
    	. = ALIGN(PAGE_SIZE);
    	__vvar_page = .;
    
    	.vvar : AT(ADDR(.vvar) - LOAD_OFFSET) {
    		/* work around gold bug 13023 */
    		__vvar_beginning_hack = .;
    
    Discard .dtors/.fini_array/.text.exit, since we don't call dtors.
    Merge .text.startup into init text.
    
    Link: http://lkml.kernel.org/r/1467386363-120030-1-git-send-email-dvyukov@google.com
    Signed-off-by: Dmitry Vyukov <dvyukov@google.com>
    Reviewed-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
    Cc: <stable@vger.kernel.org>	[4.0+]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

:040000 040000 c189d7a2a48172c6adcd17cedcf55aaaef361838 4545644f4316ab845c02b31c4bb70b1399eb1a7a M	include
bisect run success

-- 

  ciao - 
    Stefan

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] link error on recent kernels with CONFIG_STATIC_LINK=y

[Richard Weinberger]

Dmitry,

We face the following issue on UML.
My ld-fu is not very strong, can you please have a look?
AFAICT it fails since UML links to libc.a and we have section clash.

On Thu, Aug 11, 2016 at 2:19 PM, Stefan Traby <stefan@hello-penguin.com> wrote:
> hi!
>
> I get
> `.text.exit' referenced in section `.fini_array' of
> /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libc.a(sdlerror.o):
> defined in discarded section `.text.exit' of
> /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libc.a(sdlerror.o)
>
> on statically linking uml (dynamic linking works).
> I use debian unstable.
>
>
> running ../bisect.sh
> Bisecting: 6495 revisions left to test after this (roughly 13 steps)
> [c3486f5376696034d0fcbef8ba70c70cfcb26f51] mm, compaction: simplify contended compaction handling
> running ../bisect.sh
> Bisecting: 3075 revisions left to test after this (roughly 12 steps)
> [9c1958fc326a0a0a533ec8e86ea6fa30977207de] Merge tag 'media/v4.8-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
> running ../bisect.sh
> Bisecting: 1688 revisions left to test after this (roughly 11 steps)
> [7e4dc77b2869a683fc43c0394fca5441816390ba] Merge branch 'perf-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
> running ../bisect.sh
> Bisecting: 749 revisions left to test after this (roughly 10 steps)
> [25a0dc4be86fc0d8c7e81bb5f8be8427022bf15f] Merge tag 'staging-4.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
> running ../bisect.sh
> Bisecting: 480 revisions left to test after this (roughly 9 steps)
> [b403f230448ed687edcc460cd46de652bc686b12] Merge tag 'gfs2-4.7.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2
> running ../bisect.sh
> Bisecting: 237 revisions left to test after this (roughly 8 steps)
> [33f4751e99601b7bfd1d66aedabd3ee9140922de] mm: thp: move pmd check inside ptl for freeze_page()
> running ../bisect.sh
> Bisecting: 118 revisions left to test after this (roughly 7 steps)
> [4c2a8499a450b6582eb5637a8f0d472168355ddd] Merge tag 'configfs-for-4.7' of git://git.infradead.org/users/hch/configfs
> running ../bisect.sh
> Bisecting: 60 revisions left to test after this (roughly 6 steps)
> [cfae7e3eb1334ff8035bb66f307f3d4010e65646] Merge tag 'for-linus-4.7b-rc6-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip
> running ../bisect.sh
> Bisecting: 30 revisions left to test after this (roughly 5 steps)
> [f1b5e4fac164ff43b189d996e4f05f95cc57b984] Merge tag 'acpi-urgent-4.7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
> running ../bisect.sh
> Bisecting: 15 revisions left to test after this (roughly 4 steps)
> [f97d10454e4da2aceb44dfa7c59bb43ba9f50199] Merge branches 'perf-urgent-for-linus' and 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
> running ../bisect.sh
> Bisecting: 7 revisions left to test after this (roughly 3 steps)
> [ef722fd4a7592ddbfa42bcb3ad8a5caa598589b3] Revert "scripts/gdb: add documentation example for radix tree"
> running ../bisect.sh
> Bisecting: 3 revisions left to test after this (roughly 2 steps)
> [e4568d3803852d00effd41dcdd489e726b998879] mm, meminit: always return a valid node from early_pfn_to_nid
> running ../bisect.sh
> Bisecting: 1 revision left to test after this (roughly 1 step)
> [d02038f972538b93011d78c068f44514fbde0a8c] gcov: add support for gcc version >= 6
> running ../bisect.sh
> Bisecting: 0 revisions left to test after this (roughly 0 steps)
> [e41f501d391265ff568f3e49d6128cc30856a36f] vmlinux.lds: account for destructor sections
> running ../bisect.sh
> e41f501d391265ff568f3e49d6128cc30856a36f is the first bad commit
> commit e41f501d391265ff568f3e49d6128cc30856a36f
> Author: Dmitry Vyukov <dvyukov@google.com>
> Date:   Thu Jul 14 12:07:29 2016 -0700
>
>     vmlinux.lds: account for destructor sections
>
>     If CONFIG_KASAN is enabled and gcc is configured with
>     --disable-initfini-array and/or gold linker is used, gcc emits
>     .ctors/.dtors and .text.startup/.text.exit sections instead of
>     .init_array/.fini_array.  .dtors section is not explicitly accounted in
>     the linker script and messes vvar/percpu layout.
>
>     We want:
>       ffffffff822bfd80 D _edata
>       ffffffff822c0000 D __vvar_beginning_hack
>       ffffffff822c0000 A __vvar_page
>       ffffffff822c0080 0000000000000098 D vsyscall_gtod_data
>       ffffffff822c1000 A __init_begin
>       ffffffff822c1000 D init_per_cpu__irq_stack_union
>       ffffffff822c1000 A __per_cpu_load
>       ffffffff822d3000 D init_per_cpu__gdt_page
>
>     We got:
>       ffffffff8279a600 D _edata
>       ffffffff8279b000 A __vvar_page
>       ffffffff8279c000 A __init_begin
>       ffffffff8279c000 D init_per_cpu__irq_stack_union
>       ffffffff8279c000 A __per_cpu_load
>       ffffffff8279e000 D __vvar_beginning_hack
>       ffffffff8279e080 0000000000000098 D vsyscall_gtod_data
>       ffffffff827ae000 D init_per_cpu__gdt_page
>
>     This happens because __vvar_page and .vvar get different addresses in
>     arch/x86/kernel/vmlinux.lds.S:
>
>         . = ALIGN(PAGE_SIZE);
>         __vvar_page = .;
>
>         .vvar : AT(ADDR(.vvar) - LOAD_OFFSET) {
>                 /* work around gold bug 13023 */
>                 __vvar_beginning_hack = .;
>
>     Discard .dtors/.fini_array/.text.exit, since we don't call dtors.
>     Merge .text.startup into init text.
>
>     Link: http://lkml.kernel.org/r/1467386363-120030-1-git-send-email-dvyukov@google.com
>     Signed-off-by: Dmitry Vyukov <dvyukov@google.com>
>     Reviewed-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
>     Cc: <stable@vger.kernel.org>        [4.0+]
>     Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>     Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>
> :040000 040000 c189d7a2a48172c6adcd17cedcf55aaaef361838 4545644f4316ab845c02b31c4bb70b1399eb1a7a M      include
> bisect run success
>
> --
>
>   ciao -
>     Stefan
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. http://sdm.link/zohodev2dev
> _______________________________________________
> User-mode-linux-devel mailing list
> User-mode-linux-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel



-- 
Thanks,
//richard

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[PATCH] UML: don't discard .text.exit section

[Andrey Ryabinin]

Commit e41f501d3912 ("vmlinux.lds: account for destructor sections")
added '.text.exit' to EXIT_TEXT which is discarded at link time by default.
This breaks compilation of UML:
     `.text.exit' referenced in section `.fini_array' of
     /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libc.a(sdlerror.o):
     defined in discarded section `.text.exit' of
     /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libc.a(sdlerror.o)

Apparently UML doesn't want to discard exit text, so let's place all EXIT_TEXT
sections in .exit.text.

Fixes: e41f501d3912 ("vmlinux.lds: account for destructor sections")
Reported-by: Stefan Traby <stefan@hello-penguin.com>
Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: <stable@vger.kernel.org> # 4.0+
---
 arch/um/include/asm/common.lds.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/um/include/asm/common.lds.S b/arch/um/include/asm/common.lds.S
index 1dd5bd8..1330553 100644
--- a/arch/um/include/asm/common.lds.S
+++ b/arch/um/include/asm/common.lds.S
@@ -81,7 +81,7 @@
   .altinstr_replacement : { *(.altinstr_replacement) }
   /* .exit.text is discard at runtime, not link time, to deal with references
      from .altinstructions and .eh_frame */
-  .exit.text : { *(.exit.text) }
+  .exit.text : { EXIT_TEXT }
   .exit.data : { *(.exit.data) }
 
   .preinit_array : {
-- 
2.7.3

[PATCH] UML: don't discard .text.exit section

[Andrey Ryabinin]

Commit e41f501d3912 ("vmlinux.lds: account for destructor sections")
added '.text.exit' to EXIT_TEXT which is discarded at link time by default.
This breaks compilation of UML:
     `.text.exit' referenced in section `.fini_array' of
     /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libc.a(sdlerror.o):
     defined in discarded section `.text.exit' of
     /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libc.a(sdlerror.o)

Apparently UML doesn't want to discard exit text, so let's place all EXIT_TEXT
sections in .exit.text.

Fixes: e41f501d3912 ("vmlinux.lds: account for destructor sections")
Reported-by: Stefan Traby <stefan@hello-penguin.com>
Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: <stable@vger.kernel.org> # 4.0+
---
 arch/um/include/asm/common.lds.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/um/include/asm/common.lds.S b/arch/um/include/asm/common.lds.S
index 1dd5bd8..1330553 100644
--- a/arch/um/include/asm/common.lds.S
+++ b/arch/um/include/asm/common.lds.S
@@ -81,7 +81,7 @@
   .altinstr_replacement : { *(.altinstr_replacement) }
   /* .exit.text is discard at runtime, not link time, to deal with references
      from .altinstructions and .eh_frame */
-  .exit.text : { *(.exit.text) }
+  .exit.text : { EXIT_TEXT }
   .exit.data : { *(.exit.data) }
 
   .preinit_array : {
-- 
2.7.3

Re: [PATCH] UML: don't discard .text.exit section

[Dmitry Vyukov]

On Wed, Aug 17, 2016 at 8:10 AM, Andrey Ryabinin
<aryabinin@virtuozzo.com> wrote:
> Commit e41f501d3912 ("vmlinux.lds: account for destructor sections")
> added '.text.exit' to EXIT_TEXT which is discarded at link time by default.
> This breaks compilation of UML:
>      `.text.exit' referenced in section `.fini_array' of
>      /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libc.a(sdlerror.o):
>      defined in discarded section `.text.exit' of
>      /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libc.a(sdlerror.o)
>
> Apparently UML doesn't want to discard exit text, so let's place all EXIT_TEXT
> sections in .exit.text.
>
> Fixes: e41f501d3912 ("vmlinux.lds: account for destructor sections")
> Reported-by: Stefan Traby <stefan@hello-penguin.com>
> Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
> Cc: <stable@vger.kernel.org> # 4.0+
> ---
>  arch/um/include/asm/common.lds.S | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/um/include/asm/common.lds.S b/arch/um/include/asm/common.lds.S
> index 1dd5bd8..1330553 100644
> --- a/arch/um/include/asm/common.lds.S
> +++ b/arch/um/include/asm/common.lds.S
> @@ -81,7 +81,7 @@
>    .altinstr_replacement : { *(.altinstr_replacement) }
>    /* .exit.text is discard at runtime, not link time, to deal with references
>       from .altinstructions and .eh_frame */
> -  .exit.text : { *(.exit.text) }
> +  .exit.text : { EXIT_TEXT }
>    .exit.data : { *(.exit.data) }
>
>    .preinit_array : {
> --
> 2.7.3
>


Sorry for delays, I am travelling.
Do we need ".fini_array" section? It's also destructors that we don't
run. Or does UML use them? Does discarding ".fini_array" help?

Re: [PATCH] UML: don't discard .text.exit section

[Andrey Ryabinin]

On 08/17/2016 08:11 PM, Dmitry Vyukov wrote:
> On Wed, Aug 17, 2016 at 8:10 AM, Andrey Ryabinin
> <aryabinin@virtuozzo.com> wrote:
>> Commit e41f501d3912 ("vmlinux.lds: account for destructor sections")
>> added '.text.exit' to EXIT_TEXT which is discarded at link time by default.
>> This breaks compilation of UML:
>>      `.text.exit' referenced in section `.fini_array' of
>>      /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libc.a(sdlerror.o):
>>      defined in discarded section `.text.exit' of
>>      /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libc.a(sdlerror.o)
>>
>> Apparently UML doesn't want to discard exit text, so let's place all EXIT_TEXT
>> sections in .exit.text.
>>
>> Fixes: e41f501d3912 ("vmlinux.lds: account for destructor sections")
>> Reported-by: Stefan Traby <stefan@hello-penguin.com>
>> Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
>> Cc: <stable@vger.kernel.org> # 4.0+
>> ---
>>  arch/um/include/asm/common.lds.S | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/um/include/asm/common.lds.S b/arch/um/include/asm/common.lds.S
>> index 1dd5bd8..1330553 100644
>> --- a/arch/um/include/asm/common.lds.S
>> +++ b/arch/um/include/asm/common.lds.S
>> @@ -81,7 +81,7 @@
>>    .altinstr_replacement : { *(.altinstr_replacement) }
>>    /* .exit.text is discard at runtime, not link time, to deal with references
>>       from .altinstructions and .eh_frame */
>> -  .exit.text : { *(.exit.text) }
>> +  .exit.text : { EXIT_TEXT }
>>    .exit.data : { *(.exit.data) }
>>
>>    .preinit_array : {
>> --
>> 2.7.3
>>
> 
> 
> Sorry for delays, I am travelling.
> Do we need ".fini_array" section? It's also destructors that we don't
> run. Or does UML use them? Does discarding ".fini_array" help?
> 

libc has desctructors and use them for whatever purpose it needs.

Re: [PATCH] UML: don't discard .text.exit section

[Dmitry Vyukov]

On Thu, Aug 18, 2016 at 3:08 AM, Andrey Ryabinin
<aryabinin@virtuozzo.com> wrote:
>
>
> On 08/17/2016 08:11 PM, Dmitry Vyukov wrote:
>> On Wed, Aug 17, 2016 at 8:10 AM, Andrey Ryabinin
>> <aryabinin@virtuozzo.com> wrote:
>>> Commit e41f501d3912 ("vmlinux.lds: account for destructor sections")
>>> added '.text.exit' to EXIT_TEXT which is discarded at link time by default.
>>> This breaks compilation of UML:
>>>      `.text.exit' referenced in section `.fini_array' of
>>>      /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libc.a(sdlerror.o):
>>>      defined in discarded section `.text.exit' of
>>>      /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libc.a(sdlerror.o)
>>>
>>> Apparently UML doesn't want to discard exit text, so let's place all EXIT_TEXT
>>> sections in .exit.text.
>>>
>>> Fixes: e41f501d3912 ("vmlinux.lds: account for destructor sections")
>>> Reported-by: Stefan Traby <stefan@hello-penguin.com>
>>> Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
>>> Cc: <stable@vger.kernel.org> # 4.0+
>>> ---
>>>  arch/um/include/asm/common.lds.S | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/um/include/asm/common.lds.S b/arch/um/include/asm/common.lds.S
>>> index 1dd5bd8..1330553 100644
>>> --- a/arch/um/include/asm/common.lds.S
>>> +++ b/arch/um/include/asm/common.lds.S
>>> @@ -81,7 +81,7 @@
>>>    .altinstr_replacement : { *(.altinstr_replacement) }
>>>    /* .exit.text is discard at runtime, not link time, to deal with references
>>>       from .altinstructions and .eh_frame */
>>> -  .exit.text : { *(.exit.text) }
>>> +  .exit.text : { EXIT_TEXT }
>>>    .exit.data : { *(.exit.data) }
>>>
>>>    .preinit_array : {
>>> --
>>> 2.7.3
>>>
>>
>>
>> Sorry for delays, I am travelling.
>> Do we need ".fini_array" section? It's also destructors that we don't
>> run. Or does UML use them? Does discarding ".fini_array" help?
>>
>
> libc has desctructors and use them for whatever purpose it needs.


Does UML actually gracefully exit running global destructors? That
would also require gracefully shutting down all threads/cpus. Doesn't
it just _exit (or syscall(SYS_exit_group))?

Re: [PATCH] UML: don't discard .text.exit section

[Andrey Ryabinin]

On 08/19/2016 03:14 AM, Dmitry Vyukov wrote:
> On Thu, Aug 18, 2016 at 3:08 AM, Andrey Ryabinin
> <aryabinin@virtuozzo.com> wrote:
>>
>>>
>>> Sorry for delays, I am travelling.
>>> Do we need ".fini_array" section? It's also destructors that we don't
>>> run. Or does UML use them? Does discarding ".fini_array" help?
>>>
>>
>> libc has desctructors and use them for whatever purpose it needs.
> 
> 
> Does UML actually gracefully exit running global destructors? That
> would also require gracefully shutting down all threads/cpus. Doesn't
> it just _exit (or syscall(SYS_exit_group))?
> 

Sigh, I dunno, I didn't look that far. My intention was to fix build and keep old behavior unaffected.
If you want to wipe destructors, and think that this is ok, go ahead.

Re: [PATCH] UML: don't discard .text.exit section

[Richard Weinberger]

On 19.08.2016 12:48, Andrey Ryabinin wrote:
> On 08/19/2016 03:14 AM, Dmitry Vyukov wrote:
>> On Thu, Aug 18, 2016 at 3:08 AM, Andrey Ryabinin
>> <aryabinin@virtuozzo.com> wrote:
>>>
>>>>
>>>> Sorry for delays, I am travelling.
>>>> Do we need ".fini_array" section? It's also destructors that we don't
>>>> run. Or does UML use them? Does discarding ".fini_array" help?
>>>>
>>>
>>> libc has desctructors and use them for whatever purpose it needs.
>>
>>
>> Does UML actually gracefully exit running global destructors? That
>> would also require gracefully shutting down all threads/cpus. Doesn't
>> it just _exit (or syscall(SYS_exit_group))?
>>
> 
> Sigh, I dunno, I didn't look that far. My intention was to fix build and keep old behavior unaffected.
> If you want to wipe destructors, and think that this is ok, go ahead.

UML exits like any regular C program does.
The main() function is in arch/um/os-Linux/main.c, when the kernel terminates,
hence linux_main() returns back to main() it just returns the exit code.
At this point libc's destructors will run, right?

Thanks,
//richard

Re: [uml-devel] [PATCH] UML: don't discard .text.exit section

[Richard Weinberger]

On 19.08.2016 12:48, Andrey Ryabinin wrote:
> On 08/19/2016 03:14 AM, Dmitry Vyukov wrote:
>> On Thu, Aug 18, 2016 at 3:08 AM, Andrey Ryabinin
>> <aryabinin@virtuozzo.com> wrote:
>>>
>>>>
>>>> Sorry for delays, I am travelling.
>>>> Do we need ".fini_array" section? It's also destructors that we don't
>>>> run. Or does UML use them? Does discarding ".fini_array" help?
>>>>
>>>
>>> libc has desctructors and use them for whatever purpose it needs.
>>
>>
>> Does UML actually gracefully exit running global destructors? That
>> would also require gracefully shutting down all threads/cpus. Doesn't
>> it just _exit (or syscall(SYS_exit_group))?
>>
> 
> Sigh, I dunno, I didn't look that far. My intention was to fix build and keep old behavior unaffected.
> If you want to wipe destructors, and think that this is ok, go ahead.

UML exits like any regular C program does.
The main() function is in arch/um/os-Linux/main.c, when the kernel terminates,
hence linux_main() returns back to main() it just returns the exit code.
At this point libc's destructors will run, right?

Thanks,
//richard

------------------------------------------------------------------------------
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [PATCH] UML: don't discard .text.exit section

[Andrey Ryabinin]

On 08/19/2016 02:16 PM, Richard Weinberger wrote:
> On 19.08.2016 12:48, Andrey Ryabinin wrote:
>> On 08/19/2016 03:14 AM, Dmitry Vyukov wrote:
>>> On Thu, Aug 18, 2016 at 3:08 AM, Andrey Ryabinin
>>> <aryabinin@virtuozzo.com> wrote:
>>>>
>>>>>
>>>>> Sorry for delays, I am travelling.
>>>>> Do we need ".fini_array" section? It's also destructors that we don't
>>>>> run. Or does UML use them? Does discarding ".fini_array" help?
>>>>>
>>>>
>>>> libc has desctructors and use them for whatever purpose it needs.
>>>
>>>
>>> Does UML actually gracefully exit running global destructors? That
>>> would also require gracefully shutting down all threads/cpus. Doesn't
>>> it just _exit (or syscall(SYS_exit_group))?
>>>
>>
>> Sigh, I dunno, I didn't look that far. My intention was to fix build and keep old behavior unaffected.
>> If you want to wipe destructors, and think that this is ok, go ahead.
> 
> UML exits like any regular C program does.
> The main() function is in arch/um/os-Linux/main.c, when the kernel terminates,
> hence linux_main() returns back to main() it just returns the exit code.
> At this point libc's destructors will run, right?
> 
Sounds right to me.

> Thanks,
> //richard
> 

Re: [PATCH] UML: don't discard .text.exit section

[Dmitry Vyukov]

On Fri, Aug 19, 2016 at 6:06 AM, Andrey Ryabinin
<aryabinin@virtuozzo.com> wrote:
>
>
> On 08/19/2016 02:16 PM, Richard Weinberger wrote:
>> On 19.08.2016 12:48, Andrey Ryabinin wrote:
>>> On 08/19/2016 03:14 AM, Dmitry Vyukov wrote:
>>>> On Thu, Aug 18, 2016 at 3:08 AM, Andrey Ryabinin
>>>> <aryabinin@virtuozzo.com> wrote:
>>>>>
>>>>>>
>>>>>> Sorry for delays, I am travelling.
>>>>>> Do we need ".fini_array" section? It's also destructors that we don't
>>>>>> run. Or does UML use them? Does discarding ".fini_array" help?
>>>>>>
>>>>>
>>>>> libc has desctructors and use them for whatever purpose it needs.
>>>>
>>>>
>>>> Does UML actually gracefully exit running global destructors? That
>>>> would also require gracefully shutting down all threads/cpus. Doesn't
>>>> it just _exit (or syscall(SYS_exit_group))?
>>>>
>>>
>>> Sigh, I dunno, I didn't look that far. My intention was to fix build and keep old behavior unaffected.
>>> If you want to wipe destructors, and think that this is ok, go ahead.
>>
>> UML exits like any regular C program does.
>> The main() function is in arch/um/os-Linux/main.c, when the kernel terminates,
>> hence linux_main() returns back to main() it just returns the exit code.
>> At this point libc's destructors will run, right?
>>
> Sounds right to me.



If it exits then

Acked-by: Dmitry Vyukov <dvyukov@google.com>

Thanks for taking care of it.

Re: [PATCH] UML: don't discard .text.exit section

[Richard Weinberger]

On 19.08.2016 17:24, Dmitry Vyukov wrote:
> If it exits then
> 
> Acked-by: Dmitry Vyukov <dvyukov@google.com>

Andrey, shall I carry this patch through the UML tree or
do you have something else in mind?

Thanks,
//richard

Re: [uml-devel] [PATCH] UML: don't discard .text.exit section

[Richard Weinberger]

On 19.08.2016 17:24, Dmitry Vyukov wrote:
> If it exits then
> 
> Acked-by: Dmitry Vyukov <dvyukov@google.com>

Andrey, shall I carry this patch through the UML tree or
do you have something else in mind?

Thanks,
//richard

------------------------------------------------------------------------------
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [PATCH] UML: don't discard .text.exit section

[Andrey Ryabinin]

On 08/22/2016 11:10 PM, Richard Weinberger wrote:
> On 19.08.2016 17:24, Dmitry Vyukov wrote:
>> If it exits then
>>
>> Acked-by: Dmitry Vyukov <dvyukov@google.com>
> 
> Andrey, shall I carry this patch through the UML tree or
> do you have something else in mind?
> 

Take it in the UML tree please.

> Thanks,
> //richard
> 

Re: [PATCH] UML: don't discard .text.exit section

[Richard Weinberger]

On 23.08.2016 11:59, Andrey Ryabinin wrote:
>> Andrey, shall I carry this patch through the UML tree or
>> do you have something else in mind?
>>
> 
> Take it in the UML tree please.

Ok! Applied to -next.

Thanks,
//richard

Re: [uml-devel] [PATCH] UML: don't discard .text.exit section

[Richard Weinberger]

On 23.08.2016 11:59, Andrey Ryabinin wrote:
>> Andrey, shall I carry this patch through the UML tree or
>> do you have something else in mind?
>>
> 
> Take it in the UML tree please.

Ok! Applied to -next.

Thanks,
//richard

------------------------------------------------------------------------------
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel