In D59531#1434812, @ruiu wrote:

In D59531#1434312, @pcc wrote:

Is it possible for this to fail with a linker script that looks like:

SECTIONS {
  . = SIZEOF_HEADERS;
  .note1 : { *(.note1) }
  . = 0x10000;
  .note2 : { *(.note2) }
}

?

Is this realistic? I'm not worried too much about this because it seems you are intentionally creating a large gap between .note sections.

It seems quite easy to handle TLS. See the change that I just uploaded. Similar code would be necessary to correctly extract partitions if for example the first partition had a .tbss whose address space extended into the second partition.

Handle TLS

In D58426#1435243, @jakehehrlich wrote:

I mean in the handler for the option you can re-traverse the program headers for each section and handle your check.

In D58426#1433713, @jakehehrlich wrote:

For your use case you can simply traverse the program headers for each to see if a section is indeed loadable. e.g. you want to strip all non-loadable allocated sections. That seems like a good thing but this probably isn't the right way to handle it IMO.

Is it possible for this to fail with a linker script that looks like:

SECTIONS {
  . = SIZEOF_HEADERS;
  .note1 : { *(.note1) }
  . = 0x10000;
  .note2 : { *(.note2) }
}

?

LGTM

In D56828#1428674, @MaskRay wrote:

Looks good, please go ahead and modify the tests.

I'll take that as approval as in offline discussion ruiu said he didn't have objection and was waiting on your decision :)

Is there a test that shows that the behavior is correct if a .bss.rel.ro is large enough to require another page?

LGTM

Looks good modulo tests.

Looks good, please go ahead and modify the tests.

Yes, I meant for all of them.

It looks like our handling of weak undef in executables is a little unusual. At least it does not match the other two linkers. Taking ELF/weak-undef.s as an example:

$ ld.lld ra/obj/lld/test/ELF/Output/weak-undef.s.tmp.o -o ra/obj/lld/test/ELF/Output/weak-undef.s.tmp -pie 
$ nm -D ra/obj/lld/test/ELF/Output/weak-undef.s.tmp
                 w foo
$ ld.gold ra/obj/lld/test/ELF/Output/weak-undef.s.tmp.o -o ra/obj/lld/test/ELF/Output/weak-undef.s.tmp -pie 
$ nm -D ra/obj/lld/test/ELF/Output/weak-undef.s.tmp
nm: ra/obj/lld/test/ELF/Output/weak-undef.s.tmp: no symbols
$ ld.bfd ra/obj/lld/test/ELF/Output/weak-undef.s.tmp.o -o ra/obj/lld/test/ELF/Output/weak-undef.s.tmp -pie 
$ nm -D ra/obj/lld/test/ELF/Output/weak-undef.s.tmp
nm: ra/obj/lld/test/ELF/Output/weak-undef.s.tmp: no symbols

This needs a test under test/CodeGen at least.

In D59269#1426677, @ruiu wrote:

I thought that we could protect BumpPtrAllocator::Allocate with a mutex, but since StringSaver directly calls that function, there's no way to acquire a lock before calling that function. Maybe we should protect StringSaver::save?

In D59269#1426604, @ruiu wrote:

I wonder how much does it actually cost to acquire a lock under the situation where there's no contention. Except this place, all accesses to BAlloc are already serialized, so there's usually no contention. If the cost of acquiring a lock under that situation is negligible, I'd imagine that always acquiring the lock could be a reasonable option.

Thanks Peter. I think I prefer this approach.

Hmm, I remembered that we can just do e.g. REQUIRES: !asan. So maybe we should make that change globally and only define the positive features here.

• Fix typo

LGTM

An alternative to storing this field in Segment would be to store a reference to the file contents as a field in Object. That would allow you to access the segment contents using the OriginalOffset and Size fields, and also seems like it might allow you to remove the various Contents fields from the Section hierarchy. So maybe we should remove this field in case that approach turns out to work out better?

LGTM

In D59133#1422951, @krytarowski wrote:

In D59133#1422906, @thakis wrote:

In D59133#1422851, @krytarowski wrote:

How about DFSan and shadowcallstack?

I don't understand how that question is related to this change. What do you mean?

shadowcallstack still misses even runtime.

In D59133#1422960, @eugenis wrote:

LGTM, good job!

Regarding dfsan, I think it has users @pcc

An alternative solution might be to create a PT_NOTE for each note upfront, and opportunistically merge them if they end up being laid out contiguously. This would also handle the case where a note's size is not a multiple of its alignment.

LGTM

Turns own that IsUsedInRegularObject is set for lazy (archive) symbols.

LGTM

Thanks for cleaning this up.