- User Since
- Nov 23 2012, 10:16 AM (247 w, 4 d)
Well, the libexecinfo one exists as fallback because gcc doesn't provide one.
Kamil, which unwind.h are you using? The outdated copy in libexecinfo.h or the modern one used by libunwind? I see little reason to cater to the bugs in the former...
Fri, Aug 18
BTW, I recently spend some time slapping GNU ld in NetBSD into shape so that it can properly support read-only .eh_frame even on MIPS. You might want to look at adopting similar changes.
Thu, Aug 17
divtc3 and friends.
Because PPC uses the TC variant.
Just assume that the full 32bit address space is available.
The primary reason for using mmap is not so much performance, but reduced memory foot print.
Sat, Aug 12
@spatel: I don't see a reason why we can't (or shouldn't) try to do common-prefix elimination for the memcmp intrinsic. It certainly seems to be better to me to preserve the intrinsics in your case as they should be easier to reason about. That's kind of my question for here too -- why does the expansion allow better code?
What is the advantage of expanding the memcpy intrinsic in InstCombine vs doing it later in the target-specific code?
Thu, Aug 10
Wed, Aug 9
Thu, Aug 3
I don't see any reason why zero-initialised constants should be emitted in BSS. I know that GCC does that and I just fixed bugs in that because created wrong section flags for it. So yes, I'd prefer to revert this and fix the real problem.
I'm not sure I want anything like this unconditionally. It is going to waste quite a bit of space, i.e. 2KB per executable and shared library sums up.
Tue, Aug 1
I had a long discussion with James about this on IRC without reaching a clear consensus. I consider forcing this behavior on all targets to be a major bug. It should be opt-in and opt-in only:
Wed, Jul 26
Merging would be reasonable, yes.
Tue, Jul 25
Warning for .ctor/.dtor use would IMO be completely bogus. They can easily be translated and they are kind of the LCD for "portable" assembler, i.e. much less problematic to deal with than plain .init/.fini segments.
Sun, Jul 23
I don't really like this. The reason why -lm is added explicitly on many targets is because the C++ STL typically depends on it and that means for static linking and broken ELF linkers, it will be necessary to link against it explicitly.
There is also the question on whether any platform we have currently uses separate STL and ABI libraries and it is not clear whether the flag should handle both.
Jul 23 2017
While more localized, this seems to be an even greater hack than adopting the JIT users to use AllocateRWXMemory.
Jul 21 2017
Jul 20 2017
Keep in mind that the SELinux case in libffi is not fork-safe. One important part LLVM needs to consider is
whether it wants to enshrine the performance penalty of mprotect-after-commit in its APIs or not. The second part
is whether platforms should aim to support hot-patchable JIT for multi-threaded environments or not. If the latter is
not considered relevant, the API only needs to provide a function to allocate JIT-safe memory and a function to make
it executable. If the latter is relevant, the current AllocateRWX is the interface you will end up with, one way or the other.
Jul 19 2017
Jul 18 2017
i386: code requires three push instructions + call + potential stack cleanup.
x86_64: code requires three register loads + call
This doesn't make sense to me, both the existing and new code. off_t is a signed type.
Jul 16 2017
Please mark it as alias for -nopie, otherwise fine.
Jul 12 2017
What if the constexpr function is called with in a non-constexpr context, e.g. with a random global variable as argument?
Jul 11 2017
Strictly speaking, I think this comes from csh, but LGTM.
A better construct would be to compute the full length and change both it and Str in the loop. No point in the complex arithmetic. I generally do prefer this as it improves interaction with pipes etc.
Jul 10 2017
Jul 6 2017
If you want to go this way, rename them consistently and use a different prefix (e.g. AUXV_*) please.
LGTM, as Kamil said, we have the same change in pkgsrc for Illumos.
The bigger question for me is: what depends on the RTLD_GLOBAL behavior? I generally consider using it a design bug. I.e. what breaks if we just change to RTLD_LOCAL?
Jul 1 2017
Lock-free atomic operations are also signal safe. Your code is not. While I don't know whether all this functions are not required to be signal safe, the general assertion is certainly questionable.
Jun 30 2017
LGTM, but please cut down the test cases by hand. Most of the attributes and module flags should be unnecessary.
Jun 29 2017
As I said in the discussion about similar flags for GVN, I'm generally fine with. We should have a big fat warning in the Release Notes that all -fexperimental-* flags are exactly that -- temporary and not intended for long term consumption. I.e. "we can and will remove them whenever it creates the most havoc".
Jun 22 2017
Do you need someone to commit this?
I don't think it is a good idea to make this function non-transitive.
It would be nice to make the stackprobesize a proper TLI attribute, so that OSes can decide how much guarding they are willing to guarantee. I think I would also like to have an option to inline the probing without the complexity of the function call. But both can be done as a separate step.
Jun 21 2017
If the jump table is writable, you can just use the absolute pointers, PIC or no PIC. That would be the "block address" encoding.
Jun 20 2017
If you want to create a stop-gap solution that bad, I would make it emit the jump table as writable for non-PIC && largeish code model. That's a much more contained change. It would be really better to work on the real fix and not add more hacks...
For some reason we are using large code model with PIC in the JIT and this is the only issue I see on x86-64 so far.
The x86_64 code is mixed: it is correct for non-PIC but large, it doesn't work correctly for PIC. That covers the cases most people have been interested in, especially since large model and PIC runs into various other issues too from what I remember.
At least the PPC change is definitely wrong. AArch64 should be wrong as well from what I discussed with Tim.
What about the old TODO item of extending powi to integer types and folding them together in the middle end?
Jun 19 2017
Not parsers, encoders. Note that the escaping is not correct for control characters other than \n.
I don't disagree with you, but please see the referenced review for further details.
Jun 18 2017
My suggestion would be to just use the YAML writer for now and leave a comment to make it clear that this is really JSON only.
Jun 17 2017
Please see the discussion in D31992. This patch seems to go in the wrong direction.
As I said, I don't see the point in pretending we support float128 when the runtime doesn't contain the necessary pieces.
Jun 14 2017
Jun 13 2017
Jun 11 2017
This fixes the problem in mbedtls, thanks.
Jun 8 2017
Soft-float on the runtime environment part. I.e. non-trivial operations are lowered to library calls.
At the very least, missing test case.
Jun 7 2017
Actually, for NetBSD we want to use -fomit-frame-pointer by default whenever the implicit -funwind-tables is also present. In general, that should be the justification for the default behavior: "Can I reliably unwind a binary with the available information?" Performance of stack unwinding is IMO secondary and users of sanitizers can disable it where necessary.
Jun 6 2017
Given that W^X is becoming a lot more popular across systems including SELinux and other variants, I think it would be better to extend MemoryBlock to store separate pointers for W and X mappings. That avoids the complexity of storing the pointer directly in the allocation.
Jun 1 2017
A small subset can be found by searching for LINKER_RPATH_FLAG in pkgsrc. A classic offender is Emacs. For more, I would have to systematically search.
May 31 2017
sysroot is already handled in NetBSD.cpp line 118 or so.
Such knowledge is necessary anyway. There is enough software that wants to use the linker directly.
I'm against it. I consider this a strong bug on the LLD side and the behavior of clang correct.
May 29 2017
May 21 2017
Strictly speaking, the glibc attribute violates the specification of const. I.e. we could turn a call for pthread_self() into a once() initialised static variable and that transform would be valid under the const rules. That clearly doesn't reflect the intention...
May 20 2017
May 19 2017
May 18 2017
I find the use of "must" at the very least inappropriate. If there was no use case for not including it, it wouldn't be an option. There is also nothing really Android-specific here beside maybe the open64 mess.
Can this use ErrorOr?
May 17 2017
Lock-free operations provide two major advantages. You don't need to worry about signal safety and they can be mixed with certain non-atomic operations without creating havoc. All I said is that the presence of a 32bit CAS is enough to ensure lock-free atomic operations for (appropriately aligned) 8bit and 16bit values can be implemented. That will not be worse than any locked atomic operation on any non-brain-dead platform. E.g. it might not be true on SPARC v7 and v8 or the VAX, but then they don't have a 32bit CAS. It doesn't mean that you have to implement 16bit atomics using a 32bit CAS. I would hope the webassembly backend exposes atomics as precise operations, but if it only provides a 32bit CAS, that's still good enough for the needs of any frontend language.
May 16 2017
While I fully agree that the current fallback-to-GCC behavior is far from helpful, I'm not sure how much sense providing linker support for bare-metal makes. I would expect this to changes wildly depending on the specific environment.
I don't get this. If you have a lock-free 32bit CAS, you can implement all the 16bit operations on top of that and they are still lock-free.
May 15 2017
Can you check the countable part in one of the cases? Otherwise it looks good.
May 10 2017
At least NetBSD doesn't support/use DF_TEXTREL and only DT_TEXTREL.
It's actually more a diagnostic hint. Due to things like Nvidia's binary-only libGL, this is actually supported by most TLS implementations as long as no initializers are needed.