grimar (George Rimar)
User

Projects

User does not belong to any projects.

User Details

User Since
Sep 21 2015, 12:36 AM (144 w, 5 h)

Recent Activity

Today

grimar committed rL335460: [ELF] - ICF: Remove dead code. NFC..
[ELF] - ICF: Remove dead code. NFC.
Mon, Jun 25, 5:56 AM
grimar committed rLLD335460: [ELF] - ICF: Remove dead code. NFC..
[ELF] - ICF: Remove dead code. NFC.
Mon, Jun 25, 5:56 AM
grimar committed rL335453: [ELF] - ICF: test we do not merge sectinons which relocations points to symbols….
[ELF] - ICF: test we do not merge sectinons which relocations points to symbols…
Mon, Jun 25, 4:42 AM
grimar committed rLLD335453: [ELF] - ICF: test we do not merge sectinons which relocations points to symbols….
[ELF] - ICF: test we do not merge sectinons which relocations points to symbols…
Mon, Jun 25, 4:42 AM
grimar committed rLLD335447: [ELF] - Replace llvm::find_if with the loop. NFC..
[ELF] - Replace llvm::find_if with the loop. NFC.
Mon, Jun 25, 2:38 AM
grimar committed rL335447: [ELF] - Replace llvm::find_if with the loop. NFC..
[ELF] - Replace llvm::find_if with the loop. NFC.
Mon, Jun 25, 2:35 AM
grimar added a comment to D48405: [ELF] Assign RF_EXEC rank even if --no-rosegment or SECTIONS command is used.

You regard these changes:

llvm-readobj --elf-output-style=GNU -> llvm-readelf
llvm-mc ... -o %t -> llvm-mc ... -o %t.o

as "refactoring". They were for the purpose of consistency.

Mon, Jun 25, 2:10 AM
grimar added a comment to D48473: [ELF] Change llvm-objdump output for D48472: TEXT DATA -> TEXT.

Together with D48472 that probably looks reasonable for me, thanks!

Mon, Jun 25, 2:00 AM

Fri, Jun 22

grimar committed rL335357: [ELF] - ICF: test we do not merge sections which relocations differs only in….
[ELF] - ICF: test we do not merge sections which relocations differs only in…
Fri, Jun 22, 8:26 AM
grimar committed rLLD335357: [ELF] - ICF: test we do not merge sections which relocations differs only in….
[ELF] - ICF: test we do not merge sections which relocations differs only in…
Fri, Jun 22, 8:26 AM
grimar committed rLLD335354: [ELF] - Repair (re-enable) few ICF test cases..
[ELF] - Repair (re-enable) few ICF test cases.
Fri, Jun 22, 8:15 AM
grimar committed rL335354: [ELF] - Repair (re-enable) few ICF test cases..
[ELF] - Repair (re-enable) few ICF test cases.
Fri, Jun 22, 8:15 AM
grimar committed rL335351: [ELF] - ICF: Add 2 more test cases..
[ELF] - ICF: Add 2 more test cases.
Fri, Jun 22, 7:34 AM
grimar committed rLLD335351: [ELF] - ICF: Add 2 more test cases..
[ELF] - ICF: Add 2 more test cases.
Fri, Jun 22, 7:33 AM
grimar committed rLLD335346: [ELF] - ICF: remove excessive check. NFC..
[ELF] - ICF: remove excessive check. NFC.
Fri, Jun 22, 6:26 AM
grimar committed rL335346: [ELF] - ICF: remove excessive check. NFC..
[ELF] - ICF: remove excessive check. NFC.
Fri, Jun 22, 6:26 AM
grimar committed rLLD335337: [ELF] - Change how we handle suplicate -wrap. [NFC].
[ELF] - Change how we handle suplicate -wrap. [NFC]
Fri, Jun 22, 4:24 AM
grimar added a comment to D48298: [ELF] Uniquify --wrap list..

I would propose adding the ability to retrieve a unique filtered list of arguments.

for (StringRef Name : Args.getAllUniqueArgValues(OPT_wrap))
  Symtab->addSymbolWrap<ELFT>(Name);

Relevant for other options: --defsym, --trace-symbol, --undefined etc..

I am not sure it is useful for other options we have, but it perhaps can be a nice refactoring for this particular case.

For example, I am not sure we should use it for --defsym, as in theory it can have different values: --defsym=foo=1 ... --defsym=foo=2.
It is OK to process all of them one by one like we do now. The same applies for --trace-symbol and --undefined - there is no issue to process them one by one.
I would not overcomplicate the current code for these cases until it is proven to be a useful change.

