[Lldb-commits] [lldb] [lldb][Linux] Show si_addr for SIGBUS signals (PR #207718)

2026-07-07 Thread David Spickett via lldb-commits

https://github.com/DavidSpickett closed 
https://github.com/llvm/llvm-project/pull/207718
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][Linux] Show si_addr for SIGBUS signals (PR #207718)

2026-07-06 Thread David Spickett via lldb-commits

https://github.com/DavidSpickett edited 
https://github.com/llvm/llvm-project/pull/207718
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][Linux] Show si_addr for SIGBUS signals (PR #207718)

2026-07-06 Thread David Spickett via lldb-commits

https://github.com/DavidSpickett edited 
https://github.com/llvm/llvm-project/pull/207718
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][Linux] Show si_addr for SIGBUS signals (PR #207718)

2026-07-06 Thread David Spickett via lldb-commits

https://github.com/DavidSpickett edited 
https://github.com/llvm/llvm-project/pull/207718
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][Linux] Show si_addr for SIGBUS signals (PR #207718)

2026-07-06 Thread David Spickett via lldb-commits

https://github.com/DavidSpickett edited 
https://github.com/llvm/llvm-project/pull/207718
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][Linux] Show si_addr for SIGBUS signals (PR #207718)

2026-07-06 Thread via lldb-commits

llvmorg-github-actions[bot] wrote:




@llvm/pr-subscribers-lldb

Author: David Spickett (DavidSpickett)


Changes

The general rule is if si_addr is the same as the PC, we don't show it because 
it doesn't add any new information.

SIGBUS signals are caused by an instruction trying to do something, but si_addr 
is not the address of the instruction. It's some virtual address, which is the 
important bit so add it to the description.

Before:
* thread #1, name = 'test.o', stop reason = signal SIGBUS: illegal 
address frame #0: 0x0b80 test.o`main at test.c:42:13

After:
* thread #1, name = 'test.o', stop reason = signal SIGBUS: illegal 
address (fault address=0xf7ff6000) frame #0: 0x0b80 
test.o`main at test.c:42:13

I am not adding test cases for this because:
* They would be architecture specific.
* Reliably generating BUS_OBJERR seems difficult.
* Signal reporting has good coverage as it is, so we know that si_code/si_addr 
are handled correctly.

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


1 Files Affected:

- (modified) lldb/source/Plugins/Process/Utility/LinuxSignals.cpp (+3-3) 


``diff
diff --git a/lldb/source/Plugins/Process/Utility/LinuxSignals.cpp 
b/lldb/source/Plugins/Process/Utility/LinuxSignals.cpp
index 0f6b2b2ca767a..a71bde9532915 100644
--- a/lldb/source/Plugins/Process/Utility/LinuxSignals.cpp
+++ b/lldb/source/Plugins/Process/Utility/LinuxSignals.cpp
@@ -119,9 +119,9 @@ void LinuxSignals::Reset() {
   ADD_LINUX_SIGNAL(6,  "SIGABRT",  false,true,   true,   
"abort()/IOT trap", "SIGIOT");
 
   ADD_LINUX_SIGNAL(7,  "SIGBUS",   false,true,   true,   "bus 
error");
-  ADD_SIGCODE(SIGBUS, 7, BUS_ADRALN, 1, "illegal alignment");
-  ADD_SIGCODE(SIGBUS, 7, BUS_ADRERR, 2, "illegal address");
-  ADD_SIGCODE(SIGBUS, 7, BUS_OBJERR, 3, "hardware error");
+  ADD_SIGCODE(SIGBUS, 7, BUS_ADRALN, 1, "illegal alignment", 
SignalCodePrintOption::Address);
+  ADD_SIGCODE(SIGBUS, 7, BUS_ADRERR, 2, "illegal address", 
SignalCodePrintOption::Address);
+  ADD_SIGCODE(SIGBUS, 7, BUS_OBJERR, 3, "hardware error", 
SignalCodePrintOption::Address);
 
   ADD_LINUX_SIGNAL(8,  "SIGFPE",   false,true,   true,   "floating 
point exception");
   ADD_SIGCODE(SIGFPE, 8, FPE_INTDIV, 1, "integer divide by zero");

``




https://github.com/llvm/llvm-project/pull/207718
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][Linux] Show si_addr for SIGBUS signals (PR #207718)

2026-07-06 Thread David Spickett via lldb-commits

https://github.com/DavidSpickett created 
https://github.com/llvm/llvm-project/pull/207718

The general rule is if si_addr is the same as the PC, we don't show it because 
it doesn't add any new information.

SIGBUS signals are caused by an instruction trying to do something, but si_addr 
is not the address of the instruction. It's some virtual address, which is the 
important bit so add it to the description.

Before:
* thread #1, name = 'test.o', stop reason = signal SIGBUS: illegal address 
frame #0: 0x0b80 test.o`main at test.c:42:13

After:
* thread #1, name = 'test.o', stop reason = signal SIGBUS: illegal address 
(fault address=0xf7ff6000) frame #0: 0x0b80 test.o`main at 
test.c:42:13

I am not adding test cases for this because:
* They would be architecture specific.
* Reliably generating BUS_OBJERR seems difficult.
* Signal reporting has good coverage as it is, so we know that si_code/si_addr 
are handled correctly.

>From df5f938842d3cab646a63e98bcd6ea1e77b9263f Mon Sep 17 00:00:00 2001
From: David Spickett 
Date: Mon, 6 Jul 2026 12:22:16 +
Subject: [PATCH] [lldb][Linux] Show si_addr for SIGBUS signals

The general rule is if si_addr is the same as the PC,
we don't show it because it doesn't add any new information.

SIGBUS signals are caused by an instruction trying to
do something, but si_addr is not the address of the instruction.
It's some virtual address, which is the important bit
so add it to the description.

Before:
* thread #1, name = 'test.o', stop reason = signal SIGBUS: illegal address
   frame #0: 0x0b80 test.o`main at test.c:42:13

After:
* thread #1, name = 'test.o', stop reason = signal SIGBUS: illegal address 
(fault address=0xf7ff6000)
   frame #0: 0x0b80 test.o`main at test.c:42:13

I am not adding test cases for this because:
* They would be architecture specific.
* Relibably generating BUS_OBJERR seems difficult.
* Signal reporting has good coverage as it is, so we know
  that si_code/si_addr are handled correctly.
---
 lldb/source/Plugins/Process/Utility/LinuxSignals.cpp | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/lldb/source/Plugins/Process/Utility/LinuxSignals.cpp 
b/lldb/source/Plugins/Process/Utility/LinuxSignals.cpp
index 0f6b2b2ca767a..a71bde9532915 100644
--- a/lldb/source/Plugins/Process/Utility/LinuxSignals.cpp
+++ b/lldb/source/Plugins/Process/Utility/LinuxSignals.cpp
@@ -119,9 +119,9 @@ void LinuxSignals::Reset() {
   ADD_LINUX_SIGNAL(6,  "SIGABRT",  false,true,   true,   
"abort()/IOT trap", "SIGIOT");
 
   ADD_LINUX_SIGNAL(7,  "SIGBUS",   false,true,   true,   "bus 
error");
-  ADD_SIGCODE(SIGBUS, 7, BUS_ADRALN, 1, "illegal alignment");
-  ADD_SIGCODE(SIGBUS, 7, BUS_ADRERR, 2, "illegal address");
-  ADD_SIGCODE(SIGBUS, 7, BUS_OBJERR, 3, "hardware error");
+  ADD_SIGCODE(SIGBUS, 7, BUS_ADRALN, 1, "illegal alignment", 
SignalCodePrintOption::Address);
+  ADD_SIGCODE(SIGBUS, 7, BUS_ADRERR, 2, "illegal address", 
SignalCodePrintOption::Address);
+  ADD_SIGCODE(SIGBUS, 7, BUS_OBJERR, 3, "hardware error", 
SignalCodePrintOption::Address);
 
   ADD_LINUX_SIGNAL(8,  "SIGFPE",   false,true,   true,   "floating 
point exception");
   ADD_SIGCODE(SIGFPE, 8, FPE_INTDIV, 1, "integer divide by zero");

___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits