Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[LLVM][Cygwin] Fix Signals compatibility with Cygwin API #138117

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 2, 2025

Conversation

mati865
Copy link
Contributor

@mati865 mati865 commented May 1, 2025

Cygwin types sometimes do not match Linux exactly. Like in this case:

In file included from /h/projects/llvm-project/llvm/include/llvm/Support/Error.h:23,
                 from /h/projects/llvm-project/llvm/include/llvm/Support/FileSystem.h:34,
                 from /h/projects/llvm-project/llvm/lib/Support/Signals.cpp:22:
/h/projects/llvm-project/llvm/include/llvm/Support/Format.h: In instantiation of ‘llvm::format_object<Ts>::format_object(const char*, const Ts& ...) [with Ts = {int, char [4096]}]’:
/h/projects/llvm-project/llvm/include/llvm/Support/Format.h:126:10:   required from ‘llvm::format_object<Ts ...> llvm::format(const char*, const Ts& ...) [with Ts = {int, char [4096]}]’
/h/projects/llvm-project/llvm/lib/Support/Unix/Signals.inc:850:19:   required from here
/h/projects/llvm-project/llvm/include/llvm/Support/Format.h:106:34: error: no matching function for call to ‘std::tuple<int, char [4096]>::tuple(const int&, const char [4096])’
  106 |       : format_object_base(fmt), Vals(vals...) {
      |                                  ^~~~~~~~~~~~~

Casting here is safe and solves the issue.

Split out from #134494

Cygwin types sometimes do not match Linux exactly. Like in this case:
```
In file included from /h/projects/llvm-project/llvm/include/llvm/Support/Error.h:23,
                 from /h/projects/llvm-project/llvm/include/llvm/Support/FileSystem.h:34,
                 from /h/projects/llvm-project/llvm/lib/Support/Signals.cpp:22:
/h/projects/llvm-project/llvm/include/llvm/Support/Format.h: In instantiation of ‘llvm::format_object<Ts>::format_object(const char*, const Ts& ...) [with Ts = {int, char [4096]}]’:
/h/projects/llvm-project/llvm/include/llvm/Support/Format.h:126:10:   required from ‘llvm::format_object<Ts ...> llvm::format(const char*, const Ts& ...) [with Ts = {int, char [4096]}]’
/h/projects/llvm-project/llvm/lib/Support/Unix/Signals.inc:850:19:   required from here
/h/projects/llvm-project/llvm/include/llvm/Support/Format.h:106:34: error: no matching function for call to ‘std::tuple<int, char [4096]>::tuple(const int&, const char [4096])’
  106 |       : format_object_base(fmt), Vals(vals...) {
      |                                  ^~~~~~~~~~~~~
```
Casting here is safe and solves the issue.
@mstorsjo mstorsjo marked this pull request as ready for review May 1, 2025 12:31
@llvmbot
Copy link
Member

llvmbot commented May 1, 2025

@llvm/pr-subscribers-llvm-support

Author: Mateusz Mikuła (mati865)

Changes

Cygwin types sometimes do not match Linux exactly. Like in this case:

In file included from /h/projects/llvm-project/llvm/include/llvm/Support/Error.h:23,
                 from /h/projects/llvm-project/llvm/include/llvm/Support/FileSystem.h:34,
                 from /h/projects/llvm-project/llvm/lib/Support/Signals.cpp:22:
/h/projects/llvm-project/llvm/include/llvm/Support/Format.h: In instantiation of ‘llvm::format_object&lt;Ts&gt;::format_object(const char*, const Ts&amp; ...) [with Ts = {int, char [4096]}]’:
/h/projects/llvm-project/llvm/include/llvm/Support/Format.h:126:10:   required from ‘llvm::format_object&lt;Ts ...&gt; llvm::format(const char*, const Ts&amp; ...) [with Ts = {int, char [4096]}]’
/h/projects/llvm-project/llvm/lib/Support/Unix/Signals.inc:850:19:   required from here
/h/projects/llvm-project/llvm/include/llvm/Support/Format.h:106:34: error: no matching function for call to ‘std::tuple&lt;int, char [4096]&gt;::tuple(const int&amp;, const char [4096])’
  106 |       : format_object_base(fmt), Vals(vals...) {
      |                                  ^~~~~~~~~~~~~

Casting here is safe and solves the issue.

Split out from #134494


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

1 Files Affected:

  • (modified) llvm/lib/Support/Unix/Signals.inc (+1-1)
diff --git a/llvm/lib/Support/Unix/Signals.inc b/llvm/lib/Support/Unix/Signals.inc
index 30e5f40193974..691e1014f18e8 100644
--- a/llvm/lib/Support/Unix/Signals.inc
+++ b/llvm/lib/Support/Unix/Signals.inc
@@ -847,7 +847,7 @@ void llvm::sys::PrintStackTrace(raw_ostream &OS, int Depth) {
 
     const char *name = strrchr(dlinfo.dli_fname, '/');
     if (!name)
-      OS << format(" %-*s", width, dlinfo.dli_fname);
+      OS << format(" %-*s", width, static_cast<const char *>(dlinfo.dli_fname));
     else
       OS << format(" %-*s", width, name + 1);
 

Copy link
Member

@mstorsjo mstorsjo left a comment

Choose a reason for hiding this comment

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

LGTM

@jeremyd2019
Copy link
Contributor

jeremyd2019 commented May 1, 2025

Unrelated to this PR, but they really should be checking the return value of dladdr a few lines above and not trying to use the DL_info struct in case of error. In Cygwin at least, it likely won't have written to dli_fname in that case. I'm not firm enough in the specs involved in this situation: in C I'd think you'd need to set the struct = {0} to make sure it's zeroed, but in C++ perhaps it and its members are default constructed and so zero rather than uninitialized?

@mstorsjo
Copy link
Member

mstorsjo commented May 1, 2025

Unrelated to this PR, but they really should be checking the return value of dladdr a few lines above and not trying to use the DL_info struct in case of error. In Cygwin at least, it likely won't have written to dli_fname in that case. I'm not firm enough in the specs involved in this situation: in C I'd think you'd need to set the struct = {0} to make sure it's zeroed, but in C++ perhaps it and its members are default constructed and so zero rather than uninitialized?

That sounds like a quite reasonable fix. And I do think you would need to manually initialize a struct even in C++ if you want it to be zero initialized.

@jeremyd2019
Copy link
Contributor

Cygwin's error path here (uninitialized buffer) is probably not any worse than Linux's (uninitialized pointer). After this is merged I can look at dealing with it (it'd likely conflict). The easiest thing would be to continue on error, but it might be better to output a placeholder name of (error) or something like that instead.

@mstorsjo mstorsjo merged commit 8a84a19 into llvm:main May 2, 2025
15 checks passed
@mati865 mati865 deleted the push-zvkvlrzmzrpx branch May 2, 2025 09:00
jeremyd2019 pushed a commit to jeremyd2019/llvm-project that referenced this pull request May 2, 2025
Cygwin types sometimes do not match Linux exactly. Like in this case:
```
In file included from /h/projects/llvm-project/llvm/include/llvm/Support/Error.h:23,
                 from /h/projects/llvm-project/llvm/include/llvm/Support/FileSystem.h:34,
                 from /h/projects/llvm-project/llvm/lib/Support/Signals.cpp:22:
/h/projects/llvm-project/llvm/include/llvm/Support/Format.h: In instantiation of ‘llvm::format_object<Ts>::format_object(const char*, const Ts& ...) [with Ts = {int, char [4096]}]’:
/h/projects/llvm-project/llvm/include/llvm/Support/Format.h:126:10:   required from ‘llvm::format_object<Ts ...> llvm::format(const char*, const Ts& ...) [with Ts = {int, char [4096]}]’
/h/projects/llvm-project/llvm/lib/Support/Unix/Signals.inc:850:19:   required from here
/h/projects/llvm-project/llvm/include/llvm/Support/Format.h:106:34: error: no matching function for call to ‘std::tuple<int, char [4096]>::tuple(const int&, const char [4096])’
  106 |       : format_object_base(fmt), Vals(vals...) {
      |                                  ^~~~~~~~~~~~~
```
Casting here is safe and solves the issue.
jeremyd2019 pushed a commit to jeremyd2019/llvm-project that referenced this pull request May 2, 2025
Cygwin types sometimes do not match Linux exactly. Like in this case:
```
In file included from /h/projects/llvm-project/llvm/include/llvm/Support/Error.h:23,
                 from /h/projects/llvm-project/llvm/include/llvm/Support/FileSystem.h:34,
                 from /h/projects/llvm-project/llvm/lib/Support/Signals.cpp:22:
/h/projects/llvm-project/llvm/include/llvm/Support/Format.h: In instantiation of ‘llvm::format_object<Ts>::format_object(const char*, const Ts& ...) [with Ts = {int, char [4096]}]’:
/h/projects/llvm-project/llvm/include/llvm/Support/Format.h:126:10:   required from ‘llvm::format_object<Ts ...> llvm::format(const char*, const Ts& ...) [with Ts = {int, char [4096]}]’
/h/projects/llvm-project/llvm/lib/Support/Unix/Signals.inc:850:19:   required from here
/h/projects/llvm-project/llvm/include/llvm/Support/Format.h:106:34: error: no matching function for call to ‘std::tuple<int, char [4096]>::tuple(const int&, const char [4096])’
  106 |       : format_object_base(fmt), Vals(vals...) {
      |                                  ^~~~~~~~~~~~~
```
Casting here is safe and solves the issue.
jeremyd2019 pushed a commit to jeremyd2019/llvm-project that referenced this pull request May 3, 2025
Cygwin types sometimes do not match Linux exactly. Like in this case:
```
In file included from /h/projects/llvm-project/llvm/include/llvm/Support/Error.h:23,
                 from /h/projects/llvm-project/llvm/include/llvm/Support/FileSystem.h:34,
                 from /h/projects/llvm-project/llvm/lib/Support/Signals.cpp:22:
/h/projects/llvm-project/llvm/include/llvm/Support/Format.h: In instantiation of ‘llvm::format_object<Ts>::format_object(const char*, const Ts& ...) [with Ts = {int, char [4096]}]’:
/h/projects/llvm-project/llvm/include/llvm/Support/Format.h:126:10:   required from ‘llvm::format_object<Ts ...> llvm::format(const char*, const Ts& ...) [with Ts = {int, char [4096]}]’
/h/projects/llvm-project/llvm/lib/Support/Unix/Signals.inc:850:19:   required from here
/h/projects/llvm-project/llvm/include/llvm/Support/Format.h:106:34: error: no matching function for call to ‘std::tuple<int, char [4096]>::tuple(const int&, const char [4096])’
  106 |       : format_object_base(fmt), Vals(vals...) {
      |                                  ^~~~~~~~~~~~~
```
Casting here is safe and solves the issue.
jeremyd2019 pushed a commit to jeremyd2019/llvm-project that referenced this pull request May 5, 2025
Cygwin types sometimes do not match Linux exactly. Like in this case:
```
In file included from /h/projects/llvm-project/llvm/include/llvm/Support/Error.h:23,
                 from /h/projects/llvm-project/llvm/include/llvm/Support/FileSystem.h:34,
                 from /h/projects/llvm-project/llvm/lib/Support/Signals.cpp:22:
/h/projects/llvm-project/llvm/include/llvm/Support/Format.h: In instantiation of ‘llvm::format_object<Ts>::format_object(const char*, const Ts& ...) [with Ts = {int, char [4096]}]’:
/h/projects/llvm-project/llvm/include/llvm/Support/Format.h:126:10:   required from ‘llvm::format_object<Ts ...> llvm::format(const char*, const Ts& ...) [with Ts = {int, char [4096]}]’
/h/projects/llvm-project/llvm/lib/Support/Unix/Signals.inc:850:19:   required from here
/h/projects/llvm-project/llvm/include/llvm/Support/Format.h:106:34: error: no matching function for call to ‘std::tuple<int, char [4096]>::tuple(const int&, const char [4096])’
  106 |       : format_object_base(fmt), Vals(vals...) {
      |                                  ^~~~~~~~~~~~~
```
Casting here is safe and solves the issue.
IanWood1 pushed a commit to IanWood1/llvm-project that referenced this pull request May 6, 2025
Cygwin types sometimes do not match Linux exactly. Like in this case:
```
In file included from /h/projects/llvm-project/llvm/include/llvm/Support/Error.h:23,
                 from /h/projects/llvm-project/llvm/include/llvm/Support/FileSystem.h:34,
                 from /h/projects/llvm-project/llvm/lib/Support/Signals.cpp:22:
/h/projects/llvm-project/llvm/include/llvm/Support/Format.h: In instantiation of ‘llvm::format_object<Ts>::format_object(const char*, const Ts& ...) [with Ts = {int, char [4096]}]’:
/h/projects/llvm-project/llvm/include/llvm/Support/Format.h:126:10:   required from ‘llvm::format_object<Ts ...> llvm::format(const char*, const Ts& ...) [with Ts = {int, char [4096]}]’
/h/projects/llvm-project/llvm/lib/Support/Unix/Signals.inc:850:19:   required from here
/h/projects/llvm-project/llvm/include/llvm/Support/Format.h:106:34: error: no matching function for call to ‘std::tuple<int, char [4096]>::tuple(const int&, const char [4096])’
  106 |       : format_object_base(fmt), Vals(vals...) {
      |                                  ^~~~~~~~~~~~~
```
Casting here is safe and solves the issue.
IanWood1 pushed a commit to IanWood1/llvm-project that referenced this pull request May 6, 2025
Cygwin types sometimes do not match Linux exactly. Like in this case:
```
In file included from /h/projects/llvm-project/llvm/include/llvm/Support/Error.h:23,
                 from /h/projects/llvm-project/llvm/include/llvm/Support/FileSystem.h:34,
                 from /h/projects/llvm-project/llvm/lib/Support/Signals.cpp:22:
/h/projects/llvm-project/llvm/include/llvm/Support/Format.h: In instantiation of ‘llvm::format_object<Ts>::format_object(const char*, const Ts& ...) [with Ts = {int, char [4096]}]’:
/h/projects/llvm-project/llvm/include/llvm/Support/Format.h:126:10:   required from ‘llvm::format_object<Ts ...> llvm::format(const char*, const Ts& ...) [with Ts = {int, char [4096]}]’
/h/projects/llvm-project/llvm/lib/Support/Unix/Signals.inc:850:19:   required from here
/h/projects/llvm-project/llvm/include/llvm/Support/Format.h:106:34: error: no matching function for call to ‘std::tuple<int, char [4096]>::tuple(const int&, const char [4096])’
  106 |       : format_object_base(fmt), Vals(vals...) {
      |                                  ^~~~~~~~~~~~~
```
Casting here is safe and solves the issue.
IanWood1 pushed a commit to IanWood1/llvm-project that referenced this pull request May 6, 2025
Cygwin types sometimes do not match Linux exactly. Like in this case:
```
In file included from /h/projects/llvm-project/llvm/include/llvm/Support/Error.h:23,
                 from /h/projects/llvm-project/llvm/include/llvm/Support/FileSystem.h:34,
                 from /h/projects/llvm-project/llvm/lib/Support/Signals.cpp:22:
/h/projects/llvm-project/llvm/include/llvm/Support/Format.h: In instantiation of ‘llvm::format_object<Ts>::format_object(const char*, const Ts& ...) [with Ts = {int, char [4096]}]’:
/h/projects/llvm-project/llvm/include/llvm/Support/Format.h:126:10:   required from ‘llvm::format_object<Ts ...> llvm::format(const char*, const Ts& ...) [with Ts = {int, char [4096]}]’
/h/projects/llvm-project/llvm/lib/Support/Unix/Signals.inc:850:19:   required from here
/h/projects/llvm-project/llvm/include/llvm/Support/Format.h:106:34: error: no matching function for call to ‘std::tuple<int, char [4096]>::tuple(const int&, const char [4096])’
  106 |       : format_object_base(fmt), Vals(vals...) {
      |                                  ^~~~~~~~~~~~~
```
Casting here is safe and solves the issue.
GeorgeARM pushed a commit to GeorgeARM/llvm-project that referenced this pull request May 7, 2025
Cygwin types sometimes do not match Linux exactly. Like in this case:
```
In file included from /h/projects/llvm-project/llvm/include/llvm/Support/Error.h:23,
                 from /h/projects/llvm-project/llvm/include/llvm/Support/FileSystem.h:34,
                 from /h/projects/llvm-project/llvm/lib/Support/Signals.cpp:22:
/h/projects/llvm-project/llvm/include/llvm/Support/Format.h: In instantiation of ‘llvm::format_object<Ts>::format_object(const char*, const Ts& ...) [with Ts = {int, char [4096]}]’:
/h/projects/llvm-project/llvm/include/llvm/Support/Format.h:126:10:   required from ‘llvm::format_object<Ts ...> llvm::format(const char*, const Ts& ...) [with Ts = {int, char [4096]}]’
/h/projects/llvm-project/llvm/lib/Support/Unix/Signals.inc:850:19:   required from here
/h/projects/llvm-project/llvm/include/llvm/Support/Format.h:106:34: error: no matching function for call to ‘std::tuple<int, char [4096]>::tuple(const int&, const char [4096])’
  106 |       : format_object_base(fmt), Vals(vals...) {
      |                                  ^~~~~~~~~~~~~
```
Casting here is safe and solves the issue.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants