This is an archive of the discontinued LLVM Phabricator instance.

[lld] Recommit for implementing --ctors-in-init-array
AbandonedPublic

Authored by ChuanqiXu on Mar 11 2021, 3:53 AM.

Details

Summary

This patch is mainly based on D45508. The main differences between this patch and D45508 are:

  1. This patch simply renames the .ctors section and changes its type, instead of creating a new section. I did so since I find that the newly created section wouldn't be relocated since the relocation information is lost.
  2. This patch reverse the contents of .ctors after relocation as the original author mentioned.

Test-Plan: check-lld

Diff Detail

Event Timeline

ChuanqiXu created this revision.Mar 11 2021, 3:53 AM
ChuanqiXu requested review of this revision.Mar 11 2021, 3:53 AM
MaskRay added a comment.EditedMar 11 2021, 9:15 AM

I don't think we need this gold specific option. We can use D91187.

If you don't want to write a full linker script, my linker script proposal solving such problems in a generic way: https://sourceware.org/bugzilla/show_bug.cgi?id=26404
(it may need new folks chiming in)

BTW: why do you still use the deprecated .ctors/.dtors?
The customers I need to serve use .ctors But I've been careful and try not adding this option in the upstream as it is not really useful to others.

MaskRay requested changes to this revision.Mar 11 2021, 10:02 AM
This revision now requires changes to proceed.Mar 11 2021, 10:02 AM

BTW: why do you still use the deprecated .ctors/.dtors?

Since me want to use split-stack, which is a feature dependent on libgcc.a. And the corresponding initialization section in libgcc.a uses .ctors. Here is the codes moreStack. They uses assembly directly. But lld don't combine .ctors into .init_array, which would cause segmentation fault due to uninitialized code.

I don't think we need this gold specific option. We can use D91187.

If you don't want to write a full linker script, my linker script proposal solving such problems in a generic way: https://sourceware.org/bugzilla/show_bug.cgi?id=26404
(it may need new folks chiming in)

I tried to use the linker scripts dumped from ld to solve my problems. But it seems like we can't do that directly. I am not very clear about the reason. I would give it a try to use the linker scripts you give.

The customers I need to serve use .ctors But I've been careful and try not adding this option in the upstream as it is not really useful to others.

We are trying to develop a basic library using split stack. And there would be other projects dependent on this library. So if we want to use linker scripts to solve this problem, maybe we need to add linker scripts to every projects uses this library. I am worrying if it is not so convenient.

BTW: why do you still use the deprecated .ctors/.dtors?

Since me want to use split-stack, which is a feature dependent on libgcc.a. And the corresponding initialization section in libgcc.a uses .ctors. Here is the codes moreStack.

You can contribute a patch conditionally using .init_array if the target prefers SHT_INIT_ARRAY. They will assuredly accept such a patch.

They uses assembly directly. But lld don't combine .ctors into .init_array, which would cause segmentation fault due to uninitialized code.

Can you elaborate a bit why you use split-stack? As I understand it, gccgo and GoLLVM need split stack support. LLVM itself provides support for ARM and x86-64 (used by clang -fsplit-stack). As the article says, contiguous stack is the new technology, so I wonder whether you still want to invest in split stack.

I don't think we need this gold specific option. We can use D91187.

If you don't want to write a full linker script, my linker script proposal solving such problems in a generic way: https://sourceware.org/bugzilla/show_bug.cgi?id=26404
(it may need new folks chiming in)

I tried to use the linker scripts dumped from ld to solve my problems. But it seems like we can't do that directly. I am not very clear about the reason. I would give it a try to use the linker scripts you give.

The linker script fragment is the solution. We should not need the large chunk of code adding more legacy .ctors work.

You can chime in on https://sourceware.org/bugzilla/show_bug.cgi?id=26404 so that the work can be prioritized. With that generic solution, we can address various ad-hoc requests.

The customers I need to serve use .ctors But I've been careful and try not adding this option in the upstream as it is not really useful to others.

We are trying to develop a basic library using split stack. And there would be other projects dependent on this library. So if we want to use linker scripts to solve this problem, maybe we need to add linker scripts to every projects uses this library. I am worrying if it is not so convenient.

You can contribute a patch conditionally using .init_array if the target prefers SHT_INIT_ARRAY. They will assuredly accept such a patch.

Thanks, I would give it a try.

Can you elaborate a bit why you use split-stack? As I understand it, gccgo and GoLLVM need split stack support. LLVM itself provides support for ARM and x86-64 (used by clang -fsplit-stack). As the article says, contiguous stack is the new technology, so I wonder whether you still want to invest in split stack.

We use stackful coroutines extensively and we met some stack overflow problems. If we change the default stack size directly, it may waste many spaces. So we want to know whether split stack would solve our problems. At least, the statistics is really tempting.

The linker script fragment is the solution. We should not need the large chunk of code adding more legacy .ctors work.

You can chime in on https://sourceware.org/bugzilla/show_bug.cgi?id=26404 so that the work can be prioritized. With that generic solution, we can address various ad-hoc requests.

Thanks for suggestion!

ChuanqiXu abandoned this revision.Mar 16 2021, 1:44 AM