Skip to content

[LLDB] Add ifndef to platform linux #141971

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
May 29, 2025
Merged

Conversation

Jlalond
Copy link
Contributor

@Jlalond Jlalond commented May 29, 2025

Another iteration of fixes for #141670. Platform linux can be used by other platforms, so we need to supply the signal values if they're not defined.

Values are from the manpage

@Jlalond Jlalond requested a review from dmpots May 29, 2025 16:11
@Jlalond Jlalond requested a review from JDevlieghere as a code owner May 29, 2025 16:11
@llvmbot llvmbot added the lldb label May 29, 2025
@llvmbot
Copy link
Member

llvmbot commented May 29, 2025

@llvm/pr-subscribers-lldb

Author: Jacob Lalonde (Jlalond)

Changes

Another iteration of fixes for #141670. Platform linux can be used by other platforms, so we need to supply the signal values if they're not defined.


Full diff: https://github.com/llvm/llvm-project/pull/141971.diff

1 Files Affected:

  • (modified) lldb/source/Plugins/Platform/Linux/PlatformLinux.cpp (+14)
diff --git a/lldb/source/Plugins/Platform/Linux/PlatformLinux.cpp b/lldb/source/Plugins/Platform/Linux/PlatformLinux.cpp
index cb60caf1cb422..dd6490c7141e5 100644
--- a/lldb/source/Plugins/Platform/Linux/PlatformLinux.cpp
+++ b/lldb/source/Plugins/Platform/Linux/PlatformLinux.cpp
@@ -34,6 +34,20 @@
 #define MAP_PRIVATE 2
 #define MAP_ANON 0x20
 
+// For other platforms that use platform linux
+#ifndef SIGILL
+#define SIGILL 4
+#endif
+#ifndef SIGBUS
+#define SIGBUS 7
+#endif
+#ifndef SIGFPE
+#define SIGFPE 8
+#endif
+#ifndef SIGSEGV
+#define SIGSEGV 11
+#endif
+
 using namespace lldb;
 using namespace lldb_private;
 using namespace lldb_private::platform_linux;

Copy link
Contributor

@dmpots dmpots left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approving to unblock windows build break.

@@ -34,6 +34,20 @@
#define MAP_PRIVATE 2
#define MAP_ANON 0x20

// For other platforms that use platform linux
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are these guaranteed to be defines and not constants?

#define SIGFPE 8
#endif
#ifndef SIGSEGV
#define SIGSEGV 11
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You mentioned offline that we define these somewhere else as well? Would be good to have a cleanup to unify them into a single header I think.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They're all defined in signal.h, but we can build this class on a platform that won't have access to signal.h, so we need to ensure they're defined.

@Jlalond
Copy link
Contributor Author

Jlalond commented May 29, 2025

I'm going to wait to see how many build issues we get before landing.

@labath
Copy link
Collaborator

labath commented May 29, 2025

Ummm... I should have caught this before, but this isn't correct because the host system may (and some do) use different signal numbers for these constants.

So, on windows, you get an undefined symbol error, but on e.g. macos, you'd just get a wrong value. You should take these values from the UnixSignals object.

@Jlalond
Copy link
Contributor Author

Jlalond commented May 29, 2025

Ummm... I should have caught this before, but this isn't correct because the host system may (and some do) use different signal numbers for these constants.

Are these actually different on Mac? These 4 are the same on BSD to my knowledge.

How do you think we should go about getting the value from UnixSignals?

Edit: BSD Man page, same values for SIGILL/BUS/FPE/SEGV.

We might want to make a follow up to clean this up but this should unblock the build.

I'm not sure how Linux Signals is building actually, but it appears to have built successfully

@Jlalond
Copy link
Contributor Author

Jlalond commented May 29, 2025

@labath I'm landing to not leave the build broken, but if you have a better solution/means of doing this let me know and I'll implement it

@Jlalond Jlalond merged commit 159646c into llvm:main May 29, 2025
12 checks passed
@Jlalond
Copy link
Contributor Author

Jlalond commented May 29, 2025

https://lab.llvm.org/buildbot/#/builders/197/builds/6014 looks like we're passing

@labath
Copy link
Collaborator

labath commented May 29, 2025

Are these actually different on Mac? These 4 are the same on BSD to my knowledge.

I haven't checked, I guess these four might be the same on a mac, but that definitely is not the case everywhere. We're currently growing AIX support, and that one seems to have different numbers: https://www.ibm.com/docs/en/sdk-java-technology/8?topic=reference-signal-handling. According to the linux manpage, the values can vary even across linux different architectures.

I'm not sure how Linux Signals is building actually, but it appears to have built successfully

Uses some macro trickery. We provide the symbolic constant and the value. We always use the constant value, but on linux, the macro also expands to a static_assert which checks that our constant matches what the system headers say.

@labath I'm landing to not leave the build broken, but if you have a better solution/means of doing this let me know and I'll implement it

You should be able to get the UnixSignals object from the thread (->GetProces()->GetUnixSignals()). Then, instead of the symbolic constant (e.g. SIGSEGV), you compare the signal number to value from that object (signals->GetSignalNumberFromName("SIGSEGV")).

svkeerthy pushed a commit that referenced this pull request May 29, 2025
Another iteration of fixes for #141670. Platform linux can be used by
other platforms, so we need to supply the signal values if they're not
defined.

Values are from the
[manpage](https://man7.org/linux/man-pages/man7/signal.7.html)
google-yfyang pushed a commit to google-yfyang/llvm-project that referenced this pull request May 29, 2025
Another iteration of fixes for llvm#141670. Platform linux can be used by
other platforms, so we need to supply the signal values if they're not
defined.

Values are from the
[manpage](https://man7.org/linux/man-pages/man7/signal.7.html)
sivan-shani pushed a commit to sivan-shani/llvm-project that referenced this pull request Jun 3, 2025
Another iteration of fixes for llvm#141670. Platform linux can be used by
other platforms, so we need to supply the signal values if they're not
defined.

Values are from the
[manpage](https://man7.org/linux/man-pages/man7/signal.7.html)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants