Page MenuHomePhabricator

dalias (Rich Felker)
User

Projects

User does not belong to any projects.

User Details

User Since
Nov 16 2015, 7:50 PM (199 w, 6 d)

Recent Activity

Mon, Sep 9

dalias added a comment to D65699: [Driver] Prioritize SYSROOT/usr/include over RESOURCE_DIR/include on linux-musl.

That's a separate issue of clang having a slight types-ABI mismatch with some 32-bit archs whose original ABIs used long instead of int for wchar_t. The wrong header order makes it quickly apparent, but these are independent; wrong header order is still wrong and will break (other) things even without this type mismatch. Backport of the fix would be much appreciated.

Mon, Sep 9, 4:46 AM · Restricted Project, Restricted Project

Aug 5 2019

dalias added a comment to D65699: [Driver] Prioritize SYSROOT/usr/include over RESOURCE_DIR/include on linux-musl.

It's not just infeasible; it's impossible by design. musl's headers do not support any contract with compiler-provided versions of the std headers, and won't. Attempting to use them in place of the libc ones is unsupported usage and will periodically break.

Aug 5 2019, 2:59 PM · Restricted Project, Restricted Project

Aug 4 2019

dalias added a comment to D65699: [Driver] Prioritize SYSROOT/usr/include over RESOURCE_DIR/include on linux-musl.

Just chiming in to confirm that the requested change is correct for musl. musl does not support use/mixing of compiler-provided std headers with its headers, and intentionally has no mechanism for communicating with such headers as to which types have already been defined or still need to be defined. If the current include order, with clang's headers before the libc ones, works in some situations, it's only by accident.

Aug 4 2019, 7:18 PM · Restricted Project, Restricted Project

Jul 7 2019

dalias added a comment to D62106: [X86] Support -fno-plt __tls_get_addr calls.

Have you checked what gcc does? It should be safe to do the same, no? Or is the issue that gcc leaves it to gas, and it's reasonably assumed that gas and ld.bfd versions will match, whereas clang uses an internal assembler that might not match?

Jul 7 2019, 5:20 PM · Restricted Project

Jun 29 2019

dalias added a comment to D63785: Add support for MUSL libc.

I second the question, especially since I'm pretty sure that everything the existing asan code here is doing that makes it "work" on musl is poking at implementation internals that are not public interfaces and have no reason to continue "working" however they are now. A long time ago the question was raised of whether/how libcs could provide mechanisms for sanitizers to work, but the ideas I saw at the time were based on hooks, which we didn't consider reasonable from the musl side - as soon as hooks are offered as stable API, they WILL be used not just by sanitizers but by applications.

Jun 29 2019, 10:10 AM · Restricted Project, Restricted Project

Jun 11 2019

dalias added a comment to D63132: [ELF][RISCV] Create dummy .sdata for __global_pointer$ if .sdata does not exist.

I don't immediately see any problem with adding a dummy .sdata, though I think the linker should probably also be able to do this. defining a dummy __global_pointer with SHN_ABS makes no sense. The bfd linker doing this looks like a bug to me, and the bfd linker failing to produce an error when linking it looks like another bug.

Jun 11 2019, 7:59 AM · Restricted Project

May 22 2019

dalias added a comment to D62106: [X86] Support -fno-plt __tls_get_addr calls.

I'm not sure how LLVM internals work, but if it's anything like GCC's, I think you just need to make it take a register operand for the GOT address as an input/operand. Then the higher-level code should ensure it's available, and then you just use it in the code emitted. Touching higher-level code shouldn't be needed.

May 22 2019, 7:58 AM · Restricted Project

May 19 2019

dalias added a comment to D62106: [X86] Support -fno-plt __tls_get_addr calls.

Hardcoding ebx defeats most of the purpose of no-plt, which was motivated by: https://ewontfix.com/18/

May 19 2019, 11:36 PM · Restricted Project

May 17 2019

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

I'm not sure if/where it's documented, but the congruence requirement is the only reasonable interpretation of p_align. We're fixing it in musl according to this interpretation.

May 17 2019, 7:22 PM · Restricted Project
dalias 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.

May 17 2019, 9:55 AM · Restricted Project

May 15 2019

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

I do not see how .tdata happening to be the first thing in the LOAD segment is relevant or helpful at all. Any "accidental alignment" as a result of that is not part of the alignment that will affect the runtime addresses of TLS objects.

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

Also, I think the description "make glibc happy" is possibly wrong. It looks like, while musl and some other implementations work with the current hack in LLD, it's only due to a bug that they work. The real problem is that the hack is emitting bad ELF.

May 15 2019, 7:57 AM · Restricted Project

Aug 27 2018

dalias added a comment to D51282: Disable calls to *_finite and other glibc-only functions on Musl..

I'm reasonably happy as long as this is fixed, but I would really rather see the logic reversed: rather than special casing each !glibc, all of these nonstandard functions should be enabled only if(T.isGlibc) to begin with.

Aug 27 2018, 6:39 AM

Nov 7 2017

dalias added a comment to D39700: [Builtins] Do not use tailcall for Thumb1.

This commit in musl has details on why calling memset, etc. doesn't work and violates the ABI:

Nov 7 2017, 3:16 PM
dalias added a comment to D39700: [Builtins] Do not use tailcall for Thumb1.

Looking further at this, it looks like your current implementations of the __aeabi_* functions are simply wrong - they clobber registers that the ABI does not allow them to clobber.

Nov 7 2017, 2:56 PM
dalias added a comment to D39700: [Builtins] Do not use tailcall for Thumb1.

In musl we do not define the __aeabi_* functions for the sake of having optimized implementations but simply for ABI conformance. They are specifically and intentionally NOT optimized since their ABIs (special rules about which registers they don't clobber) preclude writing them in C, and also make it hard to do the potentially-more-worthwhile optimizations like vectorization (since you don't have vector scratch registers). With this in mind, I would strongly recommend against ever generating calls to them. Our view on the musl side is that they exist just for minimal (i.e. non-performance) ABI compat with code that might have been compiled with a legacy compiler making use of them.

Nov 7 2017, 2:07 PM

Nov 17 2015

dalias added a comment to rL252457: Add initial support for the MUSL C library..

Are you sure you'd have to wrap all of them? Most of the "xlocale" functions are just standard functions that are in locale.h since POSIX 2008. Only a few are nonstandard. Of course from a practical standpoint it should work to start out just testing the ones you've observed missing on some systems, then add more later as needed.

Nov 17 2015, 7:14 AM

Nov 16 2015

dalias added a comment to rL252457: Add initial support for the MUSL C library..

I realize your build system might not be setup to deal with this situation any better, so if so, I apologize in advance for the noise. Much of this patch, however, is exactly the reason why musl does not provide a __MUSL__ macro (see the musl FAQ): in short, these hard-coded assumptions about what functions musl does not have will break the build if/when musl adds them. The right way, from our perspective, to do this would be with build-time detection for nonstandard functions like strtoll_l. By unconditionally defining them as static-inline when targeting musl, the build will break if musl's locale.h ever adds a declaration for an extern version.

Nov 16 2015, 7:59 PM