This is an archive of the discontinued LLVM Phabricator instance.

[libunwind][Modules] Add unwind_arm_ehabi.h and unwind_itanium.h to the unwind module)
ClosedPublic

Authored by iana on Feb 18 2023, 12:18 AM.

Details

Summary

Add unwind_arm_ehabi.h and unwind_itanium.h to the unwind module and use angle includes to include them.

Diff Detail

Event Timeline

iana created this revision.Feb 18 2023, 12:18 AM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptFeb 18 2023, 12:18 AM
Herald added a reviewer: Restricted Project. · View Herald Transcript
iana requested review of this revision.Feb 18 2023, 12:18 AM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 18 2023, 12:18 AM
ldionne added inline comments.Feb 27 2023, 3:03 PM
libunwind/include/unwind_arm_ehabi.h
16–18

Why is this needed? We only include those after checking #if defined(_LIBUNWIND_ARM_EHABI).

iana added inline comments.Feb 27 2023, 3:12 PM
libunwind/include/unwind_arm_ehabi.h
16–18

The module will build all of its headers, so without these guards you'll get a lot of redeclaration errors between the two unwind_ headers.

It might maybe work to put them in independent modules and mark them as conflicting. I don't really think that's the right thing to do since these two headers are just implementation details for unwind.h.

We could make them textual, but then they don't get put in the pcm which isn't what we want.

We could make them excluded and then one or the other should be pulled into unwind when it builds, but that's a fragile mechanism since some other module could unexpectedly include them. It's also not really what we're trying to do, they should be part of unwind and not really excluded.

So I think the right thing to do is make each of these headers standalone and able to be built in the same module.

ldionne added inline comments.Feb 28 2023, 11:40 AM
libunwind/include/unwind_arm_ehabi.h
16–18

The problem is that this is a general pattern we have in a lot of places. Today, we use headers as a mechanism to (quite textually) separate code into a different physical location. These headers are implementation details and they are never intended to be included directly by the user. I'm not a modules expert, but it looks to me like those are effectively textual headers that are meant to be copy-pasted into unwind.h depending on the API we want to provide. If so, we should make them textual even if that has a negative impact on the generated PCM, since that is the proper semantics of those headers.

iana added inline comments.Mar 2 2023, 4:37 PM
libunwind/include/unwind_arm_ehabi.h
16–18

Err, it would be in the unwind PCM since unwind.h includes it, it just has the potential to get copied into other PCMs. @Bigcheese suggested we make it private textual to prevent that, let me give it a try. I still feel a little icky about making the module behavior differ from textual behavior (modules will emit an error if the unwind_ headers are directly included but textual won't), but it's not so bad.

I guess it's open to interpretation, but I see textual headers as things like assert.h where it's expected that you can include it multiple times with different values of NDEBUG in your code, or for X Macro generator headers. The unwind_ headers don't really fit either of those descriptions which is why I feel like they're a bad fit for textual, especially when it's a relatively small change to make them standalone.

That said, I can be out voted, what's really important to me is these belong to a module. I'll give private textual a try and see if it works out.

iana updated this revision to Diff 504304.Mar 10 2023, 4:48 PM

Make the unwind_ files private textual headers and revert the changes to them.

iana marked 2 inline comments as done.Mar 10 2023, 4:49 PM
iana added inline comments.
libunwind/include/unwind_arm_ehabi.h
16–18

It looks like private textual works.

iana edited the summary of this revision. (Show Details)Mar 10 2023, 4:49 PM
ldionne accepted this revision.Mar 18 2023, 8:50 AM
This revision is now accepted and ready to land.Mar 18 2023, 8:50 AM

Can you please just rebase onto main and re-upload to give this one last CI spin? There's a Windows failure I don't understand. I think it's unrelated but rebasing and running the CI again should confirm that.

iana updated this revision to Diff 506622.Mar 20 2023, 9:28 AM

Rebasing

iana added a comment.Mar 20 2023, 9:43 AM

Can you please just rebase onto main and re-upload to give this one last CI spin? There's a Windows failure I don't understand. I think it's unrelated but rebasing and running the CI again should confirm that.

You got it!

ldionne accepted this revision.Mar 20 2023, 3:11 PM

LGTM, the failures in the libc++ CI are known flakes and the Windows one is a Clangd issue, most likely unrelated.

This revision was landed with ongoing or failed builds.Mar 20 2023, 3:13 PM
This revision was automatically updated to reflect the committed changes.