- User Since
- Nov 23 2012, 10:16 AM (255 w, 5 d)
Thu, Oct 12
Wed, Oct 4
In that case: the short version is that there is no EABI support at the moment. That patch changes the behavior for SYSV ABI, it is not acceptable as such. The test case doesn't reflect the ABI variance either.
Let's start with the obvious: I have no idea why you need this code at all. NetBSD builds a mix of static, PIC and PIE code using GNU ld without hitting any unsupported relocations. As I said before, the normal ABI on PowerPC is mostly PIC by default. I wonder if the root of your problem is that you want EABI and not the SYSV ABI.
This doesn't look right to me at all. The normal SYSV ABI on PowerPC is effectively PIC, with a few edge cases. This really looks like a step backwards.
Thu, Sep 28
Wed, Sep 20
Well, the background for the use of the option in NetBSD is related to inducted differences in reproducable builds. From that perspective, it is even worth to sometimes shorten the dependency and sometimes not.
Sep 17 2017
ninja is not the only consumer of this. For human inspection, it can be quite surprising to see symlinks resolved, i.e. /usr/include/machine on NetBSD. Build systems have different ideas on whether they want absolute resolved paths or not, so it seems like ninja should be able to cope with either format. This is a lossy transformation, so I'm somewhat reluctant to agree with it.
The comments at the very least are misleading. Resolving the path doesn't necessary shorten the string at all, in many cases it will be longer. I'm really not sure if clang should resolve symlinks like this as it can be quite surprising.
Sep 15 2017
So what about targets that don't support subnormals? I'm moderately sure ARM falls into this category given the right phase of the moon.
Sep 13 2017
I can't really comment on the Linux interface, but we generally ignore the system call error in NetBSD where one is necessary. While aborting might be legal, it seems to be the worst possible way of dealing with questionable arguments.
Sep 12 2017
This version is fine with me. The only contentious part is whether it should be opt-in or opt-out for platforms, so getting this version in and revisiting the issue again later is OK from my perspective.
Sep 8 2017
Create a function that does check the guard variable and make sure that it has the correct visibility declaration and/or access.
Aug 29 2017
Aug 28 2017
Aug 22 2017
Aug 21 2017
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...
Aug 18 2017
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.
Aug 17 2017
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.
Aug 12 2017
@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?
Aug 10 2017
Aug 9 2017
Aug 3 2017
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.
Aug 1 2017
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:
Jul 26 2017
Merging would be reasonable, yes.
Jul 25 2017
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.
Jul 23 2017
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.
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.