For --defsym=foo=2 --defsym=foo=1 --defsym=foo=1 --defsym=foo=3 getAllUniqueArgValues() result would be foo=2, foo=1, foo=3. We wouldn't want the result to be sorted.
However, looking at the current use cases of getAllArgValues() it doesn't seem worth adding this at the moment.

Fri, Jun 22, 4:23 AM
grimar committed rL335337: [ELF] - Change how we handle suplicate -wrap. [NFC].
[ELF] - Change how we handle suplicate -wrap. [NFC]
Fri, Jun 22, 4:22 AM
grimar committed rL335336: Recommit r335333 "[MC] - Add .stack_size sections into groups and link them….
Recommit r335333 "[MC] - Add .stack_size sections into groups and link them…
Fri, Jun 22, 3:58 AM
grimar committed rL335333: Revert r335332 "[MC] - Add .stack_size sections into groups and link them with ..
Revert r335332 "[MC] - Add .stack_size sections into groups and link them with .
Fri, Jun 22, 3:32 AM
grimar committed rL335332: [MC] - Add .stack_size sections into groups and link them with .text.
[MC] - Add .stack_size sections into groups and link them with .text
Fri, Jun 22, 3:15 AM
grimar closed D46874: [MC] - Add .stack_size sections into groups and link them with .text.
Fri, Jun 22, 3:15 AM
grimar added a comment to D48405: [ELF] Assign RF_EXEC rank even if --no-rosegment or SECTIONS command is used.

This patch seems to do a lot of unnecessary changes to the test cases.
Generally, a best practice for the patch is to do a minimal amount of changes,
though here I see unnecessary renaming changes, refactoring(?) changes etc in tests.

Fri, Jun 22, 1:07 AM

Thu, Jun 21

grimar created D48433: [ELF] - Report unimplemented -z options..
Thu, Jun 21, 7:57 AM

Tue, Jun 19

grimar added a comment to D46874: [MC] - Add .stack_size sections into groups and link them with .text.

LGTM again :)

If there's no other opinion forthcoming, I'm okay with this going in, so that it doesn't sit around any longer.

Tue, Jun 19, 3:06 AM
grimar added a comment to D46874: [MC] - Add .stack_size sections into groups and link them with .text.

Ping.

Tue, Jun 19, 2:57 AM
grimar added a comment to D48298: [ELF] Uniquify --wrap list..

I would propose adding the ability to retrieve a unique filtered list of arguments.

for (StringRef Name : Args.getAllUniqueArgValues(OPT_wrap))
  Symtab->addSymbolWrap<ELFT>(Name);

Relevant for other options: --defsym, --trace-symbol, --undefined etc..

Tue, Jun 19, 2:52 AM
grimar added inline comments to D48298: [ELF] Uniquify --wrap list..
Tue, Jun 19, 1:32 AM

Mon, Jun 18

grimar committed rLLD334946: [ELF] - Simplify the conflict-variable-linkage-name.s test case. [NFC].
[ELF] - Simplify the conflict-variable-linkage-name.s test case. [NFC]
Mon, Jun 18, 7:19 AM
grimar committed rL334946: [ELF] - Simplify the conflict-variable-linkage-name.s test case. [NFC].
[ELF] - Simplify the conflict-variable-linkage-name.s test case. [NFC]
Mon, Jun 18, 7:19 AM
grimar accepted D48153: Add TARGET(foo) linker script directive..

This is probably OK. LGTM with a nit.

Mon, Jun 18, 6:37 AM
grimar added a comment to D47803: Add definition for ELF dynamic tag DT_SYMTAB_SHNDX..

I think this needs a test.

Mon, Jun 18, 3:05 AM

Fri, Jun 8

grimar accepted D31528: [ELF][MIPS] Multi-GOT implementation.

I think that:

  1. Simon is obviously an expert in MIPS. We have probably no other good reviewers on this platform here anyways.
  2. Patch has no critical stylish issues. I added few minor nits though. Anything else can be fixed after.
  3. It already took really too long to progress.
  4. Patch mostly affects MIPS parts of the LLD code (so it is isolated).
  5. Post-commit reviews are OK in general practice.
  6. It is important and desired patch for FreeBSD.
Fri, Jun 8, 3:58 AM · lld

Mon, Jun 4

grimar committed rL333883: [ELF] - Fix BB..
[ELF] - Fix BB.
Mon, Jun 4, 3:51 AM
grimar committed rLLD333883: [ELF] - Fix BB..
[ELF] - Fix BB.
Mon, Jun 4, 3:51 AM
grimar committed rLLD333880: [ELF] - Also use DW_AT_linkage_name when gathering information about variables….
[ELF] - Also use DW_AT_linkage_name when gathering information about variables…
Mon, Jun 4, 3:34 AM
grimar committed rL333880: [ELF] - Also use DW_AT_linkage_name when gathering information about variables….
[ELF] - Also use DW_AT_linkage_name when gathering information about variables…
Mon, Jun 4, 3:33 AM
grimar closed D47373: [ELF] - Also use DW_AT_linkage_name when gathering information about variables for error messages..
Mon, Jun 4, 3:33 AM

Fri, Jun 1

grimar added a comment to D47098: [ELF] Support R_X86_64_GOTPC{32,64}.

This revision is independent from D47507 though only with both we can make the following assembly sequence work no matter the value of _GLOBAL_OFFSET_TABLE_:

// -mcmodel=medium
// extern long _DYNAMIC[] __attribute__((visibility("hidden")));
// long* foo() {
//   return _DYNAMIC;
// }

	leaq	_GLOBAL_OFFSET_TABLE_(%rip), %rdx
	movabsq	$_DYNAMIC@GOTOFF, %rax

Does this cleaned-up revision look good? (The changes to relocation calculation have been removed)

Fri, Jun 1, 12:13 PM
grimar accepted D47145: [X86][ELF][CET] Adding the .note.gnu.property ELF section in X86.

LGTM.

Fri, Jun 1, 6:10 AM
grimar added inline comments to D47145: [X86][ELF][CET] Adding the .note.gnu.property ELF section in X86.
Fri, Jun 1, 5:28 AM
grimar added inline comments to D47145: [X86][ELF][CET] Adding the .note.gnu.property ELF section in X86.
Fri, Jun 1, 5:23 AM
grimar added a comment to D47373: [ELF] - Also use DW_AT_linkage_name when gathering information about variables for error messages..

This looks sensible to me. If I've got this right when the DW_AT_linkage name differs from the DW_AT_name the symbol name will match the DW_AT_linkage_name so the lookup by symbol name won't succeed if done via DW_AT_name.

Fri, Jun 1, 3:09 AM
grimar added a comment to D47373: [ELF] - Also use DW_AT_linkage_name when gathering information about variables for error messages..

Ping.

Fri, Jun 1, 1:59 AM

Thu, May 31

grimar added a comment to D47542: Implement --{push,pop}-state..

I don't know how it was implemented at the time when the bugzilla comment was posted, but it seems bfd linker's --push-state is a real stack now.

Thu, May 31, 6:04 AM
grimar added inline comments to D47542: Implement --{push,pop}-state..
Thu, May 31, 5:54 AM
grimar accepted D47542: Implement --{push,pop}-state..

This is LGTM as is, but also added a suggestion about possible simplification.
I have no strong preference here though. I assume no much people will use this option anyways.

Thu, May 31, 2:27 AM
grimar added inline comments to D47145: [X86][ELF][CET] Adding the .note.gnu.property ELF section in X86.
Thu, May 31, 1:51 AM

Wed, May 30

grimar added inline comments to D47145: [X86][ELF][CET] Adding the .note.gnu.property ELF section in X86.
Wed, May 30, 2:45 AM
grimar updated the diff for D46874: [MC] - Add .stack_size sections into groups and link them with .text.
  • Addressed grammar nits.
Wed, May 30, 1:22 AM
grimar added a comment to D46874: [MC] - Add .stack_size sections into groups and link them with .text.

Ping.

Wed, May 30, 1:17 AM

Tue, May 29

grimar added inline comments to D47098: [ELF] Support R_X86_64_GOTPC{32,64}.
Tue, May 29, 3:26 PM
grimar added a comment to D47098: [ELF] Support R_X86_64_GOTPC{32,64}.

If llvm-mc would emit R_X86_64_GOTPC32 too that we probably could do nothing here and continue resolving such relocations relative to the .got end.
I am not sure about the other targets, but if they also have special relocations for _GLOBAL_OFFSET_TABLE_, that could help to resolve this.

Or probably we could special case relocating _GLOBAL_OFFSET_TABLE_ symbol for now.

