Page MenuHomePhabricator

nsz (Szabolcs Nagy)
User

Projects

User does not belong to any projects.

User Details

User Since
Jan 9 2018, 8:54 AM (88 w, 6 d)

Recent Activity

Jul 24 2019

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

Will be worth mentioning that this is dependent on D64906 and D64903, I could guess at D64903 but basic-aarch64.s didn't apply cleanly without D64903. I successfully did a 2 stage bootstrap of clang with ninja check-all on a native aarch64 machine and made a quick test to check the TP relative relocation. I struggled a bit to understand the description and the comments though. In particular the use of GAP_ABOVE_TP instead of TCB_SIZE, it also wasn't clear where the alignment calculation had come from. I've made a few suggestions.

Jul 24 2019, 2:14 AM · Restricted Project

Jul 17 2019

nsz added a comment to D63863: [ARM] Make coprocessor number restrictions consistent..

Would some kind of architectural extension be a reasonable solution? -march=armv8+oldcoprocessors, or some such? That way -march=armv8 continues to diagnose things that actually are illegal in the architecture you asked for.

Jul 17 2019, 6:13 AM · Restricted Project
nsz added a comment to D63863: [ARM] Make coprocessor number restrictions consistent..

Hmmm. This surely can't be the first time a case like this has come up. What's the usual solution in other similar situations, when you want to include code for mutually incompatible architectures in the same object because you're going to test at run time which one to execute?

Jul 17 2019, 1:53 AM · Restricted Project

May 15 2019

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

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...)
May 15 2019, 4:29 AM · Restricted Project

May 13 2019

Herald added a project to D53906: [ARM][AArch64] Increase TLS alignment to reserve space for Android's TCB: Restricted Project.

i think this should be fixed in the tools/runtimes that assume fixed tls offset abi that conflict with the elf tls abi.

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

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 13 2019, 8:48 AM · Restricted Project

Jan 26 2018

nsz added inline comments to D40134: [asan] Add support for AArch64 ILP32.
Jan 26 2018, 8:05 AM · Restricted Project

Jan 12 2018

nsz added a comment to D40673: Add _Float128 as alias to __float128 to enable compilations on Fedora27/glibc2-26.

as this patch is committed clang is broken (cannot use glibc headers)

This patch was supposed to *fix* compatibility with the glibc headers. If it doesn't, we should clearly revert it... but we need to figure out what we need to do to be compatible first.

From what I can see on this thread, we *must* define _Float128 on x86-64 Linux, and we *must not* define _Float128 for any other glibc target. Is that correct? Or does it depend on the glibc version?

Jan 12 2018, 12:18 PM · Restricted Project

Jan 11 2018

nsz added a comment to D40673: Add _Float128 as alias to __float128 to enable compilations on Fedora27/glibc2-26.

also note that there is less than 3 weeks until glibc-2.27 is released, if the headers need a fix for clang then say so quickly

Jan 11 2018, 3:24 AM · Restricted Project
nsz added a comment to D40673: Add _Float128 as alias to __float128 to enable compilations on Fedora27/glibc2-26.

if clang wants to provide _Float128 then the f128 constant suffix (specified by TS18661-3) and builtin_inff128, builtin_nanf128, builtin_nansf128, builtin_huge_valf128 (gcc builtins required by math.h) need to be supported too.

Jan 11 2018, 3:13 AM · Restricted Project