- User Since
- Nov 16 2015, 7:50 PM (199 w, 6 d)
Mon, Sep 9
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.
Aug 5 2019
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 4 2019
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.
Jul 7 2019
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?
Jun 29 2019
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 11 2019
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.
May 22 2019
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 19 2019
Hardcoding ebx defeats most of the purpose of no-plt, which was motivated by: https://ewontfix.com/18/
May 17 2019
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.
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 15 2019
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.
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.
Aug 27 2018
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.
Nov 7 2017
This commit in musl has details on why calling memset, etc. doesn't work and violates the ABI:
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.
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 17 2015
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 16 2015
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.