I think if we change anything we should probably make it Target specific or risk breaking something. I know that when I made the mistake of moving _GLOBAL_OFFSET_TABLE_ to be the base of .got.plt on Arm I broke Chrome https://bugs.llvm.org/show_bug.cgi?id=36555#c16 . This would have worked if llvm-mc had used R_ARM_BASE_PREL rather than R_ARM_REL32 but sadly it doesn't so it needs _GLOBAL_OFFSET_TABLE_ to be the base of the .got output section.

Tue, May 29, 9:52 AM
grimar added a comment to D47098: [ELF] Support R_X86_64_GOTPC{32,64}.

x86_64 ABI uses GOTPC32/GOTPC64 relocations for _GLOBAL_OFFSET_TABLE_:
(p40 https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-1.0.pdf)

Tue, May 29, 8:39 AM
grimar added a comment to D47098: [ELF] Support R_X86_64_GOTPC{32,64}.

I am not sure that the second way should work (if I understand everything correctly).
For x86 as you know we define _GLOBAL_OFFSET_TABLE_ in the .got.plt[0] now.
Then for example if we have the following TLS code:

addl $_GLOBAL_OFFSET_TABLE_, %ebx #add    $0x199f,%ebx, R_386_GOTPC
subl $8, %esp                                         #sub    $0x8,%esp
leal gd@tlsgd(%ebx), %eax                    #lea    -0x10(%ebx),%eax, R_386_TLS_GD

it expects the first line to be resolved to the end of .got (to the GOT base in ABI terminology).
If we redefine the relocations that use _FROM_END to use the location of the _GLOBAL_OFFSET_TABLE_ (I think that is what this patch tried to do),
then it will not help us I think as we will end up with the address of .got.plt at the first line. And the code will fail to find a proper TLS slot as a result since .got.plt
can be far away from .got in LLD.

I think that the raw calculation would work if R_386_TLS_GD (RelExpr R_TLSGD) were defined to be something like InX::Got->getGlobalDynAddr(Sym) + A - ("VA of where _GLOBAL_OFFSET_TABLE_ is defined"). Instead of InX::Got->getGlobalDynOffset(Sym) + A - InX::Got->getSize();.

Tue, May 29, 7:54 AM
grimar accepted D47473: [llvm-readobj] Support GNU_PROPERTY_X86_FEATURE_1_AND notes in .note.gnu.property.

LGTM

Tue, May 29, 7:07 AM
grimar added a comment to D47098: [ELF] Support R_X86_64_GOTPC{32,64}.

@MaskRay, do you have a sample app that does not work for you and you are trying to fix? I started to wonder what exactly the real-life use case that needs to be fixed here :)
Particularly how _GLOBAL_OFFSET_TABLE_ is used.

Tue, May 29, 6:13 AM
grimar added a comment to D47098: [ELF] Support R_X86_64_GOTPC{32,64}.

I can think of two possible fixes that satisfy the conditions:

  • Keep the _FROM_END relocations and define _GLOBAL_OFFSET_TABLE_ to be the end of the .got section on x86, extend the .got by one word so that _GLOBAL_OFFSET_TABLE_[0] can contain the link time address of _DYNAMIC. This sounds a bit hacky to me, but I think it would work.
  • Redefine the relocations that use _FROM_END to use the location of the _GLOBAL_OFFSET_TABLE_ symbol (or where we have defined it to be) rather than hard code the end of the .got section.

    Personally I'd favour the second approach as it looks like the _FROM_END relocations are a vestige of when _GLOBAL_OFFSET_TABLE_ was set to 0 and the value was never used. I'm not expert in x86 though so it would be best to get as many opinions as possible here.
Tue, May 29, 5:16 AM

Mon, May 28

grimar added a comment to D47098: [ELF] Support R_X86_64_GOTPC{32,64}.

One of the way I see how to solve it was suggested/described here: https://bugs.llvm.org/show_bug.cgi?id=36555#c19

Mon, May 28, 9:25 AM
grimar added a comment to D47379: [lld] Rename R_TLSGD/R_TLSLD to R_TLSGD_FROM_END/R_TLSLD_FROM_END [NFC].

New naming is confusing IMO. We had R_GOTONLY_PC_FROM_END, R_GOT_FROM_END and R_GOTREL_FROM_END.
Since names contains "GOT" it is clear that "FROM_END" says about the end of GOT.

But R_TLSGD_FROM_END is different made me think about the end of TLS first of all.

Fair enough, would anybody object to R_TLSGD_GOT_FROM_END and R_TLSLD_GOT_FROM_END?

Mon, May 28, 9:16 AM
grimar added a comment to D47098: [ELF] Support R_X86_64_GOTPC{32,64}.

Ok. After additional investigation (you mentioned TLS and I found a good sample for test),
I think we do the correct thing now.

Mon, May 28, 8:20 AM
grimar added inline comments to D47098: [ELF] Support R_X86_64_GOTPC{32,64}.
Mon, May 28, 4:02 AM
grimar added a comment to D47379: [lld] Rename R_TLSGD/R_TLSLD to R_TLSGD_FROM_END/R_TLSLD_FROM_END [NFC].

New naming is confusing IMO. We had R_GOTONLY_PC_FROM_END, R_GOT_FROM_END and R_GOTREL_FROM_END.
Since names contains "GOT" it is clear that "FROM_END" says about the end of GOT.

Mon, May 28, 1:57 AM
grimar added a comment to D47145: [X86][ELF][CET] Adding the .note.gnu.property ELF section in X86.

I think this should be splitted into 2 patches: one for codegen and one for llvm-readobj tool.

Mon, May 28, 1:46 AM

May 26 2018

grimar edited reviewers for D47098: [ELF] Support R_X86_64_GOTPC{32,64}, added: psmith; removed: espindola.
May 26 2018, 3:46 AM
grimar added a comment to D47098: [ELF] Support R_X86_64_GOTPC{32,64}.

I am not sure in this patch honestly. I'll add Peter, the author of D34355/D44259.

May 26 2018, 3:45 AM

May 25 2018

grimar created D47373: [ELF] - Also use DW_AT_linkage_name when gathering information about variables for error messages..
May 25 2018, 6:50 AM
grimar added a comment to D47098: [ELF] Support R_X86_64_GOTPC{32,64}.

I suggest separating R_X86_64_GOTOFF64 change from this patch to different one. I think it is completely independent.

May 25 2018, 2:03 AM

May 24 2018

grimar added a comment to D46874: [MC] - Add .stack_size sections into groups and link them with .text.

Thanks, James!

May 24 2018, 3:19 AM
grimar added a comment to D46874: [MC] - Add .stack_size sections into groups and link them with .text.

What I can probably do is to compute ID based on the .text section name.

So that for no -ffunction-sections case it would emit several .stack_sizes with the same ID and so that final object would contain only a single section finally after merging them,
just like we would want.

It would work for my sample case too I think. Let me try to implement this.

Yes, I think this all makes sense. Here's a summary of what I think is best without -function-sections enabled:

// These two share a .stack_sizes section
void func1() {}
void func2() {}

// These two share a different .stack_sizes section.
void func3()  __attribute__ ((section (".text.other"))) {}
void func4()  __attribute__ ((section (".text.other"))) {}

// This has it's own .stack_sizes section in its group
template <int I> int func5() { return I; }
May 24 2018, 2:12 AM
grimar updated the diff for D46874: [MC] - Add .stack_size sections into groups and link them with .text.
  • Generate unique ID basing on begin symbol.
  • Updated test case.
May 24 2018, 2:10 AM

May 23 2018

grimar planned changes to D46874: [MC] - Add .stack_size sections into groups and link them with .text.

What I can probably do is to compute ID based on the .text section name.

May 23 2018, 8:25 AM
grimar added a comment to D46874: [MC] - Add .stack_size sections into groups and link them with .text.

Maybe I've been confusing things, because from what I'm seeing in this, there is now a unique stack sizes section for every function, even without -ffunction-sections, which I don't think we want.

May 23 2018, 8:09 AM
grimar updated the diff for D46874: [MC] - Add .stack_size sections into groups and link them with .text.
  • Updated patch to match the behavior I suggested in latest comments.

(unconditionally add unique attribute)

May 23 2018, 7:36 AM
grimar added inline comments to D46874: [MC] - Add .stack_size sections into groups and link them with .text.
May 23 2018, 7:02 AM
grimar added inline comments to D46874: [MC] - Add .stack_size sections into groups and link them with .text.
May 23 2018, 6:52 AM
grimar updated the diff for D46874: [MC] - Add .stack_size sections into groups and link them with .text.

I think that is fine. Updated the test cases as suggested.

May 23 2018, 5:37 AM
grimar updated the diff for D46874: [MC] - Add .stack_size sections into groups and link them with .text.
  • Updated test case (added no -ffunction-sections case).
May 23 2018, 5:11 AM
grimar updated the diff for D46874: [MC] - Add .stack_size sections into groups and link them with .text.
  • Do not do unification when no -ffunction-section is specified.
May 23 2018, 4:05 AM
grimar added a comment to D46874: [MC] - Add .stack_size sections into groups and link them with .text.

And observing the results, I think it is worth to stop doing unification when -ffunction-sections is off
(to reduce the number of sections and possible linker slowdown).

I'll update the patch.

I agree, although with one caveat: COMDAT sections should always have a separate .stack_sizes section (maybe in their group), as otherwise we'll have the same invalid problem for discarded COMDATs as I mentioned earlier - i.e. their entries will be preserved, even though they are no longer present.

May 23 2018, 4:02 AM
grimar added a comment to D46874: [MC] - Add .stack_size sections into groups and link them with .text.

Is .stack_sizes off by default? I assume so, and if it isn't, it probably should be, since it's not necessarily useful for everybody. If so, I'd suggest you go ahead with this change - it will only impact those who are using it, and they probably want it done properly if they are using -ffunction-sections. Maybe @ruiu has some suggestions from the linker's point of view too?

May 23 2018, 2:20 AM
grimar added a comment to D46874: [MC] - Add .stack_size sections into groups and link them with .text.

The problem of this patch is benchmark results I had.

May 23 2018, 1:15 AM

May 21 2018

grimar planned changes to D46874: [MC] - Add .stack_size sections into groups and link them with .text.

I'll update the status of this later.

May 21 2018, 3:33 AM

May 18 2018

grimar closed D46200: Mitigate relocation overflow [part 2 of 2].

Was committed as r332688

May 18 2018, 2:19 AM
grimar accepted D46200: Mitigate relocation overflow [part 2 of 2].

LGTM.

May 18 2018, 2:08 AM

May 17 2018

grimar added a comment to D46200: Mitigate relocation overflow [part 2 of 2].

I think Text is fine, but if you don't like it, I'd name it Default.

May 17 2018, 11:36 AM
grimar added inline comments to D46200: Mitigate relocation overflow [part 2 of 2].
May 17 2018, 11:19 AM
grimar added inline comments to D46200: Mitigate relocation overflow [part 2 of 2].
May 17 2018, 11:16 AM
grimar committed rL332589: [ELF] - Do not crash when do --gc-sections for non-allocatable metadata….
[ELF] - Do not crash when do --gc-sections for non-allocatable metadata…
May 17 2018, 3:06 AM
grimar committed rLLD332589: [ELF] - Do not crash when do --gc-sections for non-allocatable metadata….
[ELF] - Do not crash when do --gc-sections for non-allocatable metadata…
May 17 2018, 3:06 AM
grimar closed D46880: [ELF] - Do not crash when do --gc-sections for non-allocatable metadata sections..
May 17 2018, 3:05 AM
grimar added a comment to D46874: [MC] - Add .stack_size sections into groups and link them with .text.

The default behavior is to group by name.

Ah okay, I haven't really worked with that area. I assume it's the same with other linkers?

May 17 2018, 3:01 AM
grimar added a comment to D46200: Mitigate relocation overflow [part 2 of 2].

It looks a bit hacky. But I think it should work. Rui, what do you think?

May 17 2018, 2:28 AM
grimar added a comment to D46874: [MC] - Add .stack_size sections into groups and link them with .text.

! In D46874#1102740, @jhenderson wrote:

! In D46874#1102734, @grimar wrote:
And renaming to something like .stack_sizes.XXX would require linker side change to place them into the single output section I think,
as currently they are merged by name, just like other regular sections.

This surprises me. I thought that default grouping would match up to the first '.', like it does for e.g. .text or .data grouping (i.e. .text.foo and .text.bar end up in .text). Or are some sections special-cased for this?

May 17 2018, 2:14 AM
grimar added a comment to D46874: [MC] - Add .stack_size sections into groups and link them with .text.

@grimar, what is the link-time performance of doing this on something with many functions?

May 17 2018, 1:57 AM

May 16 2018

grimar added a comment to D46880: [ELF] - Do not crash when do --gc-sections for non-allocatable metadata sections..

This is for use with D46874. (currently LLD just crashes)

May 16 2018, 2:14 AM
grimar updated the diff for D46874: [MC] - Add .stack_size sections into groups and link them with .text.

I switched to IR test case (and also fixed another one that turned out to be failing).

May 16 2018, 2:04 AM
grimar accepted D46839: [lld] Make ALIGN work with -r in linker scripts.

LGTM

May 16 2018, 12:25 AM

May 15 2018

grimar added a comment to D45519: [ELF] - Change the way of sorting local symbols..

Can we land it stand alone? It still brings a noticeable speed-up even without D45548.

May 15 2018, 7:45 AM