- User Since
- Dec 9 2012, 11:41 PM (266 w, 5 d)
context + comment
Can we avoid the _WIN32 usage please? We spent some effort to avoid it, and have _LIBCPP_WIN32API to indicate that we want the Win32 API. I know that Marshall had some strong opinions on avoiding the _WIN32 usage, but, beyond that, I think that this is a completely reasonable thing to provide. I'm still torn if we should enable this on not _LIBCPP_ABI_MICROSOFT. One other option would be to have a _LIBCPP_MS_EXTENSIONS flag to control whether they are provided. But, all of that is merely details on how to control access to the interfaces, not the direction itself.
Took a bit of reading to realize that the compiler is being set to clang, and therefore CMAKE_ASM_COMPILER_ID should be Clang.
What is the motivation for this change? If you are trying to enable this for MinGW, that is fine, but I'm not sure if we should try to catch the VLA issues in the frontend. I believe that on x86_64, we also disallow the VLAs as Microsoft does not permit them there, but @rnk can correct me if I'm wrong on that.
Thu, Jan 18
Can you add a test case to ensure that it still triggers for non-dllexport cases with this target?
Wed, Jan 17
rebase and emit one entry per line
Awesome; I was thinking about doing that as a follow up. I'll hoist this into that new layer. Completely agree on the fixing the emission after this infrastructure is in place. I can't believe that we never implemented this.
Mon, Jan 8
Yeah, we should be using symlinks on the unix hosts. This fixes an issue in cross-compiling, LGTM.
Thanks for splitting this up!
This needs to be coordinated with D41706.
This seems fine, but will need D41673 to go in at the same time. The sanitizers are pretty tightly coupled with the compiler, so I don't think that it is too big of a deal, but it may be nice to have a more robust upgrade path.
Sat, Jan 6
Fri, Jan 5
Thu, Jan 4
Looking over this patch again, I think I really would prefer that this was split up into two patches. The first one should be entirely mechanical, replacing n64 with newabi. The second patch would actually make the changes that you are are after. That would really help with focusing what the issue here actually is. I don't see anything technically that is an issue (I admit I didn't verify the sizes, but the assertions should hopefully catch that). Beyond that split up, Id like to get a signoff from @sdardis for the MIPS specific bits, but from the libunwind side, LGTM.
Wed, Jan 3
Fri, Dec 29
Similar to the libc++abi and libc++ changes.
Similar to the libc++abi wrt find_path. The CMAKE_REQUIRED_FLAGS handling LGTM.
I think that it might be better to handle this as a single global change:
Mon, Dec 25
Cn you add a roundtrip test through yaml2obj/obj2yaml and a test for the COFF dumper?
Sun, Dec 24
Dec 20 2017
Dec 19 2017
Please do add the docs that the large code model behavior is an extension.
Bah, I forgot that __chkstk is special and the normal preserved/clobbered register set is not the same.
We have tests for the dyld bits in the tree already. You should be able to use that for inspiration for writing the tests. They are in test/ExecutionEngine/RuntimeDyld/<ARCH>
Address @jhenderson's suggestions.
Dec 18 2017
Address @ruiu's comments
Address various comments, fix test
Dec 16 2017
ARM ELF has an additional field that indicates the PCS used. With the frontend validating the input, wouldn't we be sure that each object file is valid. If there is a mismatch in the PCS, that should already be an error from the linker. Wouldn't the LTO case be handled similarly?
Dec 15 2017
Dec 14 2017
This is awesome!
Dec 13 2017
It would be good to straighten out the corner case of the canonicalized vs specified triple before merging this as that would make it harder to change.
Yes, gABI specifies pointer sized alignment, but that is not what currently occurs. Everything is 4-byte aligned due to a mis-interpretation of the specification long ago, and now it has fossilized into the reality (yay for compatibility!).
Dec 12 2017
@ruiu, that explicitly has the problem that Im trying to avoid: having to modify the compiler for any new option.
I was thinking more along the lines of #pragma comment(linker, "-liberty").
I don't think that parsing the options on the LLVM side is a good idea. What if the linker uses a non-GNU style driver? What if there are multiple ways of specifying the option (joined vs separate)? This is something that really should be pushed further down. Can you even do -l library with the GNU driver?
Add llvm-readobj decoding support, tweak the structure layout a bit.
@ruiu I had the same concern and thats why I am doing one option per C-style string with an array that is null terminated to represent the options. If there are options with spaces they will be a string onto themselves. That is in the test itself (two options: "spaced option" and "nospace").
Dec 11 2017
Ah, my concern is in keeping the handling in the compiler agnostic. I don't mind discussing the aspects of the options. I think that the two options that really matter are -L and -l. I think that adjusting the linker search path should apply to all future library searches. For the -l, the ideal location would be after the object itself. But, I don't think that should really gate this infrastructure level support.
Address implementation details pointed out by @jakehehrlich
It also means that it is harder to add features in the future for things which may not yet exist. As an example, there is no equivalent to this option today, but it would be pretty nice to have: -reexport-l<ibrary>. This would be equivalent to forwarders in COFF and LC_REEXPORT in the MachO. There is no ELF equivalent, but, were we to add that to the linker, this would now require changing the entire toolchain rather than forwarding the one single option.
Sure, the intent is that only a subset of features would be used. But, controlling which subset of the features shouldn't be limited in the implementation I think. This is mostly meant to serve as a means for adding equivalent functionality for linking that exists elsewhere. Im thinking of things like library search paths and linked libraries are generally pretty useful to be able to embed in a static library (as well as objects). One place where this would be immediately useful would be swift and Linux where currently the linker directives are added into a special section, a special tool will then post-process object files to extract and construct response files to pass along the options. All of this seems unnecessary and bulky when all the other object files support a clean way to support this.
Dec 8 2017
I really wish that we had some way to indicate that this is a LLVM extension.
Dec 6 2017
LGTM if @sdardis is good with it
This could be embedded within the note structure. Because we want this section to be discarded by default, having a PROGBITS section seems like a bad idea to me, but if someone else has a better way to accomplish this, I'm not tied to this.
Dec 5 2017
I'm okay with this change in principle, but Im worried that this may break the buildbots. Please ensure that they remain green after this change.
Dec 4 2017
Dec 3 2017
Looks like a carry-over from the autoconf conversion (where it is used to deal with a posix sh limitation.
Please add a MachO test as this enables emulated TLS on MachO as well.
Please add a test case with emulated TLS on Darwin as -femulated-tls will now lower with emulated TLS on Darwin too.