Page MenuHomePhabricator
Feed Advanced Search

Jul 31 2019

rprichard added a comment to D64930: [ELF][AArch64] Allow PT_LOAD to have overlapping p_offset ranges.

Its aarch64 port is correct (https://sourceware.org/bugzilla/show_bug.cgi?id=24606).

Jul 31 2019, 2:19 PM · Restricted Project

Jul 30 2019

rprichard accepted D65459: [AARCH64] Renumber relocation codes R_AARCH64_TLS_TPREL64 and DTPMOD64.

Looks good to me.

Jul 30 2019, 4:19 PM
rprichard added a comment to D64930: [ELF][AArch64] Allow PT_LOAD to have overlapping p_offset ranges.

I had a quick look at the PR to see if I could make it fail (with D64930 applied) with glibc without hacking the binary with the trim-pt-tls program with this change. I wasn't able to do so although that doesn't mean it is impossible. Having said that I agree that it would be safer to be conservative in our demands on the capabilities of dynamic loaders.

Jul 30 2019, 3:02 PM · Restricted Project

Jul 29 2019

rprichard added a comment to D64930: [ELF][AArch64] Allow PT_LOAD to have overlapping p_offset ranges.

I'm not sure about breaking the (p_vaddr % p_align == 0) invariant. ld.bfd, gold, and (for the most part) lld currently provide this invariant for TLS segments in output files.

Jul 29 2019, 8:43 PM · Restricted Project
Herald updated subscribers of D64906: [ELF][PPC] Allow PT_LOAD to have overlapping p_offset ranges.
Jul 29 2019, 4:30 PM · Restricted Project

Jun 27 2019

rprichard added reviewers for D63904: [Android] Use ELF TLS for Android API level 29+: danalbert, srhines.

Android's ELF TLS requires lld, but the NDK doesn't default to lld yet. (I believe the NDK uses bfd on arm64 and gold everywhere else.) When the NDK Clang driver targets 29/Q+, the NDK could generate executables or shared objects using ELF TLS that don't load on 29/Q.

Jun 27 2019, 4:54 PM · Restricted Project

May 17 2019

rprichard added a comment to D61824: [ARM][AArch64] Overalign .tbss (Android Bionic hack) to avoid p_vaddr%p_align!=0.

The waste is not just 48 bytes in the ELF image on disk, but up to 63 bytes in each thread. Depending on how that falls, the waste is likely actually either 0 bytes or 4096 bytes per thread, since the memory is allocated with page granularity.

Forcing the alignment will also force musl to *always* mmap space (on page granularity, so A LOT of waste) for the main thread's TLS at startup, rather than using the built-in bss space intended to be used when the application's TLS needs are small, since the built-in space does not have excess alignment. This imposes a syscall as well, and a new failure mode for static-linked binaries that may have been intended not to be able to fail after exec.

Please, drop this ridiculous and costly hack for Bionic or put it under the --android-tls option or whatever.

May 17 2019, 6:17 PM · Restricted Project
rprichard added a comment to D61824: [ARM][AArch64] Overalign .tbss (Android Bionic hack) to avoid p_vaddr%p_align!=0.
In D61824#1499997, @nsz wrote:

i think glibc is right (comes up with a tlsoffset%p_align == p_vaddr%p_align for the module) and musl and other implementations are wrong (they may not get the tlsoffset right in this case: it seems musl always computes tlsoffset%p_align==0 on tls variant 1 targets).

May 17 2019, 5:15 PM · Restricted Project
rprichard added a comment to D62059: [ELF] Don't align PT_TLS's p_memsz.

I had suggested doing something like this at https://reviews.llvm.org/D53906#1326683. I like the idea, but I think we need to fix up the variant 2 case in getTlsTpOffset:

May 17 2019, 12:55 PM · Restricted Project
rprichard accepted D62055: [ARM][AArch64] Revert Android Bionic PT_TLS overaligning hack.

I'm wondering if ruiu and/or srhines want to weigh in. I think I'm OK with reverting this change, at least for now, so that we can get the lld+glibc combination working again. It seems like a good idea to fix the https://bugs.llvm.org/show_bug.cgi?id=41527 regression in LLVM 8.0.1, which is coming up soon.

May 17 2019, 12:30 AM · Restricted Project

May 15 2019

rprichard added a comment to D61973: [AArch64] Support .reloc *, R_AARCH64_NONE, *.

FWIW: I noticed that the binutils assembler's .reloc directive can reference an arbitrary symbol whereas with this patch, a .reloc directive referencing a label turns into a section reference. e.g.:

May 15 2019, 11:22 PM · Restricted Project
rprichard added a comment to D61973: [AArch64] Support .reloc *, R_AARCH64_NONE, *.

The commit message only mentions AArch64, but the commit appears to also add support for R_ARM_NONE. I tried using R_ARM_NONE, though, and was unsuccessful:

May 15 2019, 10:34 PM · Restricted Project
rprichard added a comment to D61824: [ARM][AArch64] Overalign .tbss (Android Bionic hack) to avoid p_vaddr%p_align!=0.
In D61824#1502750, @nsz wrote:

I think that basically works. It would add a TLS segment to every Android executable, even those that aren't using ELF TLS:

  • If the placeholder symbol has size 1 and 64-byte alignment, then every Android executable (targeting Q(29) and up) would have a PT_TLS segment of 64-byte size and alignment with gold or lld.
  • If the placeholder symbol in .tdata has size 0 instead, then ld.bfd omits the .tdata section from the output if there aren't any other non-empty .tdata sections. This is a problem if there are other TLS sections (.tbss). Android is switching to lld, though, so maybe it's OK. (The NDK still defaults to bfd and gold.)
  • If the placeholder symbol has a size of 48 bytes and 1-byte alignment, then libc.so can't use alignment to detect whether space was reserved. I can think of a couple ways for space to not be reserved:
    • Using an NDK that's too old
    • Using a too-old NDK API level, assuming this placeholder symbol is omitted when targeting old versions of Bionic (because Q(29) is currently rejecting an underaligned TLS segment...)

i think the placeholder tls symbol size and alignment should
be exactly such that it covers the bionic internal tls slots.

May 15 2019, 9:04 PM · Restricted Project
rprichard added a comment to D61824: [ARM][AArch64] Overalign .tbss (Android Bionic hack) to avoid p_vaddr%p_align!=0.

@rprichard Rich Felker briefly mentioned this can be worked around in crt1.o. My understanding is that:

  1. create a dummy .tdata ((a) with placeholder TLS variables of 8*sizeof(void*) bytes (b) sh_addralign=8*sizeof(void*)) in crt1.o (and its variants)
  2. create a R_{ARM,AARCH64}_NONE from .text offset 0 to the .tdata (this prevents --gc-sections stripping)
  3. no hack is needed in ld.bfd/gold/lld. crt1.o is linked into executables. The linker applies its usual Rules for Linking Unrecognized Sections and concatenates .tdata and .tbss. The .tdata from crt1.o will be the first input section in the TLS segment. Don't use the dummy part of the TLS block (they may collide with Bionic's reserved TLS slots)

    Does this approach work?
May 15 2019, 3:16 AM · Restricted Project
rprichard added inline comments to D61931: [Driver] Use --android-tls for Android ARM/AArch64 when lld is used.
May 15 2019, 12:03 AM · Restricted Project

Feb 22 2019

rprichard abandoned D53904: [ELF] Define PT_ANDROID_TLS_TPOFF.

This change isn't needed anymore -- Bionic instead uses the standard TLS layout on x86-{32,64} and arm{32,64}, but with a minimum alignment of 8 words on arm{32,64}.

Feb 22 2019, 6:45 PM · Restricted Project

Jan 8 2019

rprichard committed rLLD350681: [ARM][AArch64] Increase TLS alignment to reserve space for Android's TCB.
[ARM][AArch64] Increase TLS alignment to reserve space for Android's TCB
Jan 8 2019, 4:13 PM
rprichard committed rL350681: [ARM][AArch64] Increase TLS alignment to reserve space for Android's TCB.
[ARM][AArch64] Increase TLS alignment to reserve space for Android's TCB
Jan 8 2019, 4:13 PM
rprichard closed D53906: [ARM][AArch64] Increase TLS alignment to reserve space for Android's TCB.
Jan 8 2019, 4:13 PM · Restricted Project
rprichard updated the diff for D53906: [ARM][AArch64] Increase TLS alignment to reserve space for Android's TCB.

Update comment again.

Jan 8 2019, 4:08 PM · Restricted Project
rprichard updated the diff for D53906: [ARM][AArch64] Increase TLS alignment to reserve space for Android's TCB.

Remove the blank line.

Jan 8 2019, 3:47 PM · Restricted Project
rprichard updated the diff for D53906: [ARM][AArch64] Increase TLS alignment to reserve space for Android's TCB.

Add an explanation of how overaligning the executable TLS segment reserves the extra space Android needs for its TCB slots.

Jan 8 2019, 3:35 PM · Restricted Project
rprichard updated the diff for D53906: [ARM][AArch64] Increase TLS alignment to reserve space for Android's TCB.

Move comment into if-statement and clarify that it's only for ARM and AArch64.

Jan 8 2019, 2:54 PM · Restricted Project
rprichard added inline comments to D53906: [ARM][AArch64] Increase TLS alignment to reserve space for Android's TCB.
Jan 8 2019, 2:48 PM · Restricted Project

Jan 7 2019

rprichard added a comment to D53906: [ARM][AArch64] Increase TLS alignment to reserve space for Android's TCB.

I think this CL is ready for review now.

Jan 7 2019, 6:23 PM · Restricted Project

Dec 12 2018

rprichard added a comment to D55581: Switch Android from TLS_SLOT_TSAN(8) to TLS_SLOT_SANITIZER(6).

Thanks for looking at the buildbot failure. Let me know if I need to revert my two commits.

Dec 12 2018, 5:51 PM
rprichard committed rCRT348984: Switch Android from TLS_SLOT_TSAN(8) to TLS_SLOT_SANITIZER(6).
Switch Android from TLS_SLOT_TSAN(8) to TLS_SLOT_SANITIZER(6)
Dec 12 2018, 2:49 PM
rprichard committed rL348983: [hwasan] Android: Switch from TLS_SLOT_TSAN(8) to TLS_SLOT_SANITIZER(6).
[hwasan] Android: Switch from TLS_SLOT_TSAN(8) to TLS_SLOT_SANITIZER(6)
Dec 12 2018, 2:49 PM
rprichard committed rL348984: Switch Android from TLS_SLOT_TSAN(8) to TLS_SLOT_SANITIZER(6).
Switch Android from TLS_SLOT_TSAN(8) to TLS_SLOT_SANITIZER(6)
Dec 12 2018, 2:49 PM
rprichard closed D55592: [hwasan] Android: Switch from TLS_SLOT_TSAN(8) to TLS_SLOT_SANITIZER(6).
Dec 12 2018, 2:49 PM
rprichard closed D55581: Switch Android from TLS_SLOT_TSAN(8) to TLS_SLOT_SANITIZER(6).
Dec 12 2018, 2:49 PM

Dec 11 2018

rprichard added a comment to D55581: Switch Android from TLS_SLOT_TSAN(8) to TLS_SLOT_SANITIZER(6).

I switched HWAddressSanitizer::getHwasanThreadSlotPtr over:
https://reviews.llvm.org/D55592

Dec 11 2018, 6:58 PM
rprichard added reviewers for D55592: [hwasan] Android: Switch from TLS_SLOT_TSAN(8) to TLS_SLOT_SANITIZER(6): srhines, eugenis.
Dec 11 2018, 6:48 PM
rprichard added a parent revision for D55592: [hwasan] Android: Switch from TLS_SLOT_TSAN(8) to TLS_SLOT_SANITIZER(6): D55581: Switch Android from TLS_SLOT_TSAN(8) to TLS_SLOT_SANITIZER(6).
Dec 11 2018, 6:48 PM
rprichard added a child revision for D55581: Switch Android from TLS_SLOT_TSAN(8) to TLS_SLOT_SANITIZER(6): D55592: [hwasan] Android: Switch from TLS_SLOT_TSAN(8) to TLS_SLOT_SANITIZER(6).
Dec 11 2018, 6:48 PM
rprichard created D55592: [hwasan] Android: Switch from TLS_SLOT_TSAN(8) to TLS_SLOT_SANITIZER(6).
Dec 11 2018, 6:47 PM
rprichard accepted D55587: [hwasan] Verify Android TLS slot at startup..
Dec 11 2018, 6:22 PM
rprichard added a comment to D55587: [hwasan] Verify Android TLS slot at startup..

Looks good to me.

Dec 11 2018, 4:40 PM
rprichard added a reviewer for D55581: Switch Android from TLS_SLOT_TSAN(8) to TLS_SLOT_SANITIZER(6): enh.
Dec 11 2018, 2:34 PM
rprichard added reviewers for D55581: Switch Android from TLS_SLOT_TSAN(8) to TLS_SLOT_SANITIZER(6): eugenis, srhines.

For context:

Dec 11 2018, 2:34 PM
rprichard created D55581: Switch Android from TLS_SLOT_TSAN(8) to TLS_SLOT_SANITIZER(6).
Dec 11 2018, 2:26 PM

Dec 10 2018

rprichard retitled D53906: [ARM][AArch64] Increase TLS alignment to reserve space for Android's TCB from [ELF] Allow configuring the TLS layout for an Android executable to [ARM][AArch64] Increase TLS alignment to reserve space for Android's TCB.
Dec 10 2018, 11:24 PM · Restricted Project
rprichard updated the diff for D53906: [ARM][AArch64] Increase TLS alignment to reserve space for Android's TCB.

I implemented the proposed fix for ARM/AArch64 (i.e. set a minimum alignment of 8 words on an executable's TLS segment). I think this will work for Android -- i.e. we'll leave the x86 layout alone. Even if we *did* decide to change the x86 TLS layout later, it'd probably make sense to use this approach on ARM.

Dec 10 2018, 11:24 PM · Restricted Project

Nov 12 2018

rprichard added a comment to D53906: [ARM][AArch64] Increase TLS alignment to reserve space for Android's TCB.

FWIW: I've published a draft of a document summarizing ELF TLS with emphasis on issues affecting Bionic. It's at https://android.googlesource.com/platform/bionic/+/master/docs/elf-tls.md. These sections are relevant to this LLVM patch:

Nov 12 2018, 4:32 PM · Restricted Project

Nov 2 2018

rprichard added a comment to D53906: [ARM][AArch64] Increase TLS alignment to reserve space for Android's TCB.

On non-Android Linux, it looks like hwasan and msan instrumentation use an IE-model TLS variable (via the GOT), which is more of a load-time constant than a compile-time one.

Nov 2 2018, 3:35 PM · Restricted Project

Nov 1 2018

rprichard updated subscribers of D53906: [ARM][AArch64] Increase TLS alignment to reserve space for Android's TCB.

I'm wondering whether moving the TLS_SLOT_TSAN slot is feasible. e.g. This sanitizer code would stop working, but it could presumably be fixed in a newer sanitizer library:

// The Android Bionic team has allocated a TLS slot for TSan starting with N,
// given that Android currently doesn't support ELF TLS. It is used to store
// Sanitizers thread specific data.
static const int TLS_SLOT_TSAN = 8;
Nov 1 2018, 5:46 PM · Restricted Project
rprichard added a comment to D53906: [ARM][AArch64] Increase TLS alignment to reserve space for Android's TCB.

What I'm currently seeking is a simple way to create executables/DSOs that are compatible on non-Android and Android, without introducing any new command line flag or a target-dependent logic. I believe it is OK to waste a few words on non-Android if we can achieve that goal. Another idea that is in line with that is to always set a >8 word alignment (you suggested 16, but I don't know why it has to be 16) to a TLS segment if ARM or AArch64. Maybe that could produce a binary that is compatible both Android and non-Android?

