You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I searched for any similar issues to this but didn't find anything, so apologies if it's a known issue.
We recently switched the default clang compiler in the OmniOS operating system distribution from 16 to 17, and we had a report that the smartmontools package was no longer working correctly.
The short version is that clang 17 is not aligning drive on the stack for some reason in the following code if -fstack-protector-strong is in the build flags:
which is supported by gdb's interpretation of the DWARF - note that raw_drive is aligned as expected.
Symbol drive is a variable at frame base reg $rbp offset 0+-570, length 512.
Symbol raw_drive is a variable at frame base reg $rbp offset 0+-1088, length 512.
Building with either clang 16 or 18 does not cause this, in both of those cases the variable is properly aligned, as shown below.
Unfortunately I have not been able to come up with a standalone reproducer for this, but I did build the same smartmontools source on Ubuntu 24.04 with clang 17.0.6, and got similar results:
I searched for any similar issues to this but didn't find anything, so apologies if it's a known issue.
We recently switched the default clang compiler in the OmniOS operating system distribution from 16 to 17, and we had a report that the smartmontools package was no longer working correctly.
The short version is that clang 17 is not aligning drive on the stack for some reason in the following code if -fstack-protector-strong is in the build flags:
which is supported by gdb's interpretation of the DWARF - note that raw_drive is aligned as expected.
Symbol drive is a variable at frame base reg $rbp offset 0+-570, length 512.
Symbol raw_drive is a variable at frame base reg $rbp offset 0+-1088, length 512.
Building with either clang 16 or 18 does not cause this, in both of those cases the variable is properly aligned, as shown below.
Unfortunately I have not been able to come up with a standalone reproducer for this, but I did build the same smartmontools source on Ubuntu 24.04 with clang 17.0.6, and got similar results:
I searched for any similar issues to this but didn't find anything, so apologies if it's a known issue.
We recently switched the default clang compiler in the OmniOS operating system distribution from 16 to 17, and we had a report that the
smartmontools
package was no longer working correctly.There is more detail in omniosorg/omnios-extra#1418 but the relevant parts are included below.
The short version is that clang 17 is not aligning
drive
on the stack for some reason in the following code if-fstack-protector-strong
is in the build flags:Here's the context.
When building with clang 17.0.6, the resulting disassembly shows the misalignment:
which is supported by gdb's interpretation of the DWARF - note that
raw_drive
is aligned as expected.Building with either clang 16 or 18 does not cause this, in both of those cases the variable is properly aligned, as shown below.
Unfortunately I have not been able to come up with a standalone reproducer for this, but I did build the same smartmontools source on Ubuntu 24.04 with clang 17.0.6, and got similar results:
The build line for these was:
clang17
clang18
If there is any more data I can gather on this that would help, please let me know.
The text was updated successfully, but these errors were encountered: