needed for memmove too

I think with the move to newer C++ standards, some of the missing functionality in C could be replicated (or use the _WIN32 code paths for __CYGWIN__ in more places). I tried that for a bit, but it was pieces like struct sigaction, realpath, and getsid missing, which are very platform-specific.

I think this, and similar recent commits, are causing the shared library builds to fail some tests if this code gets linked into libLLVM.so: https://bugs.llvm.org/show_bug.cgi?id=48181. I assume it might actually a bug in ld (GNU Binutils for Ubuntu 2.34), as I don't understand the linker behavior there?

Thanks for identifying that. I think I can re-land just without that part of the test. It is not essential, I added it just to try to check all of the dwarf-related output.

Ah, okay, yes that is more clearly needing to be fixed. I think I just need to rearrange how that command line option works.

add null test as requested, rebase

If it's too fiddly I don't mind this going in without a test case right now -- I think extra cycles would be just as well spent bringing up / testing JITLink for ELF. We should make sure we don't replicate this issue by using empty strings as sentinels there.

The .cfi_startproc directive is part of the unwind information (eh_frame), and is not debug info, so that seems like a possible bugfix even? I'd expect that observation to be consistent with the goal of this PR, though I didn't see specifically where that pass was being affected in a cursory glance back through the PR.

use helper method

fix test

I think these need to be handled in these places, given how clang emits relocations in .dwarf sections. For some contextual history, this was added as a sentinel for absolute symbols in https://github.com/llvm/llvm-project/commit/ad6d349fbcb2f9ced3c57b5b61231315175bcb47 (and later adjusted in https://github.com/llvm/llvm-project/commit/8f1f87c73487dcb83cf5d6d44b062f1e9796fae6). If I compare readelf --relocations of clang vs. gcc, I see GCC emit a name for these symbols for x86 inside the .dwarf sections, but that clang uses the name NULL, which gets translated there into the empty string.

In my first attempt, I missed that it's intentional we're claiming MMI->hasDebugInfo() if there's information available for DWARF output if using fast-isel, even if we don't need that DebugInfo because the output for it is disabled (CodeView information is still somewhat separate, as my attempt to bring them back in line is what failed the CI testing). Fortunately, that's what tests are for when this change was added in 8763c0c5b7a566d2fe9476259aa346640b0a9deb (https://reviews.llvm.org/D53885). I think this should pass all tests now, as I've now fully removed that part of the change (it passes locally anyways).

Yep, I saw that too. I pushed a revert commit while I wait for the tests locally to rerun and confirm my fix for that.

@rnk I've generalized the API to your suggestion and added a test. Let me know what you think, thanks!

update

Removed NFCI, since as I look back, I think this also enabled optimization of constant structures, and I was misusing the NFCI term

I've removed NFCI, since I ended up changing some of the SVE handling when attempting to rebase it

Makes sense to me

rebase

rebase

clang-format patch

@rnk would you be an appropriate reviewer for this idea and willing to look it over? I see @timurrrr originally created this generalization that I'm proposing exposing (r196288 / 1cd1444449cb68e2091e8f36785403288ebd3326), but that he's not working with the llvm project anymore. Thanks!

rebase

fixing commit diff

rename helper functions to canBeUnquotedInDirective

I'm glad to see this is gone. I was just about to file a bug report that this code used to incur a deadlock risk when unw_step was used from a signal handler since macOS 10.9.0 on x86_64, since Apple had removed the other side of this code circa keymgr-28, so it now had been attempting to call malloc. (I'd observed this deadlock occur in testing, and implemented a work around for it downstream, in https://github.com/JuliaLang/julia/pull/37101/commits/fad04d39d592d8e0fcbfba439e8157f582bbc850#diff-86a37833b03dbe7f0874e30469cb1d46R93-R102)

Does that mean I should commit it there also, or how does that process work?

review

Thanks, that's a great reduction. I'll fix this shortly.

Merged as 19f01a484760d9a29f4f414b30da110dd6550191, e244f86f4dfd9e8982940d09294af522d3809d7f, and 2c7a07b59d5da54eba8e3e030e1cc040a88ecf58

We emit an offset table of the form:

ptrdiff_t symbol_offset = &f2 - &f1;

since we know this should normally be folded to a constant in the object file. This is normally rejected by a C compiler ("error: initializer element is not a compile-time constant", pointing to the f2 symbol) but LLVM accepts it. It used to be handled here (since the difference is a constant known here), though it seems the mingw-w64 linker later corrupts this expression.

I thought about that, but I didn't think it felt like it needed to. If the cwd is readonly, it'll just silently turn itself off.

formatting