Nov 1 2018, 5:18 PM · Restricted Project
rprichard added a comment to D53906: [ARM][AArch64] Increase TLS alignment to reserve space for Android's TCB.

Setting a large alignment to the TLS segment to make room from TP and the TLS segment is an interesting idea. It is tempting, but at the same time it feels a bit too subtle and perhaps fragile. Looks like it is a very indirect way to do what we actually want to do.

If I understand correctly, what we want to do is boiled down to this:

 // A TLS symbol's virtual address is relative to the TLS segment. Add a
 // target-specific adjustment to produce a thread-pointer-relative offset.
 static int64_t getTlsTpOffset() {
   switch (Config->EMachine) {
   case EM_ARM:
   case EM_AARCH64:
     // Variant 1. The thread pointer points to a TCB with a fixed 2-word size,
     // followed by a variable amount of alignment padding, followed by the TLS
    // segment.
-    return alignTo(Config->Wordsize * 2, Out::TlsPhdr->p_align);
+    if (Android)
+      return alignTo(Config->Wordsize * 6, Out::TlsPhdr->p_align);
+    else
+      return alignTo(Config->Wordsize * 2, Out::TlsPhdr->p_align);
   case EM_386:
   case EM_X86_64:
     // Variant 2. The TLS segment is located just before the thread pointer.
     return -Out::TlsPhdr->p_memsz;

Is this understanding correct? If so, one radical but simple approach would be to always skip the first 6 words from TP on ARM and AArch64 whether it is Android or not. Obviously that wastes 4 words per a thread, but since thread is not a lightweight data structure, it might be negligible.

Nov 1 2018, 5:01 PM · Restricted Project
rprichard added a comment to D53906: [ARM][AArch64] Increase TLS alignment to reserve space for Android's TCB.

Increasing the alignment of the TLS segment is an interesting idea as it allows the possibility of a larger TCB and in theory could also be used by the loader to detect compatible ELF files (reject those without the alignment).

One possible way to achieve this without linker changes would be for the Android startup equivalent crt0.s to have a zero sized TLS .data section with 16 byte alignment. This would have the problem that all executables and shared libraries that didn't use TLS would get a 0 sized TLS segment.

Nov 1 2018, 2:39 PM · Restricted Project

Oct 31 2018

rprichard updated subscribers of D53906: [ARM][AArch64] Increase TLS alignment to reserve space for Android's TCB.

@peter.smith Thanks for taking a look. That's a good summary of the problem.

Oct 31 2018, 7:21 PM · Restricted Project
rprichard added a comment to D53906: [ARM][AArch64] Increase TLS alignment to reserve space for Android's TCB.

As a near-equivalent to this patch, if we had a good way of increasing an executable's TLS segment alignment to 16 words, then libc could allocate the Bionic slots in the alignment padding between the 2-word TCB and the TLS segment. In that case, Android executables would still be following the official TLS ABI, but slightly subsetted.

Oct 31 2018, 7:21 PM · Restricted Project
rprichard committed rL345775: [ELF] Refactor per-target TLS layout configuration. NFC..
[ELF] Refactor per-target TLS layout configuration. NFC.
Oct 31 2018, 1:56 PM
rprichard committed rLLD345775: [ELF] Refactor per-target TLS layout configuration. NFC..
[ELF] Refactor per-target TLS layout configuration. NFC.
Oct 31 2018, 1:56 PM
rprichard closed D53905: [ELF] Refactor per-target TLS layout configuration. NFC..
Oct 31 2018, 1:56 PM
rprichard updated the diff for D53906: [ARM][AArch64] Increase TLS alignment to reserve space for Android's TCB.

Update according to the latest revision of D53905 (export getTlsTpOffset).

Oct 31 2018, 1:21 PM · Restricted Project
rprichard updated the diff for D53905: [ELF] Refactor per-target TLS layout configuration. NFC..

Make getTlsTpOffset a file-scope static function.

Oct 31 2018, 1:20 PM

Oct 30 2018

rprichard updated the summary of D53906: [ARM][AArch64] Increase TLS alignment to reserve space for Android's TCB.
Oct 30 2018, 6:48 PM · Restricted Project
rprichard updated the diff for D53906: [ARM][AArch64] Increase TLS alignment to reserve space for Android's TCB.

Rebase on updated parent revision (TLS layout consolidated in getTlsTpOffset).

Oct 30 2018, 6:46 PM · Restricted Project
rprichard retitled D53905: [ELF] Refactor per-target TLS layout configuration. NFC. from [ELF] Refactor TLS layout TargetInfo config. NFC. to [ELF] Refactor per-target TLS layout configuration. NFC..
Oct 30 2018, 6:40 PM
rprichard updated the diff for D53905: [ELF] Refactor per-target TLS layout configuration. NFC..

Replace the TargetInfo TLS layout fields with a switch on Config->EMachine.

Oct 30 2018, 6:35 PM
rprichard added inline comments to D53905: [ELF] Refactor per-target TLS layout configuration. NFC..
Oct 30 2018, 5:32 PM
rprichard added a comment to D53906: [ARM][AArch64] Increase TLS alignment to reserve space for Android's TCB.

Yeah, I also need to modify libc and the loader. The problem is that, with the TLS local-exec (LE) access model used in executables, the static linker writes a thread-pointer-relative offset into an executable's text section, which the loader can't relocate. With the next-most efficient model, initial-exec (IE), the linker stores TLS offsets in the GOT, which the loader does relocate. (Disabling LE in the compiler+linker in favor of IE is another way of resolving this ABI conflict, but IIRC, it was also problematic. e.g. We can't do LD->LE relaxation anymore.)

Oct 30 2018, 5:19 PM · Restricted Project
rprichard added a comment to D53906: [ARM][AArch64] Increase TLS alignment to reserve space for Android's TCB.

Android/Bionic currently doesn't have ELF TLS support, so no existing binaries are affected. I'm working on adding support for ELF TLS to Android, but Android's existing use of the thread pointer conflicts with the ordinary ELF TLS ABI.

Oct 30 2018, 4:45 PM · Restricted Project
rprichard added reviewers for D53906: [ARM][AArch64] Increase TLS alignment to reserve space for Android's TCB: ruiu, aivchenk, kristof.beyls, peter.smith, srhines.

I'm currently planning to use a 16-word TCB layout on all architectures for Android, but I'm not completely committed to that yet. This patch can accommodate a larger TCB. I'm also considering using a variant 2 layout instead, which would reuse some of this patch, but would require additional work to accommodate negative offsets on arm64.

Oct 30 2018, 4:31 PM · Restricted Project
rprichard added reviewers for D53905: [ELF] Refactor per-target TLS layout configuration. NFC.: ruiu, PkmX, jrtc27.

This change would make it possible to model RISC-V TLS without the (Config->EMachine == EM_RISCV) special case in https://reviews.llvm.org/D39324 (InputSection.cpp). RISC-V expects a fixed offset of 0.

Oct 30 2018, 3:36 PM
rprichard added a parent revision for D53906: [ARM][AArch64] Increase TLS alignment to reserve space for Android's TCB: D53905: [ELF] Refactor per-target TLS layout configuration. NFC..
Oct 30 2018, 3:23 PM · Restricted Project
rprichard added a child revision for D53905: [ELF] Refactor per-target TLS layout configuration. NFC.: D53906: [ARM][AArch64] Increase TLS alignment to reserve space for Android's TCB.
Oct 30 2018, 3:23 PM
rprichard added a parent revision for D53905: [ELF] Refactor per-target TLS layout configuration. NFC.: D53904: [ELF] Define PT_ANDROID_TLS_TPOFF.
Oct 30 2018, 3:23 PM
rprichard added a child revision for D53904: [ELF] Define PT_ANDROID_TLS_TPOFF: D53905: [ELF] Refactor per-target TLS layout configuration. NFC..
Oct 30 2018, 3:23 PM · Restricted Project
rprichard created D53906: [ARM][AArch64] Increase TLS alignment to reserve space for Android's TCB.
Oct 30 2018, 3:21 PM · Restricted Project
rprichard created D53904: [ELF] Define PT_ANDROID_TLS_TPOFF.
Oct 30 2018, 3:18 PM · Restricted Project
rprichard created D53905: [ELF] Refactor per-target TLS layout configuration. NFC..
Oct 30 2018, 3:18 PM

Oct 26 2018

rprichard committed rL345436: [llvm-readobj] Fix bugs with unrecognized types in switch statements.
[llvm-readobj] Fix bugs with unrecognized types in switch statements
Oct 26 2018, 4:04 PM
rprichard closed D53730: [llvm-readobj] Fix bugs with unrecognized types in switch statements.
Oct 26 2018, 4:04 PM

Oct 25 2018

rprichard added reviewers for D53730: [llvm-readobj] Fix bugs with unrecognized types in switch statements: pcc, grimar.
Oct 25 2018, 2:12 PM
rprichard retitled D53730: [llvm-readobj] Fix bugs with unrecognized types in switch statements from [llvm-readobj] Fix minor segment type dumping bugs to [llvm-readobj] Fix bugs with unrecognized types in switch statements.
Oct 25 2018, 2:09 PM
rprichard added a comment to D53730: [llvm-readobj] Fix bugs with unrecognized types in switch statements.

I didn't see a good way to write a regression test. I tested it by hand with this script:

Oct 25 2018, 1:59 PM
rprichard created D53730: [llvm-readobj] Fix bugs with unrecognized types in switch statements.
Oct 25 2018, 1:54 PM

Oct 8 2018

rprichard added a comment to D53003: [ELF] Fix link failure with Android compressed relocation support..

Adding zero padding to the end of the SHT_ANDROID_REL[A] section shouldn't be a problem. It looks like the original Android relocation_packer tool left up to a page of zero bytes at the end of the packed section, and the decoders in Bionic and LLVM would ignore the trailing bytes. relocation_packer doesn't loop stabilizing SLEB sizes, but I think it didn't need to. When it shrunk a .rel[a].dyn section, it apparently only shrunk the section by a multiple of the page size. It left the virtual addresses of the sections following .rel[a].dyn unchanged, and I don't think it adjusted the offset/addend values of the relocations.

Oct 8 2018, 6:20 PM

Sep 26 2018

rprichard committed rL343145: Allow later -z name=<int> args to override earlier args.
Allow later -z name=<int> args to override earlier args
Sep 26 2018, 1:52 PM
rprichard committed rLLD343145: Allow later -z name=<int> args to override earlier args.
Allow later -z name=<int> args to override earlier args
Sep 26 2018, 1:52 PM
rprichard committed rL343144: [AArch64] Fix range check of R_AARCH64_TLSLE_ADD_TPREL_HI12.
[AArch64] Fix range check of R_AARCH64_TLSLE_ADD_TPREL_HI12
Sep 26 2018, 1:52 PM
rprichard committed rLLD343144: [AArch64] Fix range check of R_AARCH64_TLSLE_ADD_TPREL_HI12.
[AArch64] Fix range check of R_AARCH64_TLSLE_ADD_TPREL_HI12
Sep 26 2018, 1:52 PM
rprichard closed D52526: Allow later -z name=<int> args to override earlier args.
Sep 26 2018, 1:52 PM
rprichard closed D52525: [AArch64] Fix range check of R_AARCH64_TLSLE_ADD_TPREL_HI12.
Sep 26 2018, 1:52 PM
rprichard closed D52525: [AArch64] Fix range check of R_AARCH64_TLSLE_ADD_TPREL_HI12.
Sep 26 2018, 1:52 PM

Sep 25 2018

rprichard added a comment to D52526: Allow later -z name=<int> args to override earlier args.

I noticed this issue while experimenting with a new -z option, not when using -z max-page-size or -z stack-size.

Sep 25 2018, 6:10 PM
rprichard added a comment to D52525: [AArch64] Fix range check of R_AARCH64_TLSLE_ADD_TPREL_HI12.

For context, I didn't notice this bug because I needed more than 2^23 bytes of TLS LE memory, but because I was experimenting with using a variant 2 TLS layout with Android/AArch64. The standard layout (variant 1 with a 2-word TCB) is a problem because Bionic has allocated some memory that overlaps with the first TLS segment, accessible using TLS LE. In particular, the stack cookie is a problem (see getStackCookieLocation in https://reviews.llvm.org/D18632), because third-party binaries may be assuming a variant-1 incompatible TLS layout.

Sep 25 2018, 6:10 PM
rprichard updated the summary of D52525: [AArch64] Fix range check of R_AARCH64_TLSLE_ADD_TPREL_HI12.
Sep 25 2018, 5:46 PM
rprichard created D52526: Allow later -z name=<int> args to override earlier args.
Sep 25 2018, 5:44 PM
rprichard added reviewers for D52525: [AArch64] Fix range check of R_AARCH64_TLSLE_ADD_TPREL_HI12: ruiu, peter.smith, zatrazz.

The original line was added in https://reviews.llvm.org/rL260677.

Sep 25 2018, 5:41 PM
rprichard created D52525: [AArch64] Fix range check of R_AARCH64_TLSLE_ADD_TPREL_HI12.
Sep 25 2018, 5:31 PM

Sep 19 2018

rprichard accepted D52251: [builtins] Add __emutls_unregister_key function.
Sep 19 2018, 4:42 PM
rprichard added inline comments to D52251: [builtins] Add __emutls_unregister_key function.
Sep 19 2018, 3:38 PM
rprichard added a comment to D50297: Align AArch64 and i386 image base to superpage.

+Ryan in case there is anything here that could affect Bionic loading from these pages.

Sep 19 2018, 12:48 AM

Sep 17 2018

rprichard committed rL342432: [ELF] Set Out::TlsPhdr earlier for encoding packed reloc tables.
[ELF] Set Out::TlsPhdr earlier for encoding packed reloc tables
Sep 17 2018, 5:29 PM
rprichard committed rLLD342432: [ELF] Set Out::TlsPhdr earlier for encoding packed reloc tables.
[ELF] Set Out::TlsPhdr earlier for encoding packed reloc tables
Sep 17 2018, 5:29 PM
rprichard closed D51671: [ELF] Set Out::TlsPhdr earlier for encoding packed reloc tables.
Sep 17 2018, 5:28 PM

Sep 14 2018

rprichard updated the diff for D51671: [ELF] Set Out::TlsPhdr earlier for encoding packed reloc tables.

I removed const from Out::TlsPhdr and added comments.

Sep 14 2018, 9:46 PM

Sep 13 2018

rprichard added a comment to D51671: [ELF] Set Out::TlsPhdr earlier for encoding packed reloc tables.

Ping.

Sep 13 2018, 4:48 PM