[Lldb-commits] [lldb] [LLDB][Process/Utility] Introduce NativeRegisterContextDBReg class (PR #118043)
https://github.com/DavidSpickett edited https://github.com/llvm/llvm-project/pull/118043 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][Process/Utility] Introduce NativeRegisterContextDBReg class (PR #118043)
https://github.com/DavidSpickett commented: Looking good, I will test this version today. https://github.com/llvm/llvm-project/pull/118043 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][Process/Utility] Introduce NativeRegisterContextDBReg class (PR #118043)
@@ -0,0 +1,90 @@
+//===-- NativeRegisterContextDBReg.h *- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef lldb_NativeRegisterContextDBReg_h
+#define lldb_NativeRegisterContextDBReg_h
+
+#include "Plugins/Process/Utility/NativeRegisterContextRegisterInfo.h"
+
+#include
+
+namespace lldb_private {
+
+class NativeRegisterContextDBReg
+: public virtual NativeRegisterContextRegisterInfo {
+public:
+ uint32_t NumSupportedHardwareBreakpoints() override;
+
+ uint32_t SetHardwareBreakpoint(lldb::addr_t addr, size_t size) override;
+
+ bool ClearHardwareBreakpoint(uint32_t hw_idx) override;
+
+ Status ClearAllHardwareBreakpoints() override;
+
+ Status GetHardwareBreakHitIndex(uint32_t &bp_index,
+ lldb::addr_t trap_addr) override;
+
+ uint32_t NumSupportedHardwareWatchpoints() override;
+
+ uint32_t SetHardwareWatchpoint(lldb::addr_t addr, size_t size,
+ uint32_t watch_flags) override;
+
+ bool ClearHardwareWatchpoint(uint32_t hw_index) override;
+
+ Status ClearAllHardwareWatchpoints() override;
+
+ Status GetWatchpointHitIndex(uint32_t &wp_index,
+ lldb::addr_t trap_addr) override;
+
+ lldb::addr_t GetWatchpointHitAddress(uint32_t wp_index) override;
+
+ lldb::addr_t GetWatchpointAddress(uint32_t wp_index) override;
+
+protected:
+ // Debug register type select
+ enum DREGType { eDREGTypeWATCH = 0, eDREGTypeBREAK };
+
+ /// Debug register info for hardware breakpoints and watchpoints management.
+ struct DREG {
+lldb::addr_t address; // Breakpoint/watchpoint address value.
+lldb::addr_t hit_addr; // Address at which last watchpoint trigger
exception
+ // occurred.
+lldb::addr_t real_addr; // Address value that should cause target to stop.
+uint32_t control; // Breakpoint/watchpoint control value.
+ };
+
+ std::array m_hbp_regs; // hardware breakpoints
+ std::array m_hwp_regs; // hardware watchpoints
+
+ uint32_t m_max_hbp_supported;
+ uint32_t m_max_hwp_supported;
+ uint32_t m_hw_dbg_enable_bit;
+
+ bool WatchpointIsEnabled(uint32_t wp_index);
+ bool BreakpointIsEnabled(uint32_t bp_index);
+
+ // Default hardware breakpoint length size is 4.
+ // Default hardware breakpoint target address must 4-byte alignment.
+ virtual bool ValidateBreakpoint(size_t size, lldb::addr_t addr) {
+return (size == 4) && !(addr & 0x3);
DavidSpickett wrote:
If these specific checks are common to AArch64 and LoongArch, this is fine. You
could remove `virtual` if so.
If this is just the AArch64 checks, I think it might be better to make this an
abstract method. Just so that future programmers are forced to confirm what
their architecture requires, and they can find existing rules by looking at the
arch specific class, rather than having to know that one uses the base
implementation.
https://github.com/llvm/llvm-project/pull/118043
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][Process/Utility] Introduce NativeRegisterContextDBReg class (PR #118043)
DavidSpickett wrote: And now I see that x86 has a `NativeRegisterContextDBReg_x86` class. The way it stores registers is quite different though, so I don't think: 1. We can share that much code without changing how it reads the registers. 2. That it's a problem if we just leave `NativeRegisterContextDBReg_x86` as it is. So let's ignore that class for now. LoongArch and AArch64 is enough to be dealing with. https://github.com/llvm/llvm-project/pull/118043 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][Process/Utility] Introduce NativeRegisterContextDBReg class (PR #118043)
@@ -0,0 +1,400 @@
+//===-- NativeRegisterContextDBReg.cpp
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "NativeRegisterContextDBReg.h"
+
+#include "lldb/Utility/LLDBLog.h"
+#include "lldb/Utility/Log.h"
+#include "lldb/Utility/RegisterValue.h"
+
+using namespace lldb_private;
+
+uint32_t NativeRegisterContextDBReg::NumSupportedHardwareBreakpoints() {
+ Log *log = GetLog(LLDBLog::Breakpoints);
+
+ // Read hardware breakpoint and watchpoint information.
+ Status error = ReadHardwareDebugInfo();
+
+ if (error.Fail()) {
+LLDB_LOG(log, "failed to read debug registers");
+return 0;
+ }
+
+ LLDB_LOG(log, "{0}", m_max_hbp_supported);
+ return m_max_hbp_supported;
+}
+
+uint32_t NativeRegisterContextDBReg::SetHardwareBreakpoint(lldb::addr_t addr,
+ size_t size) {
+ Log *log = GetLog(LLDBLog::Breakpoints);
+ LLDB_LOG(log, "addr: {0:x}, size: {1:x}", addr, size);
+
+ // Read hardware breakpoint and watchpoint information.
+ Status error = ReadHardwareDebugInfo();
+ if (error.Fail()) {
+LLDB_LOG(log,
+ "unable to set breakpoint: failed to read debug registers: {0}");
+return LLDB_INVALID_INDEX32;
+ }
+
+ uint32_t control_value = 0, bp_index = 0;
+
+ // Check hardware breakpoint size and address.
+ if (!ValidateBreakpoint(size, addr))
+return LLDB_INVALID_INDEX32;
+
+ // Setup control value
+ control_value = MakeControlValue(size);
+
+ // Iterate over stored breakpoints and find a free bp_index
+ bp_index = LLDB_INVALID_INDEX32;
+ for (uint32_t i = 0; i < m_max_hbp_supported; i++) {
+if (!BreakpointIsEnabled(i))
+ bp_index = i; // Mark last free slot
+else if (m_hbp_regs[i].address == addr)
+ return LLDB_INVALID_INDEX32; // We do not support duplicate breakpoints.
+ }
+
+ if (bp_index == LLDB_INVALID_INDEX32)
+return LLDB_INVALID_INDEX32;
+
+ // Update breakpoint in local cache
+ m_hbp_regs[bp_index].real_addr = addr;
+ m_hbp_regs[bp_index].address = addr;
+ m_hbp_regs[bp_index].control = control_value;
+
+ // PTRACE call to set corresponding hardware breakpoint register.
+ error = WriteHardwareDebugRegs(eDREGTypeBREAK);
+
+ if (error.Fail()) {
+m_hbp_regs[bp_index].address = 0;
+m_hbp_regs[bp_index].control &= ~m_hw_dbg_enable_bit;
+
+LLDB_LOG(log,
+ "unable to set breakpoint: failed to write debug registers: {0}");
+return LLDB_INVALID_INDEX32;
+ }
+
+ return bp_index;
+}
+
+bool NativeRegisterContextDBReg::ClearHardwareBreakpoint(uint32_t hw_idx) {
+ Log *log = GetLog(LLDBLog::Breakpoints);
+ LLDB_LOG(log, "hw_idx: {0}", hw_idx);
+
+ // Read hardware breakpoint and watchpoint information.
+ Status error = ReadHardwareDebugInfo();
+ if (error.Fail()) {
+LLDB_LOG(log,
+ "unable to clear breakpoint: failed to read debug registers:
{0}");
+return false;
+ }
+
+ if (hw_idx >= m_max_hbp_supported)
+return false;
+
+ // Create a backup we can revert to in case of failure.
+ lldb::addr_t tempAddr = m_hbp_regs[hw_idx].address;
+ uint32_t tempControl = m_hbp_regs[hw_idx].control;
+
+ m_hbp_regs[hw_idx].control &= ~m_hw_dbg_enable_bit;
+ m_hbp_regs[hw_idx].address = 0;
+
+ // PTRACE call to clear corresponding hardware breakpoint register.
+ error = WriteHardwareDebugRegs(eDREGTypeBREAK);
+
+ if (error.Fail()) {
+m_hbp_regs[hw_idx].control = tempControl;
+m_hbp_regs[hw_idx].address = tempAddr;
+
+LLDB_LOG(log,
+ "unable to clear breakpoint: failed to write debug registers");
+return false;
+ }
+
+ return true;
+}
+
+Status
+NativeRegisterContextDBReg::GetHardwareBreakHitIndex(uint32_t &bp_index,
+ lldb::addr_t trap_addr) {
+ Log *log = GetLog(LLDBLog::Breakpoints);
+
+ LLDB_LOGF(log, "NativeRegisterContextDBReg::%s()", __FUNCTION__);
+
+ lldb::addr_t break_addr;
+
+ for (bp_index = 0; bp_index < m_max_hbp_supported; ++bp_index) {
+break_addr = m_hbp_regs[bp_index].address;
+
+if (BreakpointIsEnabled(bp_index) && trap_addr == break_addr) {
+ m_hbp_regs[bp_index].hit_addr = trap_addr;
+ return Status();
+}
+ }
+
+ bp_index = LLDB_INVALID_INDEX32;
+ return Status();
+}
+
+Status NativeRegisterContextDBReg::ClearAllHardwareBreakpoints() {
+ Log *log = GetLog(LLDBLog::Breakpoints);
+
+ LLDB_LOGF(log, "NativeRegisterContextDBReg::%s()", __FUNCTION__);
+
+ // Read hardware breakpoint and watchpoint information.
+ Status error = ReadHardwareDebugInfo();
+ if (error.Fail())
+return error;
+
+ for (uint32_t i = 0; i < m_max_hbp_supported; i++) {
+if (!BreakpointIsEnabled(i))
+ continue
[Lldb-commits] [lldb] [LLDB][Process/Utility] Introduce NativeRegisterContextDBReg class (PR #118043)
@@ -0,0 +1,400 @@
+//===-- NativeRegisterContextDBReg.cpp
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "NativeRegisterContextDBReg.h"
+
+#include "lldb/Utility/LLDBLog.h"
+#include "lldb/Utility/Log.h"
+#include "lldb/Utility/RegisterValue.h"
+
+using namespace lldb_private;
+
+uint32_t NativeRegisterContextDBReg::NumSupportedHardwareBreakpoints() {
+ Log *log = GetLog(LLDBLog::Breakpoints);
+
+ // Read hardware breakpoint and watchpoint information.
+ Status error = ReadHardwareDebugInfo();
+
+ if (error.Fail()) {
+LLDB_LOG(log, "failed to read debug registers");
+return 0;
+ }
+
+ LLDB_LOG(log, "{0}", m_max_hbp_supported);
+ return m_max_hbp_supported;
+}
+
+uint32_t NativeRegisterContextDBReg::SetHardwareBreakpoint(lldb::addr_t addr,
+ size_t size) {
+ Log *log = GetLog(LLDBLog::Breakpoints);
+ LLDB_LOG(log, "addr: {0:x}, size: {1:x}", addr, size);
+
+ // Read hardware breakpoint and watchpoint information.
+ Status error = ReadHardwareDebugInfo();
+ if (error.Fail()) {
+LLDB_LOG(log,
+ "unable to set breakpoint: failed to read debug registers: {0}");
+return LLDB_INVALID_INDEX32;
+ }
+
+ uint32_t control_value = 0, bp_index = 0;
+
+ // Check hardware breakpoint size and address.
+ if (!ValidateBreakpoint(size, addr))
+return LLDB_INVALID_INDEX32;
+
+ // Setup control value
+ control_value = MakeControlValue(size);
+
+ // Iterate over stored breakpoints and find a free bp_index
+ bp_index = LLDB_INVALID_INDEX32;
+ for (uint32_t i = 0; i < m_max_hbp_supported; i++) {
+if (!BreakpointIsEnabled(i))
+ bp_index = i; // Mark last free slot
+else if (m_hbp_regs[i].address == addr)
+ return LLDB_INVALID_INDEX32; // We do not support duplicate breakpoints.
+ }
+
+ if (bp_index == LLDB_INVALID_INDEX32)
+return LLDB_INVALID_INDEX32;
+
+ // Update breakpoint in local cache
+ m_hbp_regs[bp_index].real_addr = addr;
+ m_hbp_regs[bp_index].address = addr;
+ m_hbp_regs[bp_index].control = control_value;
+
+ // PTRACE call to set corresponding hardware breakpoint register.
+ error = WriteHardwareDebugRegs(eDREGTypeBREAK);
+
+ if (error.Fail()) {
+m_hbp_regs[bp_index].address = 0;
+m_hbp_regs[bp_index].control &= ~m_hw_dbg_enable_bit;
+
+LLDB_LOG(log,
+ "unable to set breakpoint: failed to write debug registers: {0}");
+return LLDB_INVALID_INDEX32;
+ }
+
+ return bp_index;
+}
+
+bool NativeRegisterContextDBReg::ClearHardwareBreakpoint(uint32_t hw_idx) {
+ Log *log = GetLog(LLDBLog::Breakpoints);
+ LLDB_LOG(log, "hw_idx: {0}", hw_idx);
+
+ // Read hardware breakpoint and watchpoint information.
+ Status error = ReadHardwareDebugInfo();
+ if (error.Fail()) {
+LLDB_LOG(log,
+ "unable to clear breakpoint: failed to read debug registers:
{0}");
+return false;
+ }
+
+ if (hw_idx >= m_max_hbp_supported)
+return false;
+
+ // Create a backup we can revert to in case of failure.
+ lldb::addr_t tempAddr = m_hbp_regs[hw_idx].address;
+ uint32_t tempControl = m_hbp_regs[hw_idx].control;
+
+ m_hbp_regs[hw_idx].control &= ~m_hw_dbg_enable_bit;
+ m_hbp_regs[hw_idx].address = 0;
+
+ // PTRACE call to clear corresponding hardware breakpoint register.
+ error = WriteHardwareDebugRegs(eDREGTypeBREAK);
+
+ if (error.Fail()) {
+m_hbp_regs[hw_idx].control = tempControl;
+m_hbp_regs[hw_idx].address = tempAddr;
+
+LLDB_LOG(log,
+ "unable to clear breakpoint: failed to write debug registers");
+return false;
+ }
+
+ return true;
+}
+
+Status
+NativeRegisterContextDBReg::GetHardwareBreakHitIndex(uint32_t &bp_index,
+ lldb::addr_t trap_addr) {
+ Log *log = GetLog(LLDBLog::Breakpoints);
+
+ LLDB_LOGF(log, "NativeRegisterContextDBReg::%s()", __FUNCTION__);
+
+ lldb::addr_t break_addr;
+
+ for (bp_index = 0; bp_index < m_max_hbp_supported; ++bp_index) {
+break_addr = m_hbp_regs[bp_index].address;
+
+if (BreakpointIsEnabled(bp_index) && trap_addr == break_addr) {
+ m_hbp_regs[bp_index].hit_addr = trap_addr;
+ return Status();
+}
+ }
+
+ bp_index = LLDB_INVALID_INDEX32;
+ return Status();
+}
+
+Status NativeRegisterContextDBReg::ClearAllHardwareBreakpoints() {
+ Log *log = GetLog(LLDBLog::Breakpoints);
+
+ LLDB_LOGF(log, "NativeRegisterContextDBReg::%s()", __FUNCTION__);
+
+ // Read hardware breakpoint and watchpoint information.
+ Status error = ReadHardwareDebugInfo();
+ if (error.Fail())
+return error;
+
+ for (uint32_t i = 0; i < m_max_hbp_supported; i++) {
+if (!BreakpointIsEnabled(i))
+ continue
[Lldb-commits] [lldb] [LLDB][Process/Utility] Introduce NativeRegisterContextDBReg class (PR #118043)
@@ -272,199 +57,27 @@ uint32_t
NativeRegisterContextDBReg_arm64::SetHardwareWatchpoint(
addr = addr & (~0x07);
}
-
- // Setup control value
- control_value = g_enable_bit | g_pac_bits | GetSizeBits(size);
- control_value |= watch_flags << 3;
-
- // Iterate over stored watchpoints and find a free wp_index
- wp_index = LLDB_INVALID_INDEX32;
- for (uint32_t i = 0; i < m_max_hwp_supported; i++) {
-if (!WatchpointIsEnabled(i))
- wp_index = i; // Mark last free slot
-else if (m_hwp_regs[i].address == addr) {
- return LLDB_INVALID_INDEX32; // We do not support duplicate watchpoints.
-}
- }
-
- if (wp_index == LLDB_INVALID_INDEX32)
-return LLDB_INVALID_INDEX32;
-
- // Update watchpoint in local cache
- m_hwp_regs[wp_index].real_addr = real_addr;
- m_hwp_regs[wp_index].address = addr;
- m_hwp_regs[wp_index].control = control_value;
-
- // PTRACE call to set corresponding watchpoint register.
- error = WriteHardwareDebugRegs(eDREGTypeWATCH);
-
- if (error) {
-m_hwp_regs[wp_index].address = 0;
-m_hwp_regs[wp_index].control &= ~g_enable_bit;
-
-LLDB_LOG_ERROR(
-log, std::move(error),
-"unable to set watchpoint: failed to write debug registers: {0}");
-return LLDB_INVALID_INDEX32;
- }
-
- return wp_index;
-}
-
-bool NativeRegisterContextDBReg_arm64::ClearHardwareWatchpoint(
-uint32_t wp_index) {
- Log *log = GetLog(LLDBLog::Watchpoints);
- LLDB_LOG(log, "wp_index: {0}", wp_index);
-
- // Read hardware breakpoint and watchpoint information.
- llvm::Error error = ReadHardwareDebugInfo();
- if (error) {
-LLDB_LOG_ERROR(
-log, std::move(error),
-"unable to clear watchpoint: failed to read debug registers: {0}");
-return false;
- }
-
- if (wp_index >= m_max_hwp_supported)
-return false;
-
- // Create a backup we can revert to in case of failure.
- lldb::addr_t tempAddr = m_hwp_regs[wp_index].address;
- uint32_t tempControl = m_hwp_regs[wp_index].control;
-
- // Update watchpoint in local cache
- m_hwp_regs[wp_index].control &= ~g_enable_bit;
- m_hwp_regs[wp_index].address = 0;
-
- // Ptrace call to update hardware debug registers
- error = WriteHardwareDebugRegs(eDREGTypeWATCH);
-
- if (error) {
-m_hwp_regs[wp_index].control = tempControl;
-m_hwp_regs[wp_index].address = tempAddr;
-
-LLDB_LOG_ERROR(
-log, std::move(error),
-"unable to clear watchpoint: failed to write debug registers: {0}");
-return false;
- }
-
return true;
}
-Status NativeRegisterContextDBReg_arm64::ClearAllHardwareWatchpoints() {
- // Read hardware breakpoint and watchpoint information.
- llvm::Error error = ReadHardwareDebugInfo();
- if (error)
-return Status::FromError(std::move(error));
-
- for (uint32_t i = 0; i < m_max_hwp_supported; i++) {
-if (WatchpointIsEnabled(i)) {
- // Create a backup we can revert to in case of failure.
- lldb::addr_t tempAddr = m_hwp_regs[i].address;
- uint32_t tempControl = m_hwp_regs[i].control;
-
- // Clear watchpoints in local cache
- m_hwp_regs[i].control &= ~g_enable_bit;
- m_hwp_regs[i].address = 0;
-
- // Ptrace call to update hardware debug registers
- error = WriteHardwareDebugRegs(eDREGTypeWATCH);
-
- if (error) {
-m_hwp_regs[i].control = tempControl;
-m_hwp_regs[i].address = tempAddr;
-
-return Status::FromError(std::move(error));
- }
-}
- }
-
- return Status();
-}
-
uint32_t
-NativeRegisterContextDBReg_arm64::GetWatchpointSize(uint32_t wp_index) {
- Log *log = GetLog(LLDBLog::Watchpoints);
- LLDB_LOG(log, "wp_index: {0}", wp_index);
+NativeRegisterContextDBReg_arm64::MakeControlValue(size_t size,
+ uint32_t *watch_flags) {
+ // PAC (bits 2:1): 0b10
+ uint32_t pac_bits = (2 << 1);
DavidSpickett wrote:
const
https://github.com/llvm/llvm-project/pull/118043
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][Process/Utility] Introduce NativeRegisterContextDBReg class (PR #118043)
@@ -0,0 +1,90 @@
+//===-- NativeRegisterContextDBReg.h *- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef lldb_NativeRegisterContextDBReg_h
+#define lldb_NativeRegisterContextDBReg_h
+
+#include "Plugins/Process/Utility/NativeRegisterContextRegisterInfo.h"
+
+#include
+
+namespace lldb_private {
+
+class NativeRegisterContextDBReg
+: public virtual NativeRegisterContextRegisterInfo {
+public:
+ uint32_t NumSupportedHardwareBreakpoints() override;
+
+ uint32_t SetHardwareBreakpoint(lldb::addr_t addr, size_t size) override;
+
+ bool ClearHardwareBreakpoint(uint32_t hw_idx) override;
+
+ Status ClearAllHardwareBreakpoints() override;
+
+ Status GetHardwareBreakHitIndex(uint32_t &bp_index,
+ lldb::addr_t trap_addr) override;
+
+ uint32_t NumSupportedHardwareWatchpoints() override;
+
+ uint32_t SetHardwareWatchpoint(lldb::addr_t addr, size_t size,
+ uint32_t watch_flags) override;
+
+ bool ClearHardwareWatchpoint(uint32_t hw_index) override;
+
+ Status ClearAllHardwareWatchpoints() override;
+
+ Status GetWatchpointHitIndex(uint32_t &wp_index,
+ lldb::addr_t trap_addr) override;
+
+ lldb::addr_t GetWatchpointHitAddress(uint32_t wp_index) override;
+
+ lldb::addr_t GetWatchpointAddress(uint32_t wp_index) override;
+
+protected:
+ // Debug register type select
+ enum DREGType { eDREGTypeWATCH = 0, eDREGTypeBREAK };
+
+ /// Debug register info for hardware breakpoints and watchpoints management.
+ struct DREG {
+lldb::addr_t address; // Breakpoint/watchpoint address value.
+lldb::addr_t hit_addr; // Address at which last watchpoint trigger
exception
+ // occurred.
+lldb::addr_t real_addr; // Address value that should cause target to stop.
+uint32_t control; // Breakpoint/watchpoint control value.
+ };
+
+ std::array m_hbp_regs; // hardware breakpoints
+ std::array m_hwp_regs; // hardware watchpoints
+
+ uint32_t m_max_hbp_supported;
+ uint32_t m_max_hwp_supported;
+ uint32_t m_hw_dbg_enable_bit;
DavidSpickett wrote:
This should be const, and initialised in the class constructors.
Or, if AArch64 and LoongArch use the same bit, just init it to 1 here in the
base class.
https://github.com/llvm/llvm-project/pull/118043
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][Process/Utility] Introduce NativeRegisterContextDBReg class (PR #118043)
@@ -272,199 +57,27 @@ uint32_t
NativeRegisterContextDBReg_arm64::SetHardwareWatchpoint(
addr = addr & (~0x07);
}
-
- // Setup control value
- control_value = g_enable_bit | g_pac_bits | GetSizeBits(size);
- control_value |= watch_flags << 3;
-
- // Iterate over stored watchpoints and find a free wp_index
- wp_index = LLDB_INVALID_INDEX32;
- for (uint32_t i = 0; i < m_max_hwp_supported; i++) {
-if (!WatchpointIsEnabled(i))
- wp_index = i; // Mark last free slot
-else if (m_hwp_regs[i].address == addr) {
- return LLDB_INVALID_INDEX32; // We do not support duplicate watchpoints.
-}
- }
-
- if (wp_index == LLDB_INVALID_INDEX32)
-return LLDB_INVALID_INDEX32;
-
- // Update watchpoint in local cache
- m_hwp_regs[wp_index].real_addr = real_addr;
- m_hwp_regs[wp_index].address = addr;
- m_hwp_regs[wp_index].control = control_value;
-
- // PTRACE call to set corresponding watchpoint register.
- error = WriteHardwareDebugRegs(eDREGTypeWATCH);
-
- if (error) {
-m_hwp_regs[wp_index].address = 0;
-m_hwp_regs[wp_index].control &= ~g_enable_bit;
-
-LLDB_LOG_ERROR(
-log, std::move(error),
-"unable to set watchpoint: failed to write debug registers: {0}");
-return LLDB_INVALID_INDEX32;
- }
-
- return wp_index;
-}
-
-bool NativeRegisterContextDBReg_arm64::ClearHardwareWatchpoint(
-uint32_t wp_index) {
- Log *log = GetLog(LLDBLog::Watchpoints);
- LLDB_LOG(log, "wp_index: {0}", wp_index);
-
- // Read hardware breakpoint and watchpoint information.
- llvm::Error error = ReadHardwareDebugInfo();
- if (error) {
-LLDB_LOG_ERROR(
-log, std::move(error),
-"unable to clear watchpoint: failed to read debug registers: {0}");
-return false;
- }
-
- if (wp_index >= m_max_hwp_supported)
-return false;
-
- // Create a backup we can revert to in case of failure.
- lldb::addr_t tempAddr = m_hwp_regs[wp_index].address;
- uint32_t tempControl = m_hwp_regs[wp_index].control;
-
- // Update watchpoint in local cache
- m_hwp_regs[wp_index].control &= ~g_enable_bit;
- m_hwp_regs[wp_index].address = 0;
-
- // Ptrace call to update hardware debug registers
- error = WriteHardwareDebugRegs(eDREGTypeWATCH);
-
- if (error) {
-m_hwp_regs[wp_index].control = tempControl;
-m_hwp_regs[wp_index].address = tempAddr;
-
-LLDB_LOG_ERROR(
-log, std::move(error),
-"unable to clear watchpoint: failed to write debug registers: {0}");
-return false;
- }
-
return true;
}
-Status NativeRegisterContextDBReg_arm64::ClearAllHardwareWatchpoints() {
- // Read hardware breakpoint and watchpoint information.
- llvm::Error error = ReadHardwareDebugInfo();
- if (error)
-return Status::FromError(std::move(error));
-
- for (uint32_t i = 0; i < m_max_hwp_supported; i++) {
-if (WatchpointIsEnabled(i)) {
- // Create a backup we can revert to in case of failure.
- lldb::addr_t tempAddr = m_hwp_regs[i].address;
- uint32_t tempControl = m_hwp_regs[i].control;
-
- // Clear watchpoints in local cache
- m_hwp_regs[i].control &= ~g_enable_bit;
- m_hwp_regs[i].address = 0;
-
- // Ptrace call to update hardware debug registers
- error = WriteHardwareDebugRegs(eDREGTypeWATCH);
-
- if (error) {
-m_hwp_regs[i].control = tempControl;
-m_hwp_regs[i].address = tempAddr;
-
-return Status::FromError(std::move(error));
- }
-}
- }
-
- return Status();
-}
-
uint32_t
-NativeRegisterContextDBReg_arm64::GetWatchpointSize(uint32_t wp_index) {
- Log *log = GetLog(LLDBLog::Watchpoints);
- LLDB_LOG(log, "wp_index: {0}", wp_index);
+NativeRegisterContextDBReg_arm64::MakeControlValue(size_t size,
+ uint32_t *watch_flags) {
+ // PAC (bits 2:1): 0b10
+ uint32_t pac_bits = (2 << 1);
- switch ((m_hwp_regs[wp_index].control >> 5) & 0xff) {
- case 0x01:
-return 1;
- case 0x03:
-return 2;
- case 0x0f:
-return 4;
- case 0xff:
-return 8;
- default:
-return 0;
- }
-}
-
-bool NativeRegisterContextDBReg_arm64::WatchpointIsEnabled(uint32_t wp_index) {
- Log *log = GetLog(LLDBLog::Watchpoints);
- LLDB_LOG(log, "wp_index: {0}", wp_index);
-
- if ((m_hwp_regs[wp_index].control & g_enable_bit) != 0)
-return true;
- else
-return false;
-}
-
-Status NativeRegisterContextDBReg_arm64::GetWatchpointHitIndex(
-uint32_t &wp_index, lldb::addr_t trap_addr) {
- Log *log = GetLog(LLDBLog::Watchpoints);
- LLDB_LOG(log, "wp_index: {0}, trap_addr: {1:x}", wp_index, trap_addr);
-
- // Read hardware breakpoint and watchpoint information.
- llvm::Error error = ReadHardwareDebugInfo();
- if (error)
-return Status::FromError(std::move(error));
-
- // Mask off ignored bits from watchpoint trap address.
- trap_addr = FixWatchpointHitAddress(trap_addr);
-
- uint32_t watch_size;
- lldb::addr_t watch_addr;
-
- for (wp_index = 0; wp_index < m_max_hwp_supported; +
[Lldb-commits] [lldb] [lldb] Reduce the frequency of DWARF index progress reporting (PR #118953)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Pavel Labath (labath)
Changes
Indexing a single DWARF unit is a relatively fast operation, particularly if
it's a type unit, which can be very small. Reporting progress takes a mutex
(and allocates memory, etc.), which creates a lot of contention and slows down
indexing noticeably.
This patch reports makes us report progress only once per 10 milliseconds (on
average), which speeds up indexing by up to 55%. It achieves this by checking
whether the time after indexing every unit. This creates the possibility that a
particularly large unit could cause us to stop reporting progress for a while
(even for units that have already been indexed), but I don't think this is
likely to happen, because:
- Even the largest units don't take that long to index. The largest unit in
lldb (4MB of .debug_info) was indexed in "only" 200ms.
- The time is being checked and reported by all worker threads, which means
that in order to stall, we'd have to be very unfortunate and pick up an
extremely large compile unit on all indexing threads simultaneously.
Even if that does happens, the only negative consequence is some jitteriness in
a progress bar, which is why I prefer this over alternative implementations
which e.g. involve reporting progress from a dedicated thread.
---
Full diff: https://github.com/llvm/llvm-project/pull/118953.diff
1 Files Affected:
- (modified) lldb/source/Plugins/SymbolFile/DWARF/ManualDWARFIndex.cpp (+23-8)
``diff
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/ManualDWARFIndex.cpp
b/lldb/source/Plugins/SymbolFile/DWARF/ManualDWARFIndex.cpp
index 5b325e30bef430..a3e595d0194eb9 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/ManualDWARFIndex.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/ManualDWARFIndex.cpp
@@ -24,6 +24,7 @@
#include "llvm/Support/FormatVariadic.h"
#include "llvm/Support/ThreadPool.h"
#include
+#include
#include
using namespace lldb_private;
@@ -91,14 +92,27 @@ void ManualDWARFIndex::Index() {
// are available. This is significantly faster than submiting a new task for
// each unit.
auto for_each_unit = [&](auto &&fn) {
-std::atomic next_cu_idx = 0;
-auto wrapper = [&fn, &next_cu_idx, &units_to_index,
-&progress](size_t worker_id) {
- size_t cu_idx;
- while ((cu_idx = next_cu_idx.fetch_add(1, std::memory_order_relaxed)) <
- units_to_index.size()) {
-fn(worker_id, cu_idx, units_to_index[cu_idx]);
-progress.Increment();
+std::atomic next_unit_idx = 0;
+std::atomic units_indexed = 0;
+auto wrapper = [&fn, &next_unit_idx, &units_indexed, &units_to_index,
+&progress, num_threads](size_t worker_id) {
+ constexpr auto progress_interval = std::chrono::milliseconds(10);
+
+ // Stagger the reports for different threads so we get a steady stream of
+ // one report per ~10ms.
+ auto next_report = std::chrono::steady_clock::now() +
+ progress_interval * (1 + worker_id);
+ size_t unit_idx;
+ while ((unit_idx = next_unit_idx.fetch_add(
+ 1, std::memory_order_relaxed)) < units_to_index.size()) {
+fn(worker_id, unit_idx, units_to_index[unit_idx]);
+
+units_indexed.fetch_add(1, std::memory_order_acq_rel);
+if (auto now = std::chrono::steady_clock::now(); now >= next_report) {
+ progress.Increment(
+ units_indexed.exchange(0, std::memory_order_acq_rel));
+ next_report = now + num_threads * progress_interval;
+}
}
};
@@ -106,6 +120,7 @@ void ManualDWARFIndex::Index() {
task_group.async(wrapper, i);
task_group.wait();
+progress.Increment(units_indexed.load(std::memory_order_acquire));
};
// Extract dies for all DWARFs unit in parallel. Figure out which units
``
https://github.com/llvm/llvm-project/pull/118953
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Reduce the frequency of DWARF index progress reporting (PR #118953)
https://github.com/labath created
https://github.com/llvm/llvm-project/pull/118953
Indexing a single DWARF unit is a relatively fast operation, particularly if
it's a type unit, which can be very small. Reporting progress takes a mutex
(and allocates memory, etc.), which creates a lot of contention and slows down
indexing noticeably.
This patch reports makes us report progress only once per 10 milliseconds (on
average), which speeds up indexing by up to 55%. It achieves this by checking
whether the time after indexing every unit. This creates the possibility that a
particularly large unit could cause us to stop reporting progress for a while
(even for units that have already been indexed), but I don't think this is
likely to happen, because:
- Even the largest units don't take that long to index. The largest unit in
lldb (4MB of .debug_info) was indexed in "only" 200ms.
- The time is being checked and reported by all worker threads, which means
that in order to stall, we'd have to be very unfortunate and pick up an
extremely large compile unit on all indexing threads simultaneously.
Even if that does happens, the only negative consequence is some jitteriness in
a progress bar, which is why I prefer this over alternative implementations
which e.g. involve reporting progress from a dedicated thread.
>From 27c248a5f28f57ec3b0d2e5e191a88330f158e17 Mon Sep 17 00:00:00 2001
From: Pavel Labath
Date: Thu, 5 Dec 2024 13:07:13 +0100
Subject: [PATCH] [lldb] Reduce the frequency of DWARF index progress reporting
Indexing a single DWARF unit is a relatively fast operation,
particularly if it's a type unit, which can be very small. Reporting
progress takes a mutex (and allocates memory, etc.), which creates a lot
of contention and slows down indexing noticeably.
This patch reports makes us report progress only once per 10
milliseconds (on average), which speeds up indexing by up to 55%. It
achieves this by checking whether the time after indexing every unit.
This creates the possibility that a particularly large unit could cause
us to stop reporting progress for a while (even for units that have
already been indexed), but I don't think this is likely to happen,
because:
- Even the largest units don't take that long to index. The largest unit
in lldb (4MB of .debug_info) was indexed in "only" 200ms.
- The time is being checked and reported by all worker threads, which
means that in order to stall, we'd have to be very unfortunate and
pick up an extremely large compile unit on all indexing threads
simultaneously.
Even if that does happens, the only negative consequence is some
jitteriness in a progress bar, which is why I prefer this over
alternative implementations which e.g. involve reporting progress from a
dedicated thread.
---
.../SymbolFile/DWARF/ManualDWARFIndex.cpp | 31 ++-
1 file changed, 23 insertions(+), 8 deletions(-)
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/ManualDWARFIndex.cpp
b/lldb/source/Plugins/SymbolFile/DWARF/ManualDWARFIndex.cpp
index 5b325e30bef430..a3e595d0194eb9 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/ManualDWARFIndex.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/ManualDWARFIndex.cpp
@@ -24,6 +24,7 @@
#include "llvm/Support/FormatVariadic.h"
#include "llvm/Support/ThreadPool.h"
#include
+#include
#include
using namespace lldb_private;
@@ -91,14 +92,27 @@ void ManualDWARFIndex::Index() {
// are available. This is significantly faster than submiting a new task for
// each unit.
auto for_each_unit = [&](auto &&fn) {
-std::atomic next_cu_idx = 0;
-auto wrapper = [&fn, &next_cu_idx, &units_to_index,
-&progress](size_t worker_id) {
- size_t cu_idx;
- while ((cu_idx = next_cu_idx.fetch_add(1, std::memory_order_relaxed)) <
- units_to_index.size()) {
-fn(worker_id, cu_idx, units_to_index[cu_idx]);
-progress.Increment();
+std::atomic next_unit_idx = 0;
+std::atomic units_indexed = 0;
+auto wrapper = [&fn, &next_unit_idx, &units_indexed, &units_to_index,
+&progress, num_threads](size_t worker_id) {
+ constexpr auto progress_interval = std::chrono::milliseconds(10);
+
+ // Stagger the reports for different threads so we get a steady stream of
+ // one report per ~10ms.
+ auto next_report = std::chrono::steady_clock::now() +
+ progress_interval * (1 + worker_id);
+ size_t unit_idx;
+ while ((unit_idx = next_unit_idx.fetch_add(
+ 1, std::memory_order_relaxed)) < units_to_index.size()) {
+fn(worker_id, unit_idx, units_to_index[unit_idx]);
+
+units_indexed.fetch_add(1, std::memory_order_acq_rel);
+if (auto now = std::chrono::steady_clock::now(); now >= next_report) {
+ progress.Increment(
+ units_indexed.exchange(0, std::memory_order_acq_rel));
+ next_report = now + num_threads * progress_interval;
+
[Lldb-commits] [lldb] [LLDB][Process/Utility] Introduce NativeRegisterContextDBReg class (PR #118043)
@@ -9,79 +9,16 @@
#ifndef lldb_NativeRegisterContextDBReg_arm64_h
#define lldb_NativeRegisterContextDBReg_arm64_h
-#include "Plugins/Process/Utility/NativeRegisterContextRegisterInfo.h"
-
-#include
+#include "Plugins/Process/Utility/NativeRegisterContextDBReg.h"
namespace lldb_private {
-class NativeRegisterContextDBReg_arm64
-: public virtual NativeRegisterContextRegisterInfo {
-public:
- uint32_t NumSupportedHardwareBreakpoints() override;
-
- uint32_t SetHardwareBreakpoint(lldb::addr_t addr, size_t size) override;
-
- bool ClearHardwareBreakpoint(uint32_t hw_idx) override;
-
- Status ClearAllHardwareBreakpoints() override;
-
- Status GetHardwareBreakHitIndex(uint32_t &bp_index,
- lldb::addr_t trap_addr) override;
-
- bool BreakpointIsEnabled(uint32_t bp_index);
-
- uint32_t NumSupportedHardwareWatchpoints() override;
-
- uint32_t SetHardwareWatchpoint(lldb::addr_t addr, size_t size,
- uint32_t watch_flags) override;
-
- bool ClearHardwareWatchpoint(uint32_t hw_index) override;
-
- Status ClearAllHardwareWatchpoints() override;
-
- Status GetWatchpointHitIndex(uint32_t &wp_index,
- lldb::addr_t trap_addr) override;
-
- lldb::addr_t GetWatchpointHitAddress(uint32_t wp_index) override;
-
- lldb::addr_t GetWatchpointAddress(uint32_t wp_index) override;
-
- uint32_t GetWatchpointSize(uint32_t wp_index);
-
- bool WatchpointIsEnabled(uint32_t wp_index);
-
- // Debug register type select
- enum DREGType { eDREGTypeWATCH = 0, eDREGTypeBREAK };
-
-protected:
- /// Debug register info for hardware breakpoints and watchpoints management.
- /// Watchpoints: For a user requested size 4 at addr 0x1004, where BAS
- /// watchpoints are at doubleword (8-byte) alignment.
- /// \a real_addr is 0x1004
- /// \a address is 0x1000
- /// size is 8
- /// If a one-byte write to 0x1006 is the most recent watchpoint trap,
- /// \a hit_addr is 0x1006
- struct DREG {
-lldb::addr_t address; // Breakpoint/watchpoint address value.
-lldb::addr_t hit_addr; // Address at which last watchpoint trigger
exception
- // occurred.
-lldb::addr_t real_addr; // Address value that should cause target to stop.
-uint32_t control; // Breakpoint/watchpoint control value.
- };
-
- std::array m_hbp_regs; // hardware breakpoints
- std::array m_hwp_regs; // hardware watchpoints
+class NativeRegisterContextDBReg_arm64 : public NativeRegisterContextDBReg {
+ uint32_t GetWatchpointSize(uint32_t wp_index) override;
- uint32_t m_max_hbp_supported;
- uint32_t m_max_hwp_supported;
+ bool ValidateWatchpoint(size_t size, lldb::addr_t &addr) override;
DavidSpickett wrote:
addr_t is a uint64_t, it doesn't need to be a reference. And it being a
non-const ref makes it look like we're going to write back to addr, which we
don't.
https://github.com/llvm/llvm-project/pull/118043
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [lldb] [lldb] Analyze enum promotion type during parsing (PR #115005)
Michael137 wrote: > So, is this patch worth pursuing or is it too much code for a too specific > use case? Sorry I was out for a few weeks when you pinged. I'll have another pass/think about it early next week (if nobody else gets to it before me). https://github.com/llvm/llvm-project/pull/115005 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][Process/Utility] Introduce NativeRegisterContextDBReg class (PR #118043)
@@ -272,199 +57,27 @@ uint32_t
NativeRegisterContextDBReg_arm64::SetHardwareWatchpoint(
addr = addr & (~0x07);
}
-
- // Setup control value
- control_value = g_enable_bit | g_pac_bits | GetSizeBits(size);
- control_value |= watch_flags << 3;
-
- // Iterate over stored watchpoints and find a free wp_index
- wp_index = LLDB_INVALID_INDEX32;
- for (uint32_t i = 0; i < m_max_hwp_supported; i++) {
-if (!WatchpointIsEnabled(i))
- wp_index = i; // Mark last free slot
-else if (m_hwp_regs[i].address == addr) {
- return LLDB_INVALID_INDEX32; // We do not support duplicate watchpoints.
-}
- }
-
- if (wp_index == LLDB_INVALID_INDEX32)
-return LLDB_INVALID_INDEX32;
-
- // Update watchpoint in local cache
- m_hwp_regs[wp_index].real_addr = real_addr;
- m_hwp_regs[wp_index].address = addr;
- m_hwp_regs[wp_index].control = control_value;
-
- // PTRACE call to set corresponding watchpoint register.
- error = WriteHardwareDebugRegs(eDREGTypeWATCH);
-
- if (error) {
-m_hwp_regs[wp_index].address = 0;
-m_hwp_regs[wp_index].control &= ~g_enable_bit;
-
-LLDB_LOG_ERROR(
-log, std::move(error),
-"unable to set watchpoint: failed to write debug registers: {0}");
-return LLDB_INVALID_INDEX32;
- }
-
- return wp_index;
-}
-
-bool NativeRegisterContextDBReg_arm64::ClearHardwareWatchpoint(
-uint32_t wp_index) {
- Log *log = GetLog(LLDBLog::Watchpoints);
- LLDB_LOG(log, "wp_index: {0}", wp_index);
-
- // Read hardware breakpoint and watchpoint information.
- llvm::Error error = ReadHardwareDebugInfo();
- if (error) {
-LLDB_LOG_ERROR(
-log, std::move(error),
-"unable to clear watchpoint: failed to read debug registers: {0}");
-return false;
- }
-
- if (wp_index >= m_max_hwp_supported)
-return false;
-
- // Create a backup we can revert to in case of failure.
- lldb::addr_t tempAddr = m_hwp_regs[wp_index].address;
- uint32_t tempControl = m_hwp_regs[wp_index].control;
-
- // Update watchpoint in local cache
- m_hwp_regs[wp_index].control &= ~g_enable_bit;
- m_hwp_regs[wp_index].address = 0;
-
- // Ptrace call to update hardware debug registers
- error = WriteHardwareDebugRegs(eDREGTypeWATCH);
-
- if (error) {
-m_hwp_regs[wp_index].control = tempControl;
-m_hwp_regs[wp_index].address = tempAddr;
-
-LLDB_LOG_ERROR(
-log, std::move(error),
-"unable to clear watchpoint: failed to write debug registers: {0}");
-return false;
- }
-
return true;
}
-Status NativeRegisterContextDBReg_arm64::ClearAllHardwareWatchpoints() {
- // Read hardware breakpoint and watchpoint information.
- llvm::Error error = ReadHardwareDebugInfo();
- if (error)
-return Status::FromError(std::move(error));
-
- for (uint32_t i = 0; i < m_max_hwp_supported; i++) {
-if (WatchpointIsEnabled(i)) {
- // Create a backup we can revert to in case of failure.
- lldb::addr_t tempAddr = m_hwp_regs[i].address;
- uint32_t tempControl = m_hwp_regs[i].control;
-
- // Clear watchpoints in local cache
- m_hwp_regs[i].control &= ~g_enable_bit;
- m_hwp_regs[i].address = 0;
-
- // Ptrace call to update hardware debug registers
- error = WriteHardwareDebugRegs(eDREGTypeWATCH);
-
- if (error) {
-m_hwp_regs[i].control = tempControl;
-m_hwp_regs[i].address = tempAddr;
-
-return Status::FromError(std::move(error));
- }
-}
- }
-
- return Status();
-}
-
uint32_t
-NativeRegisterContextDBReg_arm64::GetWatchpointSize(uint32_t wp_index) {
- Log *log = GetLog(LLDBLog::Watchpoints);
- LLDB_LOG(log, "wp_index: {0}", wp_index);
+NativeRegisterContextDBReg_arm64::MakeControlValue(size_t size,
DavidSpickett wrote:
So 1st - yes, this is exactly the sort of thing I meant in my comments.
I think at minimum, the `watch_flags` should be `optional` but even
better would be to have:
MakeBreakControlValue
MakeWatchControlValue
Since I'm pretty sure we always know which one we want to use. This makes it
harder to misuse these functions.
https://github.com/llvm/llvm-project/pull/118043
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][Process/Utility] Introduce NativeRegisterContextDBReg class (PR #118043)
@@ -9,79 +9,16 @@
#ifndef lldb_NativeRegisterContextDBReg_arm64_h
#define lldb_NativeRegisterContextDBReg_arm64_h
-#include "Plugins/Process/Utility/NativeRegisterContextRegisterInfo.h"
-
-#include
+#include "Plugins/Process/Utility/NativeRegisterContextDBReg.h"
namespace lldb_private {
-class NativeRegisterContextDBReg_arm64
-: public virtual NativeRegisterContextRegisterInfo {
-public:
- uint32_t NumSupportedHardwareBreakpoints() override;
-
- uint32_t SetHardwareBreakpoint(lldb::addr_t addr, size_t size) override;
-
- bool ClearHardwareBreakpoint(uint32_t hw_idx) override;
-
- Status ClearAllHardwareBreakpoints() override;
-
- Status GetHardwareBreakHitIndex(uint32_t &bp_index,
- lldb::addr_t trap_addr) override;
-
- bool BreakpointIsEnabled(uint32_t bp_index);
-
- uint32_t NumSupportedHardwareWatchpoints() override;
-
- uint32_t SetHardwareWatchpoint(lldb::addr_t addr, size_t size,
- uint32_t watch_flags) override;
-
- bool ClearHardwareWatchpoint(uint32_t hw_index) override;
-
- Status ClearAllHardwareWatchpoints() override;
-
- Status GetWatchpointHitIndex(uint32_t &wp_index,
- lldb::addr_t trap_addr) override;
-
- lldb::addr_t GetWatchpointHitAddress(uint32_t wp_index) override;
-
- lldb::addr_t GetWatchpointAddress(uint32_t wp_index) override;
-
- uint32_t GetWatchpointSize(uint32_t wp_index);
-
- bool WatchpointIsEnabled(uint32_t wp_index);
-
- // Debug register type select
- enum DREGType { eDREGTypeWATCH = 0, eDREGTypeBREAK };
-
-protected:
- /// Debug register info for hardware breakpoints and watchpoints management.
- /// Watchpoints: For a user requested size 4 at addr 0x1004, where BAS
- /// watchpoints are at doubleword (8-byte) alignment.
- /// \a real_addr is 0x1004
- /// \a address is 0x1000
- /// size is 8
- /// If a one-byte write to 0x1006 is the most recent watchpoint trap,
- /// \a hit_addr is 0x1006
- struct DREG {
-lldb::addr_t address; // Breakpoint/watchpoint address value.
-lldb::addr_t hit_addr; // Address at which last watchpoint trigger
exception
- // occurred.
-lldb::addr_t real_addr; // Address value that should cause target to stop.
-uint32_t control; // Breakpoint/watchpoint control value.
- };
-
- std::array m_hbp_regs; // hardware breakpoints
- std::array m_hwp_regs; // hardware watchpoints
+class NativeRegisterContextDBReg_arm64 : public NativeRegisterContextDBReg {
+ uint32_t GetWatchpointSize(uint32_t wp_index) override;
- uint32_t m_max_hbp_supported;
- uint32_t m_max_hwp_supported;
+ bool ValidateWatchpoint(size_t size, lldb::addr_t &addr) override;
DavidSpickett wrote:
Ok, actually we do :rofl:
This is unfortunate because "Validate" implies we don't mutate anything.
I would split this into Validate that is purely is it valid yes or no, and
AdjustWatchpoint that takes a copy of the address and returns a new value.
https://github.com/llvm/llvm-project/pull/118043
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][Process/Utility] Introduce NativeRegisterContextDBReg class (PR #118043)
DavidSpickett wrote: The test failures were caused by: ``` virtual bool ValidateWatchpoint(size_t size, lldb::addr_t &addr) = 0; ``` Which is actually trying to change size for AArch64, but it's passed by copy so it wasn't being updated in the caller. See my comments on those lines. With that fixed, the test suite passes. If you address that, I'll test this again. If it's all working then you can address @SixWeining 's style suggestions from the original PR, and I'll have a few of my own. https://github.com/llvm/llvm-project/pull/118043 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][Process/Utility] Introduce NativeRegisterContextDBReg class (PR #118043)
@@ -9,79 +9,16 @@
#ifndef lldb_NativeRegisterContextDBReg_arm64_h
#define lldb_NativeRegisterContextDBReg_arm64_h
-#include "Plugins/Process/Utility/NativeRegisterContextRegisterInfo.h"
-
-#include
+#include "Plugins/Process/Utility/NativeRegisterContextDBReg.h"
namespace lldb_private {
-class NativeRegisterContextDBReg_arm64
-: public virtual NativeRegisterContextRegisterInfo {
-public:
- uint32_t NumSupportedHardwareBreakpoints() override;
-
- uint32_t SetHardwareBreakpoint(lldb::addr_t addr, size_t size) override;
-
- bool ClearHardwareBreakpoint(uint32_t hw_idx) override;
-
- Status ClearAllHardwareBreakpoints() override;
-
- Status GetHardwareBreakHitIndex(uint32_t &bp_index,
- lldb::addr_t trap_addr) override;
-
- bool BreakpointIsEnabled(uint32_t bp_index);
-
- uint32_t NumSupportedHardwareWatchpoints() override;
-
- uint32_t SetHardwareWatchpoint(lldb::addr_t addr, size_t size,
- uint32_t watch_flags) override;
-
- bool ClearHardwareWatchpoint(uint32_t hw_index) override;
-
- Status ClearAllHardwareWatchpoints() override;
-
- Status GetWatchpointHitIndex(uint32_t &wp_index,
- lldb::addr_t trap_addr) override;
-
- lldb::addr_t GetWatchpointHitAddress(uint32_t wp_index) override;
-
- lldb::addr_t GetWatchpointAddress(uint32_t wp_index) override;
-
- uint32_t GetWatchpointSize(uint32_t wp_index);
-
- bool WatchpointIsEnabled(uint32_t wp_index);
-
- // Debug register type select
- enum DREGType { eDREGTypeWATCH = 0, eDREGTypeBREAK };
-
-protected:
- /// Debug register info for hardware breakpoints and watchpoints management.
- /// Watchpoints: For a user requested size 4 at addr 0x1004, where BAS
- /// watchpoints are at doubleword (8-byte) alignment.
- /// \a real_addr is 0x1004
- /// \a address is 0x1000
- /// size is 8
- /// If a one-byte write to 0x1006 is the most recent watchpoint trap,
- /// \a hit_addr is 0x1006
- struct DREG {
-lldb::addr_t address; // Breakpoint/watchpoint address value.
-lldb::addr_t hit_addr; // Address at which last watchpoint trigger
exception
- // occurred.
-lldb::addr_t real_addr; // Address value that should cause target to stop.
-uint32_t control; // Breakpoint/watchpoint control value.
- };
-
- std::array m_hbp_regs; // hardware breakpoints
- std::array m_hwp_regs; // hardware watchpoints
+class NativeRegisterContextDBReg_arm64 : public NativeRegisterContextDBReg {
+ uint32_t GetWatchpointSize(uint32_t wp_index) override;
- uint32_t m_max_hbp_supported;
- uint32_t m_max_hwp_supported;
+ bool ValidateWatchpoint(size_t size, lldb::addr_t &addr) override;
DavidSpickett wrote:
Also this function has a bug, size is assigned to but it is passed by copy.
This was the cause of the test failures.
I suggest you change this to a single AdjustWatchpoint that takes two
parameters by reference, and returns true if it was able to adjust it and false
otherwise.
https://github.com/llvm/llvm-project/pull/118043
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][Process/Utility] Introduce NativeRegisterContextDBReg class (PR #118043)
@@ -9,79 +9,16 @@
#ifndef lldb_NativeRegisterContextDBReg_arm64_h
#define lldb_NativeRegisterContextDBReg_arm64_h
-#include "Plugins/Process/Utility/NativeRegisterContextRegisterInfo.h"
-
-#include
+#include "Plugins/Process/Utility/NativeRegisterContextDBReg.h"
namespace lldb_private {
-class NativeRegisterContextDBReg_arm64
-: public virtual NativeRegisterContextRegisterInfo {
-public:
- uint32_t NumSupportedHardwareBreakpoints() override;
-
- uint32_t SetHardwareBreakpoint(lldb::addr_t addr, size_t size) override;
-
- bool ClearHardwareBreakpoint(uint32_t hw_idx) override;
-
- Status ClearAllHardwareBreakpoints() override;
-
- Status GetHardwareBreakHitIndex(uint32_t &bp_index,
- lldb::addr_t trap_addr) override;
-
- bool BreakpointIsEnabled(uint32_t bp_index);
-
- uint32_t NumSupportedHardwareWatchpoints() override;
-
- uint32_t SetHardwareWatchpoint(lldb::addr_t addr, size_t size,
- uint32_t watch_flags) override;
-
- bool ClearHardwareWatchpoint(uint32_t hw_index) override;
-
- Status ClearAllHardwareWatchpoints() override;
-
- Status GetWatchpointHitIndex(uint32_t &wp_index,
- lldb::addr_t trap_addr) override;
-
- lldb::addr_t GetWatchpointHitAddress(uint32_t wp_index) override;
-
- lldb::addr_t GetWatchpointAddress(uint32_t wp_index) override;
-
- uint32_t GetWatchpointSize(uint32_t wp_index);
-
- bool WatchpointIsEnabled(uint32_t wp_index);
-
- // Debug register type select
- enum DREGType { eDREGTypeWATCH = 0, eDREGTypeBREAK };
-
-protected:
- /// Debug register info for hardware breakpoints and watchpoints management.
- /// Watchpoints: For a user requested size 4 at addr 0x1004, where BAS
- /// watchpoints are at doubleword (8-byte) alignment.
- /// \a real_addr is 0x1004
- /// \a address is 0x1000
- /// size is 8
- /// If a one-byte write to 0x1006 is the most recent watchpoint trap,
- /// \a hit_addr is 0x1006
- struct DREG {
-lldb::addr_t address; // Breakpoint/watchpoint address value.
-lldb::addr_t hit_addr; // Address at which last watchpoint trigger
exception
- // occurred.
-lldb::addr_t real_addr; // Address value that should cause target to stop.
-uint32_t control; // Breakpoint/watchpoint control value.
- };
-
- std::array m_hbp_regs; // hardware breakpoints
- std::array m_hwp_regs; // hardware watchpoints
+class NativeRegisterContextDBReg_arm64 : public NativeRegisterContextDBReg {
+ uint32_t GetWatchpointSize(uint32_t wp_index) override;
- uint32_t m_max_hbp_supported;
- uint32_t m_max_hwp_supported;
+ bool ValidateWatchpoint(size_t size, lldb::addr_t &addr) override;
DavidSpickett wrote:
If we want to prevent this sort of mistake it could be:
```
struct WatchpointDetails {
size_t size;
lldb::addr_t addr;
}
std::optional AdjustWatchpoint(const WatchPointDetails
&details);
```
This is at least clearer that:
* This can fail (empty optional)
* New values are returned not assigned by reference
https://github.com/llvm/llvm-project/pull/118043
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Include `` for `system_clock` and `now` (PR #118059)
LilyWangLL wrote: > (Please let us know if you need someone to press the merge button for you) Please merge this PR, thanks~ https://github.com/llvm/llvm-project/pull/118059 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Fix the SocketTest failure on unsupported hosts (PR #118673)
@@ -116,6 +116,30 @@ bool lldb_private::HostSupportsIPv6() {
return CheckIPSupport("IPv6", "[::1]:0");
}
+bool lldb_private::HostSupportsLocalhostToIPv4() {
+ if (!HostSupportsIPv4())
+return false;
+
+ auto addresses = SocketAddress::GetAddressInfo(
+ "localhost", nullptr, AF_UNSPEC, SOCK_STREAM, IPPROTO_TCP);
+ return std::find_if(addresses.begin(), addresses.end(),
+ [](SocketAddress &addr) {
+return addr.GetFamily() == AF_INET;
+ }) != addresses.end();
labath wrote:
Just a small llvm-ization:
```
return llvm::any_of(addresses, [](const SocketAddress &addr) { return
addr.GetFamily() == AF_INET; });
```
https://github.com/llvm/llvm-project/pull/118673
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Reduce the frequency of DWARF index progress reporting (PR #118953)
SingleAccretion wrote: I would like to say I would love for this improvement to land :). I have observed that on Windows with a good number (4K+) of small compile units the progress reporting completely dominates indexing time due to contention (presumably not just in the lock but also the IO layers), to the point that disabling it resulted in __very__ large speedup (an operation which previously took 5s+ now was almost instant). https://github.com/llvm/llvm-project/pull/118953 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][Process/Utility] Introduce NativeRegisterContextDBReg class (PR #118043)
DavidSpickett wrote: Something is up with watchpoints: ``` Failed Tests (12): lldb-api :: commands/watchpoints/multi_watchpoint_slots/TestWatchpointMultipleSlots.py lldb-api :: commands/watchpoints/watchpoint_commands/command/TestWatchpointCommandLLDB.py lldb-api :: commands/watchpoints/watchpoint_commands/command/TestWatchpointCommandPython.py lldb-api :: commands/watchpoints/watchpoint_commands/condition/TestWatchpointConditionCmd.py lldb-api :: commands/watchpoints/watchpoint_size/TestWatchpointSizes.py lldb-api :: python_api/watchpoint/condition/TestWatchpointConditionAPI.py lldb-api :: tools/lldb-dap/databreakpoint/TestDAP_setDataBreakpoints.py lldb-shell :: Subprocess/clone-follow-child-wp.test lldb-shell :: Subprocess/clone-follow-parent-wp.test lldb-shell :: Subprocess/fork-follow-child-wp.test lldb-shell :: Subprocess/fork-follow-parent-wp.test lldb-shell :: Subprocess/vfork-follow-parent-wp.test ``` I'm digging into it now. https://github.com/llvm/llvm-project/pull/118043 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add lookup by name to SBValue.child (PR #118814)
@@ -23,6 +23,13 @@ STRING_EXTENSION_OUTSIDE(SBValue) if -count <= key < count: key %= count return self.sbvalue.GetChildAtIndex(key) +elif isinstance(key, str): +if child := self.sbvalue.GetChildMemberWithName(key): +return child +# Support base classes, which are children but not members. +for child in self.sbvalue: +if child.name == key: +return child labath wrote: I don't think this is a good idea, as it means every negative lookup could end up enumerating all children of the object -- and there could be millions of them. If you really want to support looking up base classes (*), I think it should be done by iterating through the base base classes. * I actually think we shouldn't be providing extra functionality here -- at least unless GetChildMemberWithName supports that as well. I think the fact that `operator[](string)` is shorthand for `GetChildMemberWithName(string)` makes things easy to understand. I think it'd be confusing if one of them provided functionality which is not available in the other one. You'd also have to be very careful about handling data formatters -- they can provide synthetic children, but not "synthetic base classes". https://github.com/llvm/llvm-project/pull/118814 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add lookup by name to SBValue.child (PR #118814)
https://github.com/labath edited https://github.com/llvm/llvm-project/pull/118814 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 72aefbb - [lldb] Include `` for `system_clock` and `now` (#118059)
Author: Lily Wang Date: 2024-12-06T09:18:00Z New Revision: 72aefbb5d06f3b82ded6fa499c3994f5d03aba57 URL: https://github.com/llvm/llvm-project/commit/72aefbb5d06f3b82ded6fa499c3994f5d03aba57 DIFF: https://github.com/llvm/llvm-project/commit/72aefbb5d06f3b82ded6fa499c3994f5d03aba57.diff LOG: [lldb] Include `` for `system_clock` and `now` (#118059) I am a member of Microsoft vcpkg, due to there are new changes merged by microsoft/STL#5105, which revealed a conformance issue in `llvm`. It must add include `` to fix this error. Compiler error with this STL change: ``` D:\b\llvm\src\org-18.1.6-e754cb1d0b.clean\lldb\tools\lldb-dap\ProgressEvent.h(79): error C2039: 'system_clock': is not a member of 'std::chrono' D:\b\llvm\src\org-18.1.6-e754cb1d0b.clean\lldb\tools\lldb-dap\ProgressEvent.cpp(134): error C3083: 'system_clock': the symbol to the left of a '::' must be a type D:\b\llvm\src\org-18.1.6-e754cb1d0b.clean\lldb\tools\lldb-dap\ProgressEvent.cpp(134): error C2039: 'now': is not a member of 'std::chrono' ``` Added: Modified: lldb/tools/lldb-dap/ProgressEvent.h Removed: diff --git a/lldb/tools/lldb-dap/ProgressEvent.h b/lldb/tools/lldb-dap/ProgressEvent.h index dac21977add2d0..72317b879c803a 100644 --- a/lldb/tools/lldb-dap/ProgressEvent.h +++ b/lldb/tools/lldb-dap/ProgressEvent.h @@ -7,6 +7,7 @@ //===--===// #include +#include #include #include #include ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Include `` for `system_clock` and `now` (PR #118059)
https://github.com/DavidSpickett closed https://github.com/llvm/llvm-project/pull/118059 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Include `` for `system_clock` and `now` (PR #118059)
github-actions[bot] wrote: @LilyWangLL Congratulations on having your first Pull Request (PR) merged into the LLVM Project! Your changes will be combined with recent changes from other authors, then tested by our [build bots](https://lab.llvm.org/buildbot/). If there is a problem with a build, you may receive a report in an email or a comment on this PR. Please check whether problems have been caused by your change specifically, as the builds can include changes from many authors. It is not uncommon for your change to be included in a build that fails due to someone else's changes, or infrastructure issues. How to do this, and the rest of the post-merge process, is covered in detail [here](https://llvm.org/docs/MyFirstTypoFix.html#myfirsttypofix-issues-after-landing-your-pr). If your change does cause a problem, it may be reverted, or you can revert it yourself. This is a normal part of [LLVM development](https://llvm.org/docs/DeveloperPolicy.html#patch-reversion-policy). You can fix your changes and open a new PR to merge them again. If you don't get any reports, no action is required from you. Your changes are working as expected, well done! https://github.com/llvm/llvm-project/pull/118059 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add a per-CU API to read the SDK (PR #119022)
@@ -473,6 +473,32 @@ class Platform : public PluginInterface {
LLVM_PRETTY_FUNCTION, GetName()));
}
+ /// Search CU for the SDK path the CUs was compiled against.
+ ///
+ /// \param[in] unit The CU
+ ///
+ /// \returns If successful, returns a parsed XcodeSDK object.
JDevlieghere wrote:
Nit/suggestion:
```suggestion
/// \returns A parsed XcodeSDK object if successful, an Error otherwise.
```
https://github.com/llvm/llvm-project/pull/119022
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add a per-CU API to read the SDK (PR #119022)
@@ -473,6 +473,32 @@ class Platform : public PluginInterface {
LLVM_PRETTY_FUNCTION, GetName()));
}
+ /// Search CU for the SDK path the CUs was compiled against.
+ ///
+ /// \param[in] unit The CU
+ ///
+ /// \returns If successful, returns a parsed XcodeSDK object.
+ virtual llvm::Expected GetSDKPathFromDebugInfo(CompileUnit &unit) {
+return llvm::createStringError(
+llvm::formatv("{0} not implemented for '{1}' platform.",
+ LLVM_PRETTY_FUNCTION, GetName()));
+ }
+
+ /// Returns the full path of the most appropriate SDK for the
+ /// specified compile unit. This function gets this path by parsing
+ /// debug-info (see \ref `GetSDKPathFromDebugInfo`).
+ ///
+ /// \param[in] unit The CU to scan.
+ ///
+ /// \returns If successful, returns the full path to an
+ /// Xcode SDK.
+ virtual llvm::Expected
JDevlieghere wrote:
Should this return a `FileSpec` if it's a path?
https://github.com/llvm/llvm-project/pull/119022
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add a per-CU API to read the SDK (PR #119022)
https://github.com/JDevlieghere edited https://github.com/llvm/llvm-project/pull/119022 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add a per-CU API to read the SDK (PR #119022)
https://github.com/adrian-prantl updated
https://github.com/llvm/llvm-project/pull/119022
>From 60ab35f50652e761d465cc1410b8d3352fa86b3f Mon Sep 17 00:00:00 2001
From: Adrian Prantl
Date: Fri, 6 Dec 2024 12:09:27 -0800
Subject: [PATCH] [lldb] Add a per-CU API to read the SDK.
This is needed by the Swift plugin.
---
lldb/include/lldb/Target/Platform.h | 26 +
.../Platform/MacOSX/PlatformDarwin.cpp| 37 +++
.../Plugins/Platform/MacOSX/PlatformDarwin.h | 5 +++
.../SymbolFile/DWARF/XcodeSDKModuleTests.cpp | 7
4 files changed, 75 insertions(+)
diff --git a/lldb/include/lldb/Target/Platform.h
b/lldb/include/lldb/Target/Platform.h
index f8a2cbf0d5d049..fc08e7c4096add 100644
--- a/lldb/include/lldb/Target/Platform.h
+++ b/lldb/include/lldb/Target/Platform.h
@@ -473,6 +473,32 @@ class Platform : public PluginInterface {
LLVM_PRETTY_FUNCTION, GetName()));
}
+ /// Search CU for the SDK path the CUs was compiled against.
+ ///
+ /// \param[in] unit The CU
+ ///
+ /// \returns If successful, returns a parsed XcodeSDK object.
+ virtual llvm::Expected GetSDKPathFromDebugInfo(CompileUnit &unit) {
+return llvm::createStringError(
+llvm::formatv("{0} not implemented for '{1}' platform.",
+ LLVM_PRETTY_FUNCTION, GetName()));
+ }
+
+ /// Returns the full path of the most appropriate SDK for the
+ /// specified compile unit. This function gets this path by parsing
+ /// debug-info (see \ref `GetSDKPathFromDebugInfo`).
+ ///
+ /// \param[in] unit The CU to scan.
+ ///
+ /// \returns If successful, returns the full path to an
+ /// Xcode SDK.
+ virtual llvm::Expected
+ ResolveSDKPathFromDebugInfo(CompileUnit &unit) {
+return llvm::createStringError(
+llvm::formatv("{0} not implemented for '{1}' platform.",
+ LLVM_PRETTY_FUNCTION, GetName()));
+ }
+
bool IsHost() const {
return m_is_host; // Is this the default host platform?
}
diff --git a/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
b/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
index ed0c614cb3576b..8baf3a8d60c373 100644
--- a/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
+++ b/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
@@ -29,6 +29,7 @@
#include "lldb/Interpreter/OptionValueProperties.h"
#include "lldb/Interpreter/OptionValueString.h"
#include "lldb/Interpreter/Options.h"
+#include "lldb/Symbol/CompileUnit.h"
#include "lldb/Symbol/ObjectFile.h"
#include "lldb/Symbol/SymbolFile.h"
#include "lldb/Symbol/SymbolVendor.h"
@@ -1429,3 +1430,39 @@ PlatformDarwin::ResolveSDKPathFromDebugInfo(Module
&module) {
return path_or_err->str();
}
+
+llvm::Expected
+PlatformDarwin::GetSDKPathFromDebugInfo(CompileUnit &unit) {
+ ModuleSP module_sp = unit.CalculateSymbolContextModule();
+ if (!module_sp)
+return llvm::createStringError("compile unit has no module");
+ SymbolFile *sym_file = module_sp->GetSymbolFile();
+ if (!sym_file)
+return llvm::createStringError(
+llvm::formatv("No symbol file available for module '{0}'",
+ module_sp->GetFileSpec().GetFilename()));
+
+ return sym_file->ParseXcodeSDK(unit);
+}
+
+llvm::Expected
+PlatformDarwin::ResolveSDKPathFromDebugInfo(CompileUnit &unit) {
+ auto sdk_or_err = GetSDKPathFromDebugInfo(unit);
+ if (!sdk_or_err)
+return llvm::createStringError(
+llvm::inconvertibleErrorCode(),
+llvm::formatv("Failed to parse SDK path from debug-info: {0}",
+ llvm::toString(sdk_or_err.takeError(;
+
+ auto sdk = std::move(*sdk_or_err);
+
+ auto path_or_err = HostInfo::GetSDKRoot(HostInfo::SDKOptions{sdk});
+ if (!path_or_err)
+return llvm::createStringError(
+llvm::inconvertibleErrorCode(),
+llvm::formatv("Error while searching for SDK (XcodeSDK '{0}'): {1}",
+ sdk.GetString(),
+ llvm::toString(path_or_err.takeError(;
+
+ return path_or_err->str();
+}
diff --git a/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h
b/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h
index 66a26d2f496776..e2d4cb6726d585 100644
--- a/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h
+++ b/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h
@@ -130,6 +130,11 @@ class PlatformDarwin : public PlatformPOSIX {
llvm::Expected
ResolveSDKPathFromDebugInfo(Module &module) override;
+ llvm::Expected GetSDKPathFromDebugInfo(CompileUnit &unit) override;
+
+ llvm::Expected
+ ResolveSDKPathFromDebugInfo(CompileUnit &unit) override;
+
protected:
static const char *GetCompatibleArch(ArchSpec::Core core, size_t idx);
diff --git a/lldb/unittests/SymbolFile/DWARF/XcodeSDKModuleTests.cpp
b/lldb/unittests/SymbolFile/DWARF/XcodeSDKModuleTests.cpp
index f1998a92f19b05..fc008ca7011e44 100644
--- a/lldb/unittests/SymbolFile/DWARF/XcodeSDKModuleTests.cpp
+++ b/lldb/unittests/Sy
[Lldb-commits] [lldb] [lldb] Add a per-CU API to read the SDK (PR #119022)
@@ -1429,3 +1430,40 @@ PlatformDarwin::ResolveSDKPathFromDebugInfo(Module
&module) {
return path_or_err->str();
}
+
+llvm::Expected>
+PlatformDarwin::GetSDKPathFromDebugInfo(CompileUnit &unit) {
+ ModuleSP module_sp = unit.CalculateSymbolContextModule();
+ if (!module_sp)
+return llvm::createStringError("compile unit has no module");
+ SymbolFile *sym_file = module_sp->GetSymbolFile();
+ if (!sym_file)
+return llvm::createStringError(
+llvm::formatv("No symbol file available for module '{0}'",
+ module_sp->GetFileSpec().GetFilename()));
+
+ const bool found_mismatch = false;
adrian-prantl wrote:
@medismailben updated!
https://github.com/llvm/llvm-project/pull/119022
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add a per-CU API to read the SDK (PR #119022)
https://github.com/JDevlieghere approved this pull request. LGTM. https://github.com/llvm/llvm-project/pull/119022 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add a per-CU API to read the SDK (PR #119022)
https://github.com/adrian-prantl updated
https://github.com/llvm/llvm-project/pull/119022
>From 60ab35f50652e761d465cc1410b8d3352fa86b3f Mon Sep 17 00:00:00 2001
From: Adrian Prantl
Date: Fri, 6 Dec 2024 12:09:27 -0800
Subject: [PATCH 1/2] [lldb] Add a per-CU API to read the SDK.
This is needed by the Swift plugin.
---
lldb/include/lldb/Target/Platform.h | 26 +
.../Platform/MacOSX/PlatformDarwin.cpp| 37 +++
.../Plugins/Platform/MacOSX/PlatformDarwin.h | 5 +++
.../SymbolFile/DWARF/XcodeSDKModuleTests.cpp | 7
4 files changed, 75 insertions(+)
diff --git a/lldb/include/lldb/Target/Platform.h
b/lldb/include/lldb/Target/Platform.h
index f8a2cbf0d5d049..fc08e7c4096add 100644
--- a/lldb/include/lldb/Target/Platform.h
+++ b/lldb/include/lldb/Target/Platform.h
@@ -473,6 +473,32 @@ class Platform : public PluginInterface {
LLVM_PRETTY_FUNCTION, GetName()));
}
+ /// Search CU for the SDK path the CUs was compiled against.
+ ///
+ /// \param[in] unit The CU
+ ///
+ /// \returns If successful, returns a parsed XcodeSDK object.
+ virtual llvm::Expected GetSDKPathFromDebugInfo(CompileUnit &unit) {
+return llvm::createStringError(
+llvm::formatv("{0} not implemented for '{1}' platform.",
+ LLVM_PRETTY_FUNCTION, GetName()));
+ }
+
+ /// Returns the full path of the most appropriate SDK for the
+ /// specified compile unit. This function gets this path by parsing
+ /// debug-info (see \ref `GetSDKPathFromDebugInfo`).
+ ///
+ /// \param[in] unit The CU to scan.
+ ///
+ /// \returns If successful, returns the full path to an
+ /// Xcode SDK.
+ virtual llvm::Expected
+ ResolveSDKPathFromDebugInfo(CompileUnit &unit) {
+return llvm::createStringError(
+llvm::formatv("{0} not implemented for '{1}' platform.",
+ LLVM_PRETTY_FUNCTION, GetName()));
+ }
+
bool IsHost() const {
return m_is_host; // Is this the default host platform?
}
diff --git a/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
b/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
index ed0c614cb3576b..8baf3a8d60c373 100644
--- a/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
+++ b/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
@@ -29,6 +29,7 @@
#include "lldb/Interpreter/OptionValueProperties.h"
#include "lldb/Interpreter/OptionValueString.h"
#include "lldb/Interpreter/Options.h"
+#include "lldb/Symbol/CompileUnit.h"
#include "lldb/Symbol/ObjectFile.h"
#include "lldb/Symbol/SymbolFile.h"
#include "lldb/Symbol/SymbolVendor.h"
@@ -1429,3 +1430,39 @@ PlatformDarwin::ResolveSDKPathFromDebugInfo(Module
&module) {
return path_or_err->str();
}
+
+llvm::Expected
+PlatformDarwin::GetSDKPathFromDebugInfo(CompileUnit &unit) {
+ ModuleSP module_sp = unit.CalculateSymbolContextModule();
+ if (!module_sp)
+return llvm::createStringError("compile unit has no module");
+ SymbolFile *sym_file = module_sp->GetSymbolFile();
+ if (!sym_file)
+return llvm::createStringError(
+llvm::formatv("No symbol file available for module '{0}'",
+ module_sp->GetFileSpec().GetFilename()));
+
+ return sym_file->ParseXcodeSDK(unit);
+}
+
+llvm::Expected
+PlatformDarwin::ResolveSDKPathFromDebugInfo(CompileUnit &unit) {
+ auto sdk_or_err = GetSDKPathFromDebugInfo(unit);
+ if (!sdk_or_err)
+return llvm::createStringError(
+llvm::inconvertibleErrorCode(),
+llvm::formatv("Failed to parse SDK path from debug-info: {0}",
+ llvm::toString(sdk_or_err.takeError(;
+
+ auto sdk = std::move(*sdk_or_err);
+
+ auto path_or_err = HostInfo::GetSDKRoot(HostInfo::SDKOptions{sdk});
+ if (!path_or_err)
+return llvm::createStringError(
+llvm::inconvertibleErrorCode(),
+llvm::formatv("Error while searching for SDK (XcodeSDK '{0}'): {1}",
+ sdk.GetString(),
+ llvm::toString(path_or_err.takeError(;
+
+ return path_or_err->str();
+}
diff --git a/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h
b/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h
index 66a26d2f496776..e2d4cb6726d585 100644
--- a/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h
+++ b/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h
@@ -130,6 +130,11 @@ class PlatformDarwin : public PlatformPOSIX {
llvm::Expected
ResolveSDKPathFromDebugInfo(Module &module) override;
+ llvm::Expected GetSDKPathFromDebugInfo(CompileUnit &unit) override;
+
+ llvm::Expected
+ ResolveSDKPathFromDebugInfo(CompileUnit &unit) override;
+
protected:
static const char *GetCompatibleArch(ArchSpec::Core core, size_t idx);
diff --git a/lldb/unittests/SymbolFile/DWARF/XcodeSDKModuleTests.cpp
b/lldb/unittests/SymbolFile/DWARF/XcodeSDKModuleTests.cpp
index f1998a92f19b05..fc008ca7011e44 100644
--- a/lldb/unittests/SymbolFile/DWARF/XcodeSDKModuleTests.cpp
+++ b/lldb/unittest
[Lldb-commits] [lldb] [lldb] Add a per-CU API to read the SDK (PR #119022)
@@ -473,6 +473,32 @@ class Platform : public PluginInterface {
LLVM_PRETTY_FUNCTION, GetName()));
}
+ /// Search CU for the SDK path the CUs was compiled against.
+ ///
+ /// \param[in] unit The CU
+ ///
+ /// \returns If successful, returns a parsed XcodeSDK object.
+ virtual llvm::Expected GetSDKPathFromDebugInfo(CompileUnit &unit) {
+return llvm::createStringError(
+llvm::formatv("{0} not implemented for '{1}' platform.",
+ LLVM_PRETTY_FUNCTION, GetName()));
+ }
+
+ /// Returns the full path of the most appropriate SDK for the
+ /// specified compile unit. This function gets this path by parsing
+ /// debug-info (see \ref `GetSDKPathFromDebugInfo`).
+ ///
+ /// \param[in] unit The CU to scan.
+ ///
+ /// \returns If successful, returns the full path to an
+ /// Xcode SDK.
+ virtual llvm::Expected
adrian-prantl wrote:
Possibly, but none of the sibling APIs use FileSpecs either.
https://github.com/llvm/llvm-project/pull/119022
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add a per-CU API to read the SDK (PR #119022)
@@ -473,6 +473,32 @@ class Platform : public PluginInterface {
LLVM_PRETTY_FUNCTION, GetName()));
}
+ /// Search CU for the SDK path the CUs was compiled against.
+ ///
+ /// \param[in] unit The CU
+ ///
+ /// \returns If successful, returns a parsed XcodeSDK object.
+ virtual llvm::Expected GetSDKPathFromDebugInfo(CompileUnit &unit) {
+return llvm::createStringError(
+llvm::formatv("{0} not implemented for '{1}' platform.",
+ LLVM_PRETTY_FUNCTION, GetName()));
+ }
+
+ /// Returns the full path of the most appropriate SDK for the
+ /// specified compile unit. This function gets this path by parsing
+ /// debug-info (see \ref `GetSDKPathFromDebugInfo`).
+ ///
+ /// \param[in] unit The CU to scan.
+ ///
+ /// \returns If successful, returns the full path to an
+ /// Xcode SDK.
+ virtual llvm::Expected
JDevlieghere wrote:
Ok, consistency wins then.
https://github.com/llvm/llvm-project/pull/119022
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add a per-CU API to read the SDK (PR #119022)
https://github.com/Alexizx0078 approved this pull request. https://github.com/llvm/llvm-project/pull/119022 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add a per-CU API to read the SDK (PR #119022)
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff 1d95825d4d168a17a4f27401dec3f2977a59a70e
4facb5fc17280c27af99b014e621f7a573afb929 --extensions h,cpp --
lldb/include/lldb/Target/Platform.h
lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h
lldb/unittests/SymbolFile/DWARF/XcodeSDKModuleTests.cpp
``
View the diff from clang-format here.
``diff
diff --git a/lldb/include/lldb/Target/Platform.h
b/lldb/include/lldb/Target/Platform.h
index a702abb540..d6864798ea 100644
--- a/lldb/include/lldb/Target/Platform.h
+++ b/lldb/include/lldb/Target/Platform.h
@@ -477,7 +477,7 @@ public:
///
/// \param[in] unit The CU
///
- /// \returns A parsed XcodeSDK object if successful, an Error otherwise.
+ /// \returns A parsed XcodeSDK object if successful, an Error otherwise.
virtual llvm::Expected GetSDKPathFromDebugInfo(CompileUnit &unit) {
return llvm::createStringError(
llvm::formatv("{0} not implemented for '{1}' platform.",
``
https://github.com/llvm/llvm-project/pull/119022
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 01d8e0f - [lldb] Add a per-CU API to read the SDK (#119022)
Author: Adrian Prantl
Date: 2024-12-06T14:14:11-08:00
New Revision: 01d8e0fc75a897a6a9c2ce634645457a895ed505
URL:
https://github.com/llvm/llvm-project/commit/01d8e0fc75a897a6a9c2ce634645457a895ed505
DIFF:
https://github.com/llvm/llvm-project/commit/01d8e0fc75a897a6a9c2ce634645457a895ed505.diff
LOG: [lldb] Add a per-CU API to read the SDK (#119022)
The Swift plugin would find this useful.
Added:
Modified:
lldb/include/lldb/Target/Platform.h
lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h
lldb/unittests/SymbolFile/DWARF/XcodeSDKModuleTests.cpp
Removed:
diff --git a/lldb/include/lldb/Target/Platform.h
b/lldb/include/lldb/Target/Platform.h
index f8a2cbf0d5d049..a702abb540fd93 100644
--- a/lldb/include/lldb/Target/Platform.h
+++ b/lldb/include/lldb/Target/Platform.h
@@ -473,6 +473,32 @@ class Platform : public PluginInterface {
LLVM_PRETTY_FUNCTION, GetName()));
}
+ /// Search CU for the SDK path the CUs was compiled against.
+ ///
+ /// \param[in] unit The CU
+ ///
+ /// \returns A parsed XcodeSDK object if successful, an Error otherwise.
+ virtual llvm::Expected GetSDKPathFromDebugInfo(CompileUnit &unit) {
+return llvm::createStringError(
+llvm::formatv("{0} not implemented for '{1}' platform.",
+ LLVM_PRETTY_FUNCTION, GetName()));
+ }
+
+ /// Returns the full path of the most appropriate SDK for the
+ /// specified compile unit. This function gets this path by parsing
+ /// debug-info (see \ref `GetSDKPathFromDebugInfo`).
+ ///
+ /// \param[in] unit The CU to scan.
+ ///
+ /// \returns If successful, returns the full path to an
+ /// Xcode SDK.
+ virtual llvm::Expected
+ ResolveSDKPathFromDebugInfo(CompileUnit &unit) {
+return llvm::createStringError(
+llvm::formatv("{0} not implemented for '{1}' platform.",
+ LLVM_PRETTY_FUNCTION, GetName()));
+ }
+
bool IsHost() const {
return m_is_host; // Is this the default host platform?
}
diff --git a/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
b/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
index ed0c614cb3576b..8baf3a8d60c373 100644
--- a/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
+++ b/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
@@ -29,6 +29,7 @@
#include "lldb/Interpreter/OptionValueProperties.h"
#include "lldb/Interpreter/OptionValueString.h"
#include "lldb/Interpreter/Options.h"
+#include "lldb/Symbol/CompileUnit.h"
#include "lldb/Symbol/ObjectFile.h"
#include "lldb/Symbol/SymbolFile.h"
#include "lldb/Symbol/SymbolVendor.h"
@@ -1429,3 +1430,39 @@ PlatformDarwin::ResolveSDKPathFromDebugInfo(Module
&module) {
return path_or_err->str();
}
+
+llvm::Expected
+PlatformDarwin::GetSDKPathFromDebugInfo(CompileUnit &unit) {
+ ModuleSP module_sp = unit.CalculateSymbolContextModule();
+ if (!module_sp)
+return llvm::createStringError("compile unit has no module");
+ SymbolFile *sym_file = module_sp->GetSymbolFile();
+ if (!sym_file)
+return llvm::createStringError(
+llvm::formatv("No symbol file available for module '{0}'",
+ module_sp->GetFileSpec().GetFilename()));
+
+ return sym_file->ParseXcodeSDK(unit);
+}
+
+llvm::Expected
+PlatformDarwin::ResolveSDKPathFromDebugInfo(CompileUnit &unit) {
+ auto sdk_or_err = GetSDKPathFromDebugInfo(unit);
+ if (!sdk_or_err)
+return llvm::createStringError(
+llvm::inconvertibleErrorCode(),
+llvm::formatv("Failed to parse SDK path from debug-info: {0}",
+ llvm::toString(sdk_or_err.takeError(;
+
+ auto sdk = std::move(*sdk_or_err);
+
+ auto path_or_err = HostInfo::GetSDKRoot(HostInfo::SDKOptions{sdk});
+ if (!path_or_err)
+return llvm::createStringError(
+llvm::inconvertibleErrorCode(),
+llvm::formatv("Error while searching for SDK (XcodeSDK '{0}'): {1}",
+ sdk.GetString(),
+ llvm::toString(path_or_err.takeError(;
+
+ return path_or_err->str();
+}
diff --git a/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h
b/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h
index 66a26d2f496776..e2d4cb6726d585 100644
--- a/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h
+++ b/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h
@@ -130,6 +130,11 @@ class PlatformDarwin : public PlatformPOSIX {
llvm::Expected
ResolveSDKPathFromDebugInfo(Module &module) override;
+ llvm::Expected GetSDKPathFromDebugInfo(CompileUnit &unit) override;
+
+ llvm::Expected
+ ResolveSDKPathFromDebugInfo(CompileUnit &unit) override;
+
protected:
static const char *GetCompatibleArch(ArchSpec::Core core, size_t idx);
diff --git a/lldb/unittests/SymbolFile/DWARF/XcodeSDKModuleTests.cpp
b/lldb/unittests/SymbolFile/DWARF/Xcode
[Lldb-commits] [lldb] [lldb] Add a per-CU API to read the SDK (PR #119022)
https://github.com/adrian-prantl closed https://github.com/llvm/llvm-project/pull/119022 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add a compiler/interpreter of LLDB data formatter bytecode to lldb/examples (PR #113398)
https://github.com/adrian-prantl updated https://github.com/llvm/llvm-project/pull/113398 >From 7e3da87ca896484a11ac09df297183147154ac91 Mon Sep 17 00:00:00 2001 From: Adrian Prantl Date: Tue, 22 Oct 2024 16:29:50 -0700 Subject: [PATCH] [lldb] Add a compiler/interpreter of LLDB data formatter bytecode to examples This PR adds a proof-of-concept for a bytecode designed to ship and run LLDB data formatters. More motivation and context can be found in the formatter-bytecode.rst file and on discourse. https://discourse.llvm.org/t/a-bytecode-for-lldb-data-formatters/82696 --- lldb/docs/index.rst | 1 + lldb/docs/resources/formatterbytecode.rst | 238 lldb/examples/python/formatter_bytecode.py| 520 ++ .../Inputs/FormatterBytecode/MyOptional.cpp | 23 + .../Inputs/FormatterBytecode/formatter.py | 167 ++ .../ScriptInterpreter/Python/bytecode.test| 16 + 6 files changed, 965 insertions(+) create mode 100644 lldb/docs/resources/formatterbytecode.rst create mode 100644 lldb/examples/python/formatter_bytecode.py create mode 100644 lldb/test/Shell/ScriptInterpreter/Python/Inputs/FormatterBytecode/MyOptional.cpp create mode 100644 lldb/test/Shell/ScriptInterpreter/Python/Inputs/FormatterBytecode/formatter.py create mode 100644 lldb/test/Shell/ScriptInterpreter/Python/bytecode.test diff --git a/lldb/docs/index.rst b/lldb/docs/index.rst index fb22bdecad37e7..5686a33e94c938 100644 --- a/lldb/docs/index.rst +++ b/lldb/docs/index.rst @@ -164,6 +164,7 @@ interesting areas to contribute to lldb. resources/fuzzing resources/sbapi resources/dataformatters + resources/formatterbytecode resources/extensions resources/lldbgdbremote resources/lldbplatformpackets diff --git a/lldb/docs/resources/formatterbytecode.rst b/lldb/docs/resources/formatterbytecode.rst new file mode 100644 index 00..a4fd2bbe804b24 --- /dev/null +++ b/lldb/docs/resources/formatterbytecode.rst @@ -0,0 +1,238 @@ +Formatter Bytecode +== + +Background +-- + +LLDB provides rich customization options to display data types (see :doc:`/use/variable/`). To use custom data formatters, developers need to edit the global `~/.lldbinit` file to make sure they are found and loaded. In addition to this rather manual workflow, developers or library authors can ship ship data formatters with their code in a format that allows LLDB automatically find them and run them securely. + +An end-to-end example of such a workflow is the Swift `DebugDescription` macro (see https://www.swift.org/blog/announcing-swift-6/#debugging ) that translates Swift string interpolation into LLDB summary strings, and puts them into a `.lldbsummaries` section, where LLDB can find them. + +This document describes a minimal bytecode tailored to running LLDB formatters. It defines a human-readable assembler representation for the language, an efficient binary encoding, a virtual machine for evaluating it, and format for embedding formatters into binary containers. + +Goals +~ + +Provide an efficient and secure encoding for data formatters that can be used as a compilation target from user-friendly representations (such as DIL, Swift DebugDescription, or NatVis). + +Non-goals +~ + +While humans could write the assembler syntax, making it user-friendly is not a goal. It is meant to be used as a compilation target for higher-level, language-specific affordances. + +Design of the virtual machine +- + +The LLDB formatter virtual machine uses a stack-based bytecode, comparable with DWARF expressions, but with higher-level data types and functions. + +The virtual machine has two stacks, a data and a control stack. The control stack is kept separate to make it easier to reason about the security aspects of the virtual machine. + +Data types +~~ + +All objects on the data stack must have one of the following data types. These data types are "host" data types, in LLDB parlance. + +* *String* (UTF-8) +* *Int* (64 bit) +* *UInt* (64 bit) +* *Object* (Basically an `SBValue`) +* *Type* (Basically an `SBType`) +* *Selector* (One of the predefine functions) + +*Object* and *Type* are opaque, they can only be used as a parameters of `call`. + +Instruction set +--- + +Stack operations + + +These instructions manipulate the data stack directly. + + == === + OpcodeMnemonicStack effect + -- --- + 0x00 `dup` `(x -> x x)` + 0x01 `drop` `(x y -> x)` + 0x02 `pick` `(x ... UInt -> x ... x)` + 0x03 `over` `(x y -> x y x)` + 0x04 `swap` `(x y -> y x)` + 0x05 `rot` `(x y z -> z x y)` +=== == === + +Control flow + + +These manipulate the control stack and program counter. Both `if` and
[Lldb-commits] [lldb] [lldb] Add lookup by name to SBValue.child (PR #118814)
https://github.com/kastiglione updated
https://github.com/llvm/llvm-project/pull/118814
>From 639fc6d87345c8d68a822032917102a4225df355 Mon Sep 17 00:00:00 2001
From: Dave Lee
Date: Wed, 4 Dec 2024 14:37:24 -0800
Subject: [PATCH 1/4] [lldb] Add lookup by name to SBValue.child
---
lldb/bindings/interface/SBValueExtensions.i| 6 --
lldb/test/API/python_api/value/TestValueAPI.py | 8 +++-
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/lldb/bindings/interface/SBValueExtensions.i
b/lldb/bindings/interface/SBValueExtensions.i
index bee9c27775d453..f743b8b9bc786f 100644
--- a/lldb/bindings/interface/SBValueExtensions.i
+++ b/lldb/bindings/interface/SBValueExtensions.i
@@ -7,7 +7,7 @@ STRING_EXTENSION_OUTSIDE(SBValue)
return self.GetDynamicValue (eDynamicCanRunTarget)
class children_access(object):
-'''A helper object that will lazily hand out thread for a process
when supplied an index.'''
+'''A helper object that will lazily hand out child values when
supplied an index or name.'''
def __init__(self, sbvalue):
self.sbvalue = sbvalue
@@ -23,6 +23,8 @@ STRING_EXTENSION_OUTSIDE(SBValue)
if -count <= key < count:
key %= count
return self.sbvalue.GetChildAtIndex(key)
+elif isinstance(key, str):
+return self.sbvalue.GetChildMemberWithName(key)
return None
def get_child_access_object(self):
@@ -49,7 +51,7 @@ STRING_EXTENSION_OUTSIDE(SBValue)
return self.GetNumChildren()
children = property(get_value_child_list, None, doc='''A read only
property that returns a list() of lldb.SBValue objects for the children of the
value.''')
-child = property(get_child_access_object, None, doc='''A read only
property that returns an object that can access children of a variable by index
(child_value = value.children[12]).''')
+child = property(get_child_access_object, None, doc='''A read only
property that returns an object that can access children of a variable by index
or by name.''')
name = property(GetName, None, doc='''A read only property that
returns the name of this value as a string.''')
type = property(GetType, None, doc='''A read only property that
returns a lldb.SBType object that represents the type for this value.''')
size = property(GetByteSize, None, doc='''A read only property that
returns the size in bytes of this value.''')
diff --git a/lldb/test/API/python_api/value/TestValueAPI.py
b/lldb/test/API/python_api/value/TestValueAPI.py
index 512100912d6fe7..eb6dbfe6362a43 100644
--- a/lldb/test/API/python_api/value/TestValueAPI.py
+++ b/lldb/test/API/python_api/value/TestValueAPI.py
@@ -140,10 +140,8 @@ def test(self):
val_i = target.EvaluateExpression("i")
val_s = target.EvaluateExpression("s")
val_a = target.EvaluateExpression("a")
-self.assertTrue(
-val_s.GetChildMemberWithName("a").GetAddress().IsValid(),
VALID_VARIABLE
-)
-self.assertTrue(val_s.GetChildMemberWithName("a").AddressOf(),
VALID_VARIABLE)
+self.assertTrue(val_s.child["a"].GetAddress().IsValid(),
VALID_VARIABLE)
+self.assertTrue(val_s.child["a"].AddressOf(), VALID_VARIABLE)
self.assertTrue(val_a.Cast(val_i.GetType()).AddressOf(),
VALID_VARIABLE)
# Test some other cases of the Cast API. We allow casts from one
struct type
@@ -210,7 +208,7 @@ def test(self):
weird_cast = f_var.Cast(val_s.GetType())
self.assertSuccess(weird_cast.GetError(), "Can cast from a larger to a
smaller")
self.assertEqual(
-weird_cast.GetChildMemberWithName("a").GetValueAsSigned(0),
+weird_cast.child["a"].GetValueAsSigned(0),
33,
"Got the right value",
)
>From c6f926b0e451f87af8c14baed3de55f4cb4240d5 Mon Sep 17 00:00:00 2001
From: Dave Lee
Date: Thu, 5 Dec 2024 13:04:20 -0800
Subject: [PATCH 2/4] Support base class children
---
lldb/bindings/interface/SBValueExtensions.i | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/lldb/bindings/interface/SBValueExtensions.i
b/lldb/bindings/interface/SBValueExtensions.i
index f743b8b9bc786f..c813de6c65c5c6 100644
--- a/lldb/bindings/interface/SBValueExtensions.i
+++ b/lldb/bindings/interface/SBValueExtensions.i
@@ -24,7 +24,12 @@ STRING_EXTENSION_OUTSIDE(SBValue)
key %= count
return self.sbvalue.GetChildAtIndex(key)
elif isinstance(key, str):
-return self.sbvalue.GetChildMemberWithName(key)
+if child := self.sbvalue.GetChildMemberWithName(key)
+return child
+# Support base classes, which are children but not members.
+for child in self.sbvalue
[Lldb-commits] [lldb] 0ee364d - [lldb] Add a compiler/interpreter of LLDB data formatter bytecode to lldb/examples (#113398)
Author: Adrian Prantl Date: 2024-12-06T15:11:21-08:00 New Revision: 0ee364d2a28104aaa36e246fc8a316f86de32aae URL: https://github.com/llvm/llvm-project/commit/0ee364d2a28104aaa36e246fc8a316f86de32aae DIFF: https://github.com/llvm/llvm-project/commit/0ee364d2a28104aaa36e246fc8a316f86de32aae.diff LOG: [lldb] Add a compiler/interpreter of LLDB data formatter bytecode to lldb/examples (#113398) This PR adds a proof-of-concept for a bytecode designed to ship and run LLDB data formatters. More motivation and context can be found in the `formatter-bytecode.md` file and on discourse. https://discourse.llvm.org/t/a-bytecode-for-lldb-data-formatters/82696 Added: lldb/docs/resources/formatterbytecode.rst lldb/examples/python/formatter_bytecode.py lldb/test/Shell/ScriptInterpreter/Python/Inputs/FormatterBytecode/MyOptional.cpp lldb/test/Shell/ScriptInterpreter/Python/Inputs/FormatterBytecode/formatter.py lldb/test/Shell/ScriptInterpreter/Python/bytecode.test Modified: lldb/docs/index.rst Removed: diff --git a/lldb/docs/index.rst b/lldb/docs/index.rst index fb22bdecad37e7..5686a33e94c938 100644 --- a/lldb/docs/index.rst +++ b/lldb/docs/index.rst @@ -164,6 +164,7 @@ interesting areas to contribute to lldb. resources/fuzzing resources/sbapi resources/dataformatters + resources/formatterbytecode resources/extensions resources/lldbgdbremote resources/lldbplatformpackets diff --git a/lldb/docs/resources/formatterbytecode.rst b/lldb/docs/resources/formatterbytecode.rst new file mode 100644 index 00..a4fd2bbe804b24 --- /dev/null +++ b/lldb/docs/resources/formatterbytecode.rst @@ -0,0 +1,238 @@ +Formatter Bytecode +== + +Background +-- + +LLDB provides rich customization options to display data types (see :doc:`/use/variable/`). To use custom data formatters, developers need to edit the global `~/.lldbinit` file to make sure they are found and loaded. In addition to this rather manual workflow, developers or library authors can ship ship data formatters with their code in a format that allows LLDB automatically find them and run them securely. + +An end-to-end example of such a workflow is the Swift `DebugDescription` macro (see https://www.swift.org/blog/announcing-swift-6/#debugging ) that translates Swift string interpolation into LLDB summary strings, and puts them into a `.lldbsummaries` section, where LLDB can find them. + +This document describes a minimal bytecode tailored to running LLDB formatters. It defines a human-readable assembler representation for the language, an efficient binary encoding, a virtual machine for evaluating it, and format for embedding formatters into binary containers. + +Goals +~ + +Provide an efficient and secure encoding for data formatters that can be used as a compilation target from user-friendly representations (such as DIL, Swift DebugDescription, or NatVis). + +Non-goals +~ + +While humans could write the assembler syntax, making it user-friendly is not a goal. It is meant to be used as a compilation target for higher-level, language-specific affordances. + +Design of the virtual machine +- + +The LLDB formatter virtual machine uses a stack-based bytecode, comparable with DWARF expressions, but with higher-level data types and functions. + +The virtual machine has two stacks, a data and a control stack. The control stack is kept separate to make it easier to reason about the security aspects of the virtual machine. + +Data types +~~ + +All objects on the data stack must have one of the following data types. These data types are "host" data types, in LLDB parlance. + +* *String* (UTF-8) +* *Int* (64 bit) +* *UInt* (64 bit) +* *Object* (Basically an `SBValue`) +* *Type* (Basically an `SBType`) +* *Selector* (One of the predefine functions) + +*Object* and *Type* are opaque, they can only be used as a parameters of `call`. + +Instruction set +--- + +Stack operations + + +These instructions manipulate the data stack directly. + + == === + OpcodeMnemonicStack effect + -- --- + 0x00 `dup` `(x -> x x)` + 0x01 `drop` `(x y -> x)` + 0x02 `pick` `(x ... UInt -> x ... x)` + 0x03 `over` `(x y -> x y x)` + 0x04 `swap` `(x y -> y x)` + 0x05 `rot` `(x y z -> z x y)` +=== == === + +Control flow + + +These manipulate the control stack and program counter. Both `if` and `ifelse` expect a `UInt` at the top of the data stack to represent the condition. + + == + OpcodeMnemonicDescription + -- ---
[Lldb-commits] [lldb] [lldb] Add lookup by name to SBValue through new member property (PR #118814)
https://github.com/kastiglione edited https://github.com/llvm/llvm-project/pull/118814 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add a per-CU API to read the SDK (PR #119022)
@@ -473,6 +473,32 @@ class Platform : public PluginInterface {
LLVM_PRETTY_FUNCTION, GetName()));
}
+ /// Search CU for the SDK path the CUs was compiled against.
+ ///
+ /// \param[in] unit The CU
+ ///
+ /// \returns A parsed XcodeSDK object if successful, an Error otherwise.
+ virtual llvm::Expected GetSDKPathFromDebugInfo(CompileUnit &unit) {
clayborg wrote:
Can we abstract a base class for SDK and have XcodeSDK become a plug-in?
https://github.com/llvm/llvm-project/pull/119022
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add lookup by name to SBValue through new member property (PR #118814)
https://github.com/kastiglione edited https://github.com/llvm/llvm-project/pull/118814 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add lookup by name to SBValue through new member property (PR #118814)
@@ -23,6 +23,13 @@ STRING_EXTENSION_OUTSIDE(SBValue) if -count <= key < count: key %= count return self.sbvalue.GetChildAtIndex(key) +elif isinstance(key, str): +if child := self.sbvalue.GetChildMemberWithName(key): +return child +# Support base classes, which are children but not members. +for child in self.sbvalue: +if child.name == key: +return child kastiglione wrote: I've updated the PR to leave `child` alone, and introduced `member`. Does this work for everyone? It doesn't provide any means for accessing base classes by name, but that was not my primary intention. https://github.com/llvm/llvm-project/pull/118814 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add a compiler/interpreter of LLDB data formatter bytecode to lldb/examples (PR #113398)
https://github.com/adrian-prantl closed https://github.com/llvm/llvm-project/pull/113398 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add a per-CU API to read the SDK (PR #119022)
@@ -473,6 +473,32 @@ class Platform : public PluginInterface {
LLVM_PRETTY_FUNCTION, GetName()));
}
+ /// Search CU for the SDK path the CUs was compiled against.
+ ///
+ /// \param[in] unit The CU
+ ///
+ /// \returns A parsed XcodeSDK object if successful, an Error otherwise.
+ virtual llvm::Expected GetSDKPathFromDebugInfo(CompileUnit &unit) {
adrian-prantl wrote:
I'd volunteer to do that work if we had another platform that also has a
concept of an SDK. Otherwise it'd be dangerous that I design the base class to
be way too close to Xcode's SDK properties.
https://github.com/llvm/llvm-project/pull/119022
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 8ab76a4 - Revert "[lldb] Add a compiler/interpreter of LLDB data formatter bytecode to examples"
Author: Adrian Prantl
Date: 2024-12-06T15:34:12-08:00
New Revision: 8ab76a47b242addc82109a3b3b6de9c3d6426eca
URL:
https://github.com/llvm/llvm-project/commit/8ab76a47b242addc82109a3b3b6de9c3d6426eca
DIFF:
https://github.com/llvm/llvm-project/commit/8ab76a47b242addc82109a3b3b6de9c3d6426eca.diff
LOG: Revert "[lldb] Add a compiler/interpreter of LLDB data formatter bytecode
to examples"
This reverts commit 7e3da87ca896484a11ac09df297183147154ac91.
I managed to break the bots.
Added:
Modified:
lldb/docs/index.rst
Removed:
lldb/docs/resources/formatterbytecode.rst
lldb/examples/python/formatter_bytecode.py
lldb/test/Shell/ScriptInterpreter/Python/Inputs/FormatterBytecode/MyOptional.cpp
lldb/test/Shell/ScriptInterpreter/Python/Inputs/FormatterBytecode/formatter.py
lldb/test/Shell/ScriptInterpreter/Python/bytecode.test
diff --git a/lldb/docs/index.rst b/lldb/docs/index.rst
index 5686a33e94c938..fb22bdecad37e7 100644
--- a/lldb/docs/index.rst
+++ b/lldb/docs/index.rst
@@ -164,7 +164,6 @@ interesting areas to contribute to lldb.
resources/fuzzing
resources/sbapi
resources/dataformatters
- resources/formatterbytecode
resources/extensions
resources/lldbgdbremote
resources/lldbplatformpackets
diff --git a/lldb/docs/resources/formatterbytecode.rst
b/lldb/docs/resources/formatterbytecode.rst
deleted file mode 100644
index a4fd2bbe804b24..00
--- a/lldb/docs/resources/formatterbytecode.rst
+++ /dev/null
@@ -1,238 +0,0 @@
-Formatter Bytecode
-==
-
-Background
---
-
-LLDB provides rich customization options to display data types (see
:doc:`/use/variable/`). To use custom data formatters, developers need to edit
the global `~/.lldbinit` file to make sure they are found and loaded. In
addition to this rather manual workflow, developers or library authors can ship
ship data formatters with their code in a format that allows LLDB automatically
find them and run them securely.
-
-An end-to-end example of such a workflow is the Swift `DebugDescription` macro
(see https://www.swift.org/blog/announcing-swift-6/#debugging ) that translates
Swift string interpolation into LLDB summary strings, and puts them into a
`.lldbsummaries` section, where LLDB can find them.
-
-This document describes a minimal bytecode tailored to running LLDB
formatters. It defines a human-readable assembler representation for the
language, an efficient binary encoding, a virtual machine for evaluating it,
and format for embedding formatters into binary containers.
-
-Goals
-~
-
-Provide an efficient and secure encoding for data formatters that can be used
as a compilation target from user-friendly representations (such as DIL, Swift
DebugDescription, or NatVis).
-
-Non-goals
-~
-
-While humans could write the assembler syntax, making it user-friendly is not
a goal. It is meant to be used as a compilation target for higher-level,
language-specific affordances.
-
-Design of the virtual machine
--
-
-The LLDB formatter virtual machine uses a stack-based bytecode, comparable
with DWARF expressions, but with higher-level data types and functions.
-
-The virtual machine has two stacks, a data and a control stack. The control
stack is kept separate to make it easier to reason about the security aspects
of the virtual machine.
-
-Data types
-~~
-
-All objects on the data stack must have one of the following data types. These
data types are "host" data types, in LLDB parlance.
-
-* *String* (UTF-8)
-* *Int* (64 bit)
-* *UInt* (64 bit)
-* *Object* (Basically an `SBValue`)
-* *Type* (Basically an `SBType`)
-* *Selector* (One of the predefine functions)
-
-*Object* and *Type* are opaque, they can only be used as a parameters of
`call`.
-
-Instruction set
-
-Stack operations
-
-
-These instructions manipulate the data stack directly.
-
- == ===
- OpcodeMnemonicStack effect
- -- ---
- 0x00 `dup` `(x -> x x)`
- 0x01 `drop` `(x y -> x)`
- 0x02 `pick` `(x ... UInt -> x ... x)`
- 0x03 `over` `(x y -> x y x)`
- 0x04 `swap` `(x y -> y x)`
- 0x05 `rot` `(x y z -> z x y)`
-=== == ===
-
-Control flow
-
-
-These manipulate the control stack and program counter. Both `if` and `ifelse`
expect a `UInt` at the top of the data stack to represent the condition.
-
- ==
- OpcodeMnemonicDescription
- --
- 0x10 `{`push a code block address onto the control stack
- --`}`(technically not an opcode) syntax f
[Lldb-commits] [lldb] [lldb] Add lookup by name to SBValue through new member property (PR #118814)
@@ -23,6 +23,13 @@ STRING_EXTENSION_OUTSIDE(SBValue) if -count <= key < count: key %= count return self.sbvalue.GetChildAtIndex(key) +elif isinstance(key, str): +if child := self.sbvalue.GetChildMemberWithName(key): +return child +# Support base classes, which are children but not members. +for child in self.sbvalue: +if child.name == key: +return child jimingham wrote: This is fine by me, though at some point it would be convenient (and symmetric) to come back and add base class accessors. My only objection to the original patch was that using the `child` property for member access was confusing. `member` is clear. https://github.com/llvm/llvm-project/pull/118814 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add lookup by name to SBValue through new member property (PR #118814)
https://github.com/jimingham approved this pull request. LGTM https://github.com/llvm/llvm-project/pull/118814 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 9f98949 - [lldb] Move the python module import workaround further up
Author: Adrian Prantl Date: 2024-12-06T17:01:58-08:00 New Revision: 9f98949c9424addbc573fac7912cc164965b8994 URL: https://github.com/llvm/llvm-project/commit/9f98949c9424addbc573fac7912cc164965b8994 DIFF: https://github.com/llvm/llvm-project/commit/9f98949c9424addbc573fac7912cc164965b8994.diff LOG: [lldb] Move the python module import workaround further up Added: Modified: lldb/examples/python/formatter_bytecode.py Removed: diff --git a/lldb/examples/python/formatter_bytecode.py b/lldb/examples/python/formatter_bytecode.py index 0930d50013571e..ccd0c68a75483c 100644 --- a/lldb/examples/python/formatter_bytecode.py +++ b/lldb/examples/python/formatter_bytecode.py @@ -463,6 +463,12 @@ def next_byte(): if __name__ == "__main__": +# Work around the fact that one of the local files is called +# types.py, which breaks some versions of python. +import os, sys + +path = os.path.abspath(os.path.dirname(__file__)) +sys.path.remove(path) import argparse parser = argparse.ArgumentParser( @@ -487,12 +493,6 @@ def next_byte(): # Tests. if args.test: -# Work around the fact that one of the local files is calles -# types.py, which breaks some versions of python. -import os, sys - -path = os.path.abspath(os.path.dirname(__file__)) -sys.path.remove(path) import unittest class TestCompiler(unittest.TestCase): ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Bugfix: Not showing the synthetic children of values behind pointers (PR #117755)
clayborg wrote: Another thing that might not be abvious is that an instance of this class lives as long as the variable lives so as you are stepping in the same function, we will create one synthetic python instance per raw `lldb.SBValue`. This is why the `def update(self):` function is so important. https://github.com/llvm/llvm-project/pull/117755 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 60380cd - [lldb] Add a compiler/interpreter of LLDB data formatter bytecode to examples
Author: Adrian Prantl Date: 2024-12-06T16:10:09-08:00 New Revision: 60380cd27c6fa5ed6e39866c51b18a64bc4d566a URL: https://github.com/llvm/llvm-project/commit/60380cd27c6fa5ed6e39866c51b18a64bc4d566a DIFF: https://github.com/llvm/llvm-project/commit/60380cd27c6fa5ed6e39866c51b18a64bc4d566a.diff LOG: [lldb] Add a compiler/interpreter of LLDB data formatter bytecode to examples This PR adds a proof-of-concept for a bytecode designed to ship and run LLDB data formatters. More motivation and context can be found in the formatter-bytecode.rst file and on discourse. https://discourse.llvm.org/t/a-bytecode-for-lldb-data-formatters/82696 Relanding with a fix for a case-sensitive path. Added: lldb/docs/resources/formatterbytecode.rst lldb/examples/python/formatter_bytecode.py lldb/test/Shell/ScriptInterpreter/Python/Inputs/FormatterBytecode/MyOptional.cpp lldb/test/Shell/ScriptInterpreter/Python/Inputs/FormatterBytecode/formatter.py lldb/test/Shell/ScriptInterpreter/Python/bytecode.test Modified: lldb/docs/index.rst Removed: diff --git a/lldb/docs/index.rst b/lldb/docs/index.rst index fb22bdecad37e7..5686a33e94c938 100644 --- a/lldb/docs/index.rst +++ b/lldb/docs/index.rst @@ -164,6 +164,7 @@ interesting areas to contribute to lldb. resources/fuzzing resources/sbapi resources/dataformatters + resources/formatterbytecode resources/extensions resources/lldbgdbremote resources/lldbplatformpackets diff --git a/lldb/docs/resources/formatterbytecode.rst b/lldb/docs/resources/formatterbytecode.rst new file mode 100644 index 00..a4fd2bbe804b24 --- /dev/null +++ b/lldb/docs/resources/formatterbytecode.rst @@ -0,0 +1,238 @@ +Formatter Bytecode +== + +Background +-- + +LLDB provides rich customization options to display data types (see :doc:`/use/variable/`). To use custom data formatters, developers need to edit the global `~/.lldbinit` file to make sure they are found and loaded. In addition to this rather manual workflow, developers or library authors can ship ship data formatters with their code in a format that allows LLDB automatically find them and run them securely. + +An end-to-end example of such a workflow is the Swift `DebugDescription` macro (see https://www.swift.org/blog/announcing-swift-6/#debugging ) that translates Swift string interpolation into LLDB summary strings, and puts them into a `.lldbsummaries` section, where LLDB can find them. + +This document describes a minimal bytecode tailored to running LLDB formatters. It defines a human-readable assembler representation for the language, an efficient binary encoding, a virtual machine for evaluating it, and format for embedding formatters into binary containers. + +Goals +~ + +Provide an efficient and secure encoding for data formatters that can be used as a compilation target from user-friendly representations (such as DIL, Swift DebugDescription, or NatVis). + +Non-goals +~ + +While humans could write the assembler syntax, making it user-friendly is not a goal. It is meant to be used as a compilation target for higher-level, language-specific affordances. + +Design of the virtual machine +- + +The LLDB formatter virtual machine uses a stack-based bytecode, comparable with DWARF expressions, but with higher-level data types and functions. + +The virtual machine has two stacks, a data and a control stack. The control stack is kept separate to make it easier to reason about the security aspects of the virtual machine. + +Data types +~~ + +All objects on the data stack must have one of the following data types. These data types are "host" data types, in LLDB parlance. + +* *String* (UTF-8) +* *Int* (64 bit) +* *UInt* (64 bit) +* *Object* (Basically an `SBValue`) +* *Type* (Basically an `SBType`) +* *Selector* (One of the predefine functions) + +*Object* and *Type* are opaque, they can only be used as a parameters of `call`. + +Instruction set +--- + +Stack operations + + +These instructions manipulate the data stack directly. + + == === + OpcodeMnemonicStack effect + -- --- + 0x00 `dup` `(x -> x x)` + 0x01 `drop` `(x y -> x)` + 0x02 `pick` `(x ... UInt -> x ... x)` + 0x03 `over` `(x y -> x y x)` + 0x04 `swap` `(x y -> y x)` + 0x05 `rot` `(x y z -> z x y)` +=== == === + +Control flow + + +These manipulate the control stack and program counter. Both `if` and `ifelse` expect a `UInt` at the top of the data stack to represent the condition. + + == + OpcodeMnemonicDescription + ---
[Lldb-commits] [lldb] [lldb] Add lookup by name to SBValue through new member property (PR #118814)
@@ -29,6 +29,19 @@ STRING_EXTENSION_OUTSIDE(SBValue)
'''An accessor function that returns a children_access() object
which allows lazy member variable access from a lldb.SBValue object.'''
return self.children_access (self)
+def get_member_access_object(self):
+'''An accessor function that returns an interface which provides
subscript based lookup of child members.'''
+class member_access:
+def __init__(self, valobj):
+self.valobj = valobj
+
+def __getitem__(self, key):
+if isinstance(key, str):
+return self.valobj.GetChildMemberWithName(key)
+raise TypeError("invalid subscript key")
clayborg wrote:
Do we want to be more clear here and say something other than `"invalid
subscript key"`? Do we want to say `"member key values must be string values
that specify the name of a member variable to access"`?
https://github.com/llvm/llvm-project/pull/118814
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Bugfix: Not showing the synthetic children of values behind pointers (PR #117755)
clayborg wrote:
You also are overwriting the original `lldb.SBValue` with the statement
`self.valobj = self.valobj.Dereference()` here:
```
def extract_entries(self):
if self.valobj.type.is_pointer:
self.valobj = self.valobj.Dereference()
```
You never want to do this because if your value is a pointer, that pointer can
change, and now you have replaced the value that is the pointer value with the
first dereference value and that value will never change. Now when you run this
function again, you won't get the right value because you will have locked onto
the first dereferenced pointer. So if you have code like:
```
auto *int_ptr = &myHash1;
int_ptr = &myHash2;
```
You will always be showing `myHash1` as the value and it will never update. So
you never touch the original `self. valobj` value as that is always your
starting point. So lets say `&myHash1` is 0x1000 and `&myHash2` is 0x2000, with
your code you will always dereference the pointer from 0x1000 and then you
re-write your `self.valobj` to now always be that reference.
You also don't need to dereference the type. So your `extract_entries` function
that currently looks like:
```
def extract_entries(self):
if self.valobj.type.is_pointer:
self.valobj = self.valobj.Dereference()
self.size = 0 if self.valobj.GetChildMemberWithName("size").value is
None else self.valobj.GetChildMemberWithName("size").unsigned
self.entries = []
```
Should be:
```
def update(self):
self.size =
self.valobj.GetChildMemberWithName("size").GetValueAsUnsigned(0)
self.entries = []
```
https://github.com/llvm/llvm-project/pull/117755
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add lookup by name to SBValue through new member property (PR #118814)
https://github.com/clayborg edited https://github.com/llvm/llvm-project/pull/118814 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Bugfix: Not showing the synthetic children of values behind pointers (PR #117755)
clayborg wrote: You don't have a "def update(self):" method in your data formatter. This is what causes the values to be refetched. I think if you rename "extract_entries" to be named "update" it will fix your synthetic child provider. https://github.com/llvm/llvm-project/pull/117755 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Bugfix: Not showing the synthetic children of values behind pointers (PR #117755)
clayborg wrote: the `def update(self):` is a mandatory function that is automatically called for you by the LLDB python synthetic child provider when a variable needs to be updated, so you can't rename it. Since you renamed that to be `extract_entries`, your synthetic child provider will never update itself. So rename this to `update` and call `self.update()` in the `__init__` function, and change your function as outlined above and everything should work. https://github.com/llvm/llvm-project/pull/117755 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] b504c87 - Revert "[lldb] Add a compiler/interpreter of LLDB data formatter bytecode to examples"
Author: Adrian Prantl
Date: 2024-12-06T16:26:55-08:00
New Revision: b504c8771f238883ef6c7234d741c2dc1d885ae3
URL:
https://github.com/llvm/llvm-project/commit/b504c8771f238883ef6c7234d741c2dc1d885ae3
DIFF:
https://github.com/llvm/llvm-project/commit/b504c8771f238883ef6c7234d741c2dc1d885ae3.diff
LOG: Revert "[lldb] Add a compiler/interpreter of LLDB data formatter bytecode
to examples"
This reverts commit 60380cd27c6fa5ed6e39866c51b18a64bc4d566a.
Added:
Modified:
lldb/docs/index.rst
Removed:
lldb/docs/resources/formatterbytecode.rst
lldb/examples/python/formatter_bytecode.py
lldb/test/Shell/ScriptInterpreter/Python/Inputs/FormatterBytecode/MyOptional.cpp
lldb/test/Shell/ScriptInterpreter/Python/Inputs/FormatterBytecode/formatter.py
lldb/test/Shell/ScriptInterpreter/Python/bytecode.test
diff --git a/lldb/docs/index.rst b/lldb/docs/index.rst
index 5686a33e94c938..fb22bdecad37e7 100644
--- a/lldb/docs/index.rst
+++ b/lldb/docs/index.rst
@@ -164,7 +164,6 @@ interesting areas to contribute to lldb.
resources/fuzzing
resources/sbapi
resources/dataformatters
- resources/formatterbytecode
resources/extensions
resources/lldbgdbremote
resources/lldbplatformpackets
diff --git a/lldb/docs/resources/formatterbytecode.rst
b/lldb/docs/resources/formatterbytecode.rst
deleted file mode 100644
index a4fd2bbe804b24..00
--- a/lldb/docs/resources/formatterbytecode.rst
+++ /dev/null
@@ -1,238 +0,0 @@
-Formatter Bytecode
-==
-
-Background
---
-
-LLDB provides rich customization options to display data types (see
:doc:`/use/variable/`). To use custom data formatters, developers need to edit
the global `~/.lldbinit` file to make sure they are found and loaded. In
addition to this rather manual workflow, developers or library authors can ship
ship data formatters with their code in a format that allows LLDB automatically
find them and run them securely.
-
-An end-to-end example of such a workflow is the Swift `DebugDescription` macro
(see https://www.swift.org/blog/announcing-swift-6/#debugging ) that translates
Swift string interpolation into LLDB summary strings, and puts them into a
`.lldbsummaries` section, where LLDB can find them.
-
-This document describes a minimal bytecode tailored to running LLDB
formatters. It defines a human-readable assembler representation for the
language, an efficient binary encoding, a virtual machine for evaluating it,
and format for embedding formatters into binary containers.
-
-Goals
-~
-
-Provide an efficient and secure encoding for data formatters that can be used
as a compilation target from user-friendly representations (such as DIL, Swift
DebugDescription, or NatVis).
-
-Non-goals
-~
-
-While humans could write the assembler syntax, making it user-friendly is not
a goal. It is meant to be used as a compilation target for higher-level,
language-specific affordances.
-
-Design of the virtual machine
--
-
-The LLDB formatter virtual machine uses a stack-based bytecode, comparable
with DWARF expressions, but with higher-level data types and functions.
-
-The virtual machine has two stacks, a data and a control stack. The control
stack is kept separate to make it easier to reason about the security aspects
of the virtual machine.
-
-Data types
-~~
-
-All objects on the data stack must have one of the following data types. These
data types are "host" data types, in LLDB parlance.
-
-* *String* (UTF-8)
-* *Int* (64 bit)
-* *UInt* (64 bit)
-* *Object* (Basically an `SBValue`)
-* *Type* (Basically an `SBType`)
-* *Selector* (One of the predefine functions)
-
-*Object* and *Type* are opaque, they can only be used as a parameters of
`call`.
-
-Instruction set
-
-Stack operations
-
-
-These instructions manipulate the data stack directly.
-
- == ===
- OpcodeMnemonicStack effect
- -- ---
- 0x00 `dup` `(x -> x x)`
- 0x01 `drop` `(x y -> x)`
- 0x02 `pick` `(x ... UInt -> x ... x)`
- 0x03 `over` `(x y -> x y x)`
- 0x04 `swap` `(x y -> y x)`
- 0x05 `rot` `(x y z -> z x y)`
-=== == ===
-
-Control flow
-
-
-These manipulate the control stack and program counter. Both `if` and `ifelse`
expect a `UInt` at the top of the data stack to represent the condition.
-
- ==
- OpcodeMnemonicDescription
- --
- 0x10 `{`push a code block address onto the control stack
- --`}`(technically not an opcode) syntax for end of code block
- 0x11
[Lldb-commits] [lldb] fffe8c6 - [lldb] Add a compiler/interpreter of LLDB data formatter bytecode to examples
Author: Adrian Prantl Date: 2024-12-06T16:27:16-08:00 New Revision: fffe8c668461e73055182f229765cb7de908e295 URL: https://github.com/llvm/llvm-project/commit/fffe8c668461e73055182f229765cb7de908e295 DIFF: https://github.com/llvm/llvm-project/commit/fffe8c668461e73055182f229765cb7de908e295.diff LOG: [lldb] Add a compiler/interpreter of LLDB data formatter bytecode to examples This PR adds a proof-of-concept for a bytecode designed to ship and run LLDB data formatters. More motivation and context can be found in the formatter-bytecode.rst file and on discourse. https://discourse.llvm.org/t/a-bytecode-for-lldb-data-formatters/82696 Relanding with a fix for a case-sensitive path. Added: lldb/docs/resources/formatterbytecode.rst lldb/examples/python/formatter_bytecode.py lldb/test/Shell/ScriptInterpreter/Python/Inputs/FormatterBytecode/MyOptional.cpp lldb/test/Shell/ScriptInterpreter/Python/Inputs/FormatterBytecode/formatter.py lldb/test/Shell/ScriptInterpreter/Python/bytecode.test Modified: lldb/docs/index.rst Removed: diff --git a/lldb/docs/index.rst b/lldb/docs/index.rst index fb22bdecad37e7..5686a33e94c938 100644 --- a/lldb/docs/index.rst +++ b/lldb/docs/index.rst @@ -164,6 +164,7 @@ interesting areas to contribute to lldb. resources/fuzzing resources/sbapi resources/dataformatters + resources/formatterbytecode resources/extensions resources/lldbgdbremote resources/lldbplatformpackets diff --git a/lldb/docs/resources/formatterbytecode.rst b/lldb/docs/resources/formatterbytecode.rst new file mode 100644 index 00..a4fd2bbe804b24 --- /dev/null +++ b/lldb/docs/resources/formatterbytecode.rst @@ -0,0 +1,238 @@ +Formatter Bytecode +== + +Background +-- + +LLDB provides rich customization options to display data types (see :doc:`/use/variable/`). To use custom data formatters, developers need to edit the global `~/.lldbinit` file to make sure they are found and loaded. In addition to this rather manual workflow, developers or library authors can ship ship data formatters with their code in a format that allows LLDB automatically find them and run them securely. + +An end-to-end example of such a workflow is the Swift `DebugDescription` macro (see https://www.swift.org/blog/announcing-swift-6/#debugging ) that translates Swift string interpolation into LLDB summary strings, and puts them into a `.lldbsummaries` section, where LLDB can find them. + +This document describes a minimal bytecode tailored to running LLDB formatters. It defines a human-readable assembler representation for the language, an efficient binary encoding, a virtual machine for evaluating it, and format for embedding formatters into binary containers. + +Goals +~ + +Provide an efficient and secure encoding for data formatters that can be used as a compilation target from user-friendly representations (such as DIL, Swift DebugDescription, or NatVis). + +Non-goals +~ + +While humans could write the assembler syntax, making it user-friendly is not a goal. It is meant to be used as a compilation target for higher-level, language-specific affordances. + +Design of the virtual machine +- + +The LLDB formatter virtual machine uses a stack-based bytecode, comparable with DWARF expressions, but with higher-level data types and functions. + +The virtual machine has two stacks, a data and a control stack. The control stack is kept separate to make it easier to reason about the security aspects of the virtual machine. + +Data types +~~ + +All objects on the data stack must have one of the following data types. These data types are "host" data types, in LLDB parlance. + +* *String* (UTF-8) +* *Int* (64 bit) +* *UInt* (64 bit) +* *Object* (Basically an `SBValue`) +* *Type* (Basically an `SBType`) +* *Selector* (One of the predefine functions) + +*Object* and *Type* are opaque, they can only be used as a parameters of `call`. + +Instruction set +--- + +Stack operations + + +These instructions manipulate the data stack directly. + + == === + OpcodeMnemonicStack effect + -- --- + 0x00 `dup` `(x -> x x)` + 0x01 `drop` `(x y -> x)` + 0x02 `pick` `(x ... UInt -> x ... x)` + 0x03 `over` `(x y -> x y x)` + 0x04 `swap` `(x y -> y x)` + 0x05 `rot` `(x y z -> z x y)` +=== == === + +Control flow + + +These manipulate the control stack and program counter. Both `if` and `ifelse` expect a `UInt` at the top of the data stack to represent the condition. + + == + OpcodeMnemonicDescription + ---
[Lldb-commits] [lldb] [lldb][test] Skip libc++ tests if it is linked statically (PR #113935)
dzhidzhoev wrote: Thank you for the feedback! I was sorting out the ways to fix that. IMO explicitly referencing symbols that are referenced implicitly from the library could work, but it would look obscure. I'd try again with the solution like this https://github.com/llvm/llvm-project/pull/98701: we'll make lldb-remote-* buildbots build all static libraries (libc++, libc++abi, libunwind) separately (so as not to use '--ignore-duplicate-members' flag) and manually link tests with the whole library so that all internal functions will be present in the binary. https://github.com/llvm/llvm-project/pull/118986 https://github.com/llvm/llvm-project/pull/113935 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][test] Skip libc++ tests if it is linked statically (PR #113935)
https://github.com/dzhidzhoev closed https://github.com/llvm/llvm-project/pull/113935 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][test] Link certain libc++ tests with the whole library (PR #118986)
llvmbot wrote: @llvm/pr-subscribers-lldb Author: Vladislav Dzhidzhoev (dzhidzhoev) Changes Some tests from 'import-std-module' used to fail on the builder https://lab.llvm.org/staging/#/builders/195/builds/4470, since libcxx is set up to be linked statically with test binaries on it. Thus, they were temporarily disabled in #112530. Here, this commit is reverted. When libcxx is linked with a program as an archive of static libraries, functions that aren't used in the program are omitted. Then, jitted expressions from the tests try calling several functions that aren't present in the process image, which causes the failure. Here, --whole-archive linker flags are added to tests' Makefiles to ensure that the whole libc++ is included during static linking. It's applied only to -lc++ and -lc++abi (via --push-state/--pop-state), since for some reason clang Gnu toolchain driver on certain Linux configurations adds -libclang_rt.builtins twice, so we can't just apply --whole-archive to all static libraries. Flags in Makefile.rules and tests' Makefiles are changed to supported the configuration when libc++, libc++abi and libunwind are linked separately (this configuration will be enabled on lldb remote buildbots to be able to control what we link with and avoid duplicate symbols errors). '-nostdlib++ -nostdinc' are added to LDFLAGS in Makefile.rules to avoid duplicate symbols error. Applying them only to CXXFLAGS is not enough since thus they are not passed to the linker call. '--libcxx-include-dir' flag passing has been fixed on Windows host for remote platform in lldb/test/API/lit.cfg.py. --- Full diff: https://github.com/llvm/llvm-project/pull/118986.diff 8 Files Affected: - (modified) lldb/packages/Python/lldbsuite/test/make/Makefile.rules (+2-2) - (modified) lldb/test/API/commands/expression/import-std-module/array/Makefile (+5) - (modified) lldb/test/API/commands/expression/import-std-module/deque-dbg-info-content/Makefile (+5) - (modified) lldb/test/API/commands/expression/import-std-module/list-dbg-info-content/Makefile (+5) - (modified) lldb/test/API/commands/expression/import-std-module/vector-dbg-info-content/Makefile (+5) - (modified) lldb/test/API/commands/expression/import-std-module/vector-of-vectors/Makefile (+5) - (modified) lldb/test/API/lit.cfg.py (+2-1) - (modified) lldb/test/Shell/helper/toolchain.py (+1) ``diff diff --git a/lldb/packages/Python/lldbsuite/test/make/Makefile.rules b/lldb/packages/Python/lldbsuite/test/make/Makefile.rules index d0045ac9f91a77..3972fa5da7faf5 100644 --- a/lldb/packages/Python/lldbsuite/test/make/Makefile.rules +++ b/lldb/packages/Python/lldbsuite/test/make/Makefile.rules @@ -368,7 +368,7 @@ ifeq (,$(filter 1, $(USE_LIBSTDCPP) $(USE_LIBCPP) $(USE_SYSTEM_STDLIB))) ifneq "$(LIBCPP_INCLUDE_TARGET_DIR)" "" CXXFLAGS += -cxx-isystem $(LIBCPP_INCLUDE_TARGET_DIR) endif -LDFLAGS += -L$(LIBCPP_LIBRARY_DIR) -Wl,-rpath,$(LIBCPP_LIBRARY_DIR) -lc++ +LDFLAGS += -L$(LIBCPP_LIBRARY_DIR) -Wl,-rpath,$(LIBCPP_LIBRARY_DIR) -lc++ -lc++abi else USE_SYSTEM_STDLIB := 1 endif @@ -389,7 +389,7 @@ ifeq (1,$(USE_LIBCPP)) ifneq "$(LIBCPP_INCLUDE_TARGET_DIR)" "" CXXFLAGS += -cxx-isystem $(LIBCPP_INCLUDE_TARGET_DIR) endif - LDFLAGS += -L$(LIBCPP_LIBRARY_DIR) -Wl,-rpath,$(LIBCPP_LIBRARY_DIR) -lc++ + LDFLAGS += -nostdlib++ -nostdinc -L$(LIBCPP_LIBRARY_DIR) -Wl,-rpath,$(LIBCPP_LIBRARY_DIR) -lc++ -lc++abi else ifeq "$(OS)" "Android" # Nothing to do, this is already handled in diff --git a/lldb/test/API/commands/expression/import-std-module/array/Makefile b/lldb/test/API/commands/expression/import-std-module/array/Makefile index f938f7428468ab..6f0d77235b59de 100644 --- a/lldb/test/API/commands/expression/import-std-module/array/Makefile +++ b/lldb/test/API/commands/expression/import-std-module/array/Makefile @@ -1,3 +1,8 @@ USE_LIBCPP := 1 CXX_SOURCES := main.cpp + +ifneq ($(OS),Darwin) + LDFLAGS := -Xlinker --push-state -Xlinker --whole-archive -lc++ -lc++abi -Xlinker --pop-state +endif + include Makefile.rules diff --git a/lldb/test/API/commands/expression/import-std-module/deque-dbg-info-content/Makefile b/lldb/test/API/commands/expression/import-std-module/deque-dbg-info-content/Makefile index f938f7428468ab..6f0d77235b59de 100644 --- a/lldb/test/API/commands/expression/import-std-module/deque-dbg-info-content/Makefile +++ b/lldb/test/API/commands/expression/import-std-module/deque-dbg-info-content/Makefile @@ -1,3 +1,8 @@ USE_LIBCPP := 1 CXX_SOURCES := main.cpp + +ifneq ($(OS),Darwin) + LDFLAGS := -Xlinker --push-state -Xlinker --whole-archive -lc++ -lc++abi -Xlinker --pop-state +endif + include Makefile.rules diff --git a/lldb/test/API/commands/expression/import-std-module/list-dbg-info-content/Makefile b/lldb/test/API/c
[Lldb-commits] [lldb] [lldb][test] Enable static linking with libcxx for import-std-module tests (PR #98701)
dzhidzhoev wrote: Closed in favor of https://github.com/llvm/llvm-project/pull/118986 https://github.com/llvm/llvm-project/pull/98701 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][test] Enable static linking with libcxx for import-std-module tests (PR #98701)
https://github.com/dzhidzhoev closed https://github.com/llvm/llvm-project/pull/98701 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][test] Link certain libc++ tests with the whole library (PR #118986)
https://github.com/dzhidzhoev created https://github.com/llvm/llvm-project/pull/118986 Some tests from 'import-std-module' used to fail on the builder https://lab.llvm.org/staging/#/builders/195/builds/4470, since libcxx is set up to be linked statically with test binaries on it. Thus, they were temporarily disabled in #112530. Here, this commit is reverted. When libcxx is linked with a program as an archive of static libraries, functions that aren't used in the program are omitted. Then, jitted expressions from the tests try calling several functions that aren't present in the process image, which causes the failure. Here, --whole-archive linker flags are added to tests' Makefiles to ensure that the whole libc++ is included during static linking. It's applied only to -lc++ and -lc++abi (via --push-state/--pop-state), since for some reason clang Gnu toolchain driver on certain Linux configurations adds -libclang_rt.builtins twice, so we can't just apply --whole-archive to all static libraries. Flags in Makefile.rules and tests' Makefiles are changed to supported the configuration when libc++, libc++abi and libunwind are linked separately (this configuration will be enabled on lldb remote buildbots to be able to control what we link with and avoid duplicate symbols errors). '-nostdlib++ -nostdinc' are added to LDFLAGS in Makefile.rules to avoid duplicate symbols error. Applying them only to CXXFLAGS is not enough since thus they are not passed to the linker call. '--libcxx-include-dir' flag passing has been fixed on Windows host for remote platform in lldb/test/API/lit.cfg.py. >From 66bfb1f84410423d93d8c94d272bf1b89f435bd4 Mon Sep 17 00:00:00 2001 From: Vladislav Dzhidzhoev Date: Sun, 10 Nov 2024 17:04:34 +0100 Subject: [PATCH] [lldb][test] Link certain libc++ tests with the whole library Some tests from 'import-std-module' used to fail on the builder https://lab.llvm.org/staging/#/builders/195/builds/4470, since libcxx is set up to be linked statically with test binaries on it. Thus, they were temporarily disabled in #112530. Here, this commit is reverted. When libcxx is linked with a program as an archive of static libraries, functions that aren't used in the program are omitted. Then, jitted expressions from the tests try calling several functions that aren't present in the process image, which causes the failure. Here, --whole-archive linker flags are added to tests' Makefiles to ensure that the whole libc++ is included during static linking. It's applied only to -lc++ and -lc++abi (via --push-state/--pop-state), since for some reason clang Gnu toolchain driver on certain Linux configurations adds -libclang_rt.builtins twice, so we can't just apply --whole-archive to all static libraries. Flags in Makefile.rules and tests' Makefiles are changed to supported the configuration when libc++, libc++abi and libunwind are linked separately (this configuration will be enabled on lldb remote buildbots to be able to control what we link with and avoid duplicate symbols errors). '-nostdlib++ -nostdinc' are added to LDFLAGS in Makefile.rules to avoid duplicate symbols error. Applying them only to CXXFLAGS is not enough since thus they are not passed to the linker call. '--libcxx-include-dir' flag passing has been fixed on Windows host for remote platform in lldb/test/API/lit.cfg.py. --- lldb/packages/Python/lldbsuite/test/make/Makefile.rules | 4 ++-- .../API/commands/expression/import-std-module/array/Makefile | 5 + .../import-std-module/deque-dbg-info-content/Makefile| 5 + .../import-std-module/list-dbg-info-content/Makefile | 5 + .../import-std-module/vector-dbg-info-content/Makefile | 5 + .../expression/import-std-module/vector-of-vectors/Makefile | 5 + lldb/test/API/lit.cfg.py | 3 ++- lldb/test/Shell/helper/toolchain.py | 1 + 8 files changed, 30 insertions(+), 3 deletions(-) diff --git a/lldb/packages/Python/lldbsuite/test/make/Makefile.rules b/lldb/packages/Python/lldbsuite/test/make/Makefile.rules index d0045ac9f91a77..3972fa5da7faf5 100644 --- a/lldb/packages/Python/lldbsuite/test/make/Makefile.rules +++ b/lldb/packages/Python/lldbsuite/test/make/Makefile.rules @@ -368,7 +368,7 @@ ifeq (,$(filter 1, $(USE_LIBSTDCPP) $(USE_LIBCPP) $(USE_SYSTEM_STDLIB))) ifneq "$(LIBCPP_INCLUDE_TARGET_DIR)" "" CXXFLAGS += -cxx-isystem $(LIBCPP_INCLUDE_TARGET_DIR) endif -LDFLAGS += -L$(LIBCPP_LIBRARY_DIR) -Wl,-rpath,$(LIBCPP_LIBRARY_DIR) -lc++ +LDFLAGS += -L$(LIBCPP_LIBRARY_DIR) -Wl,-rpath,$(LIBCPP_LIBRARY_DIR) -lc++ -lc++abi else USE_SYSTEM_STDLIB := 1 endif @@ -389,7 +389,7 @@ ifeq (1,$(USE_LIBCPP)) ifneq "$(LIBCPP_INCLUDE_TARGET_DIR)" "" CXXFLAGS += -cxx-isystem $(LIBCPP_INCLUDE_TARGET_DIR) endif - LDFLAGS += -L$(LIBCPP_LIBRARY_DIR) -Wl,-rpath,$(LIBCPP_LIBRAR
[Lldb-commits] [lldb] [lldb] Fix typos in `StackFrame.cpp` (PR #118991)
https://github.com/DavidSpickett edited https://github.com/llvm/llvm-project/pull/118991 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] e68a3e4 - [lldb] Fix typos in `StackFrame.cpp` (#118991)
Author: Ping Charoenwet
Date: 2024-12-06T16:08:08Z
New Revision: e68a3e4d0dd349a34c02471438d2e97c2b29e846
URL:
https://github.com/llvm/llvm-project/commit/e68a3e4d0dd349a34c02471438d2e97c2b29e846
DIFF:
https://github.com/llvm/llvm-project/commit/e68a3e4d0dd349a34c02471438d2e97c2b29e846.diff
LOG: [lldb] Fix typos in `StackFrame.cpp` (#118991)
Added:
Modified:
lldb/source/Target/StackFrame.cpp
Removed:
diff --git a/lldb/source/Target/StackFrame.cpp
b/lldb/source/Target/StackFrame.cpp
index dfbac5a572d00a..2633c976c13bf4 100644
--- a/lldb/source/Target/StackFrame.cpp
+++ b/lldb/source/Target/StackFrame.cpp
@@ -670,8 +670,8 @@ ValueObjectSP
StackFrame::LegacyGetValueForVariableExpressionPath(
}
}
- // If we have a non pointer type with a sythetic value then lets check if
- // we have an sythetic dereference specified.
+ // If we have a non-pointer type with a synthetic value then lets check
if
+ // we have a synthetic dereference specified.
if (!valobj_sp->IsPointerType() && valobj_sp->HasSyntheticValue()) {
Status deref_error;
if (valobj_sp->GetCompilerType().IsReferenceType()) {
@@ -686,13 +686,13 @@ ValueObjectSP
StackFrame::LegacyGetValueForVariableExpressionPath(
valobj_sp = valobj_sp->Dereference(deref_error);
if (!valobj_sp || deref_error.Fail()) {
error = Status::FromErrorStringWithFormatv(
- "Failed to dereference sythetic value: {0}", deref_error);
+ "Failed to dereference synthetic value: {0}", deref_error);
return ValueObjectSP();
}
// Some synthetic plug-ins fail to set the error in Dereference
if (!valobj_sp) {
error =
- Status::FromErrorString("Failed to dereference sythetic value");
+ Status::FromErrorString("Failed to dereference synthetic value");
return ValueObjectSP();
}
expr_is_ptr = false;
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Fix typos in `StackFrame.cpp` (PR #118991)
https://github.com/DavidSpickett closed https://github.com/llvm/llvm-project/pull/118991 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Fix typos in `StackFrame.cpp` (PR #118991)
github-actions[bot] wrote: @phnx Congratulations on having your first Pull Request (PR) merged into the LLVM Project! Your changes will be combined with recent changes from other authors, then tested by our [build bots](https://lab.llvm.org/buildbot/). If there is a problem with a build, you may receive a report in an email or a comment on this PR. Please check whether problems have been caused by your change specifically, as the builds can include changes from many authors. It is not uncommon for your change to be included in a build that fails due to someone else's changes, or infrastructure issues. How to do this, and the rest of the post-merge process, is covered in detail [here](https://llvm.org/docs/MyFirstTypoFix.html#myfirsttypofix-issues-after-landing-your-pr). If your change does cause a problem, it may be reverted, or you can revert it yourself. This is a normal part of [LLVM development](https://llvm.org/docs/DeveloperPolicy.html#patch-reversion-policy). You can fix your changes and open a new PR to merge them again. If you don't get any reports, no action is required from you. Your changes are working as expected, well done! https://github.com/llvm/llvm-project/pull/118991 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Fix typo in `StackFrame.cpp` (PR #118991)
https://github.com/DavidSpickett approved this pull request. Thanks, much appreciated! https://github.com/llvm/llvm-project/pull/118991 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Fix typos in `StackFrame.cpp` (PR #118991)
DavidSpickett wrote: I'm going to merge this as is, but there are more uses of `sythetic` in `lldb/` you can fix if you like. None of them should break any tests if changed. https://github.com/llvm/llvm-project/pull/118991 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add a compiler/interpreter of LLDB data formatter bytecode to lldb/examples (PR #113398)
@@ -0,0 +1,238 @@ +Formatter Bytecode +== + +Background +-- + +LLDB provides very rich customization options to display data types (see :doc:`/use/variable/`). To use custom data formatters, developers need to edit the global `~/.lldbinit` file to make sure they are found and loaded. In addition to this rather manual workflow, developers or library authors can ship ship data formatters with their code in a format that allows LLDB automatically find them and run them securely. JDevlieghere wrote: nit ```suggestion LLDB provides rich customization options to display data types (see :doc:`/use/variable/`). To use custom data formatters, developers need to edit the global `~/.lldbinit` file to make sure they are found and loaded. In addition to this rather manual workflow, developers or library authors can ship ship data formatters with their code in a format that allows LLDB automatically find them and run them securely. ``` https://github.com/llvm/llvm-project/pull/113398 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add a compiler/interpreter of LLDB data formatter bytecode to lldb/examples (PR #113398)
@@ -0,0 +1,238 @@ +Formatter Bytecode +== + +Background +-- + +LLDB provides very rich customization options to display data types (see :doc:`/use/variable/`). To use custom data formatters, developers need to edit the global `~/.lldbinit` file to make sure they are found and loaded. In addition to this rather manual workflow, developers or library authors can ship ship data formatters with their code in a format that allows LLDB automatically find them and run them securely. + +An end-to-end example of such a workflow is the Swift `DebugDescription` macro (see https://www.swift.org/blog/announcing-swift-6/#debugging ) that translates Swift string interpolation into LLDB summary strings, and puts them into a `.lldbsummaries` section, where LLDB can find them. JDevlieghere wrote: ```suggestion An end-to-end example of such a workflow is the Swift `DebugDescription` macro (see https://www.swift.org/blog/announcing-swift-6/#debugging) that translates Swift string interpolation into LLDB summary strings, and puts them into a `.lldbsummaries` section, where LLDB can find them. ``` https://github.com/llvm/llvm-project/pull/113398 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add a compiler/interpreter of LLDB data formatter bytecode to lldb/examples (PR #113398)
https://github.com/JDevlieghere edited https://github.com/llvm/llvm-project/pull/113398 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add a compiler/interpreter of LLDB data formatter bytecode to lldb/examples (PR #113398)
@@ -0,0 +1,167 @@
+"""
+This is the llvm::Optional data formatter from llvm/utils/lldbDataFormatters.py
+with the implementation replaced by bytecode.
+"""
+
+from __future__ import annotations
+from formatter_bytecode import *
+import lldb
+
+
+def __lldb_init_module(debugger, internal_dict):
+debugger.HandleCommand(
+"type synthetic add -w llvm "
+f"-l {__name__}.MyOptionalSynthProvider "
+'-x "^MyOptional<.+>$"'
+)
+debugger.HandleCommand(
+"type summary add -w llvm "
+f"-e -F {__name__}.MyOptionalSummaryProvider "
+'-x "^MyOptional<.+>$"'
+)
+
+
+def stringify(bytecode: bytearray) -> str:
+s = ""
+in_hex = False
+for b in bytecode:
+if (b < 32 or b > 127 or chr(b) in ['"', "`", "'"]) or (
+in_hex
+and chr(b).lower()
+in [
+"a",
+"b",
+"c",
+"d",
+"e",
+"f",
+"0",
+"1",
+"2",
+"3",
+"4",
+"5",
+"6",
+"7",
+"8",
+"9",
+]
+):
+s += r"\x" + hex(b)[2:]
+in_hex = True
+else:
+s += chr(b)
+in_hex = False
+return s
+
+
+def evaluate(assembler: str, data: list):
+bytecode = compile(assembler)
+trace = True
+if trace:
+print(
+"Compiled to {0} bytes of bytecode:\n{1}".format(
+len(bytecode), stringify(bytecode)
+)
+)
+result = interpret(bytecode, [], data, False) # trace)
+if trace:
+print("--> {0}".format(result))
+return result
+
+
+# def GetOptionalValue(valobj):
+#storage = valobj.GetChildMemberWithName("Storage")
+#if not storage:
+#storage = valobj
+#
+#failure = 2
+#hasVal =
storage.GetChildMemberWithName("hasVal").GetValueAsUnsigned(failure)
+#if hasVal == failure:
+#return ""
+#
+#if hasVal == 0:
+#return None
+#
+#underlying_type = storage.GetType().GetTemplateArgumentType(0)
+#storage = storage.GetChildMemberWithName("value")
+#return storage.Cast(underlying_type)
JDevlieghere wrote:
```suggestion
```
https://github.com/llvm/llvm-project/pull/113398
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Fix off by one in array index check (PR #118995)
https://github.com/DavidSpickett created https://github.com/llvm/llvm-project/pull/118995 Reported in #116944 / https://pvs-studio.com/en/blog/posts/cpp/1188/. >From 6a227a0ee3e6b4c0091b94f69d348f155575192a Mon Sep 17 00:00:00 2001 From: David Spickett Date: Fri, 6 Dec 2024 16:21:51 + Subject: [PATCH] [lldb] Fix off by one in array index check Reported in #116944 / https://pvs-studio.com/en/blog/posts/cpp/1188/. --- .../ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp| 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp b/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp index 0083b499656979..c43871b08191db 100644 --- a/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp +++ b/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp @@ -3278,7 +3278,7 @@ bool AppleObjCRuntimeV2::NonPointerISACache::EvaluateNonPointerISA( } // If the index is still out of range then this isn't a pointer. - if (index > m_indexed_isa_cache.size()) + if (index >= m_indexed_isa_cache.size()) return false; LLDB_LOGF(log, "AOCRT::NPI Evaluate(ret_isa = 0x%" PRIx64 ")", ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Fix off by one in array index check in Objective C runtime plugin (PR #118995)
https://github.com/DavidSpickett edited https://github.com/llvm/llvm-project/pull/118995 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Fix off by one in array index check in Objective C runtime plugin (PR #118995)
https://github.com/JDevlieghere approved this pull request. https://github.com/llvm/llvm-project/pull/118995 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Fix off by one in array index check in Objective C runtime plugin (PR #118995)
llvmbot wrote: @llvm/pr-subscribers-lldb Author: David Spickett (DavidSpickett) Changes Reported in #116944 / https://pvs-studio.com/en/blog/posts/cpp/1188/. --- Full diff: https://github.com/llvm/llvm-project/pull/118995.diff 1 Files Affected: - (modified) lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp (+1-1) ``diff diff --git a/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp b/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp index 0083b499656979..c43871b08191db 100644 --- a/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp +++ b/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp @@ -3278,7 +3278,7 @@ bool AppleObjCRuntimeV2::NonPointerISACache::EvaluateNonPointerISA( } // If the index is still out of range then this isn't a pointer. - if (index > m_indexed_isa_cache.size()) + if (index >= m_indexed_isa_cache.size()) return false; LLDB_LOGF(log, "AOCRT::NPI Evaluate(ret_isa = 0x%" PRIx64 ")", `` https://github.com/llvm/llvm-project/pull/118995 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] a46ee73 - [lldb] Fix off by one in array index check in Objective C runtime plugin (#118995)
Author: David Spickett Date: 2024-12-06T16:40:57Z New Revision: a46ee733d244333785c0896ce399341fe30240b0 URL: https://github.com/llvm/llvm-project/commit/a46ee733d244333785c0896ce399341fe30240b0 DIFF: https://github.com/llvm/llvm-project/commit/a46ee733d244333785c0896ce399341fe30240b0.diff LOG: [lldb] Fix off by one in array index check in Objective C runtime plugin (#118995) Reported in #116944 / https://pvs-studio.com/en/blog/posts/cpp/1188/. Added: Modified: lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp Removed: diff --git a/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp b/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp index 0083b499656979..c43871b08191db 100644 --- a/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp +++ b/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp @@ -3278,7 +3278,7 @@ bool AppleObjCRuntimeV2::NonPointerISACache::EvaluateNonPointerISA( } // If the index is still out of range then this isn't a pointer. - if (index > m_indexed_isa_cache.size()) + if (index >= m_indexed_isa_cache.size()) return false; LLDB_LOGF(log, "AOCRT::NPI Evaluate(ret_isa = 0x%" PRIx64 ")", ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Fix off by one in array index check in Objective C runtime plugin (PR #118995)
https://github.com/DavidSpickett closed https://github.com/llvm/llvm-project/pull/118995 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add a compiler/interpreter of LLDB data formatter bytecode to lldb/examples (PR #113398)
https://github.com/JDevlieghere approved this pull request. I left a few nits but overall this LGTM. https://github.com/llvm/llvm-project/pull/113398 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add lookup by name to SBValue.child (PR #118814)
@@ -23,6 +23,13 @@ STRING_EXTENSION_OUTSIDE(SBValue) if -count <= key < count: key %= count return self.sbvalue.GetChildAtIndex(key) +elif isinstance(key, str): +if child := self.sbvalue.GetChildMemberWithName(key): +return child +# Support base classes, which are children but not members. +for child in self.sbvalue: +if child.name == key: +return child kastiglione wrote: I agree with your opinions. I think I'd like to avoid introducing complexities in interface/consistency. Should I change this PR to introduce a new `member` property? Or should `value.child[name]` be documented as meaning only `value.GetChildMemberWithName(name)`? cc @jimingham https://github.com/llvm/llvm-project/pull/118814 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add a per-CU API to read the SDK (PR #119022)
@@ -1429,3 +1430,40 @@ PlatformDarwin::ResolveSDKPathFromDebugInfo(Module
&module) {
return path_or_err->str();
}
+
+llvm::Expected>
+PlatformDarwin::GetSDKPathFromDebugInfo(CompileUnit &unit) {
+ ModuleSP module_sp = unit.CalculateSymbolContextModule();
+ if (!module_sp)
+return llvm::createStringError("compile unit has no module");
+ SymbolFile *sym_file = module_sp->GetSymbolFile();
+ if (!sym_file)
+return llvm::createStringError(
+llvm::formatv("No symbol file available for module '{0}'",
+ module_sp->GetFileSpec().GetFilename()));
+
+ const bool found_mismatch = false;
adrian-prantl wrote:
You're right. I copied that from the other API, but it makes no sense here.
https://github.com/llvm/llvm-project/pull/119022
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add a per-CU API to read the SDK (PR #119022)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Adrian Prantl (adrian-prantl)
Changes
---
Full diff: https://github.com/llvm/llvm-project/pull/119022.diff
4 Files Affected:
- (modified) lldb/include/lldb/Target/Platform.h (+32)
- (modified) lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp (+38)
- (modified) lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h (+6)
- (modified) lldb/unittests/SymbolFile/DWARF/XcodeSDKModuleTests.cpp (+7)
``diff
diff --git a/lldb/include/lldb/Target/Platform.h
b/lldb/include/lldb/Target/Platform.h
index f8a2cbf0d5d049..2f954ed18bb830 100644
--- a/lldb/include/lldb/Target/Platform.h
+++ b/lldb/include/lldb/Target/Platform.h
@@ -473,6 +473,38 @@ class Platform : public PluginInterface {
LLVM_PRETTY_FUNCTION, GetName()));
}
+ /// Search CU for the SDK paths the CUs was compiled against. In the
+ /// presence of different SDKs, we try to pick the most appropriate
+ /// one using \ref XcodeSDK::Merge.
+ ///
+ /// \param[in] unit The CU
+ ///
+ /// \returns If successful, returns a pair of a parsed XcodeSDK
+ /// object and a boolean that is 'true' if we encountered
+ /// a conflicting combination of SDKs when parsing the CUs
+ /// (e.g., a public and internal SDK).
+ virtual llvm::Expected>
+ GetSDKPathFromDebugInfo(CompileUnit &unit) {
+return llvm::createStringError(
+llvm::formatv("{0} not implemented for '{1}' platform.",
+ LLVM_PRETTY_FUNCTION, GetName()));
+ }
+
+ /// Returns the full path of the most appropriate SDK for the
+ /// specified compile unit. This function gets this path by parsing
+ /// debug-info (see \ref `GetSDKPathFromDebugInfo`).
+ ///
+ /// \param[in] unit The CU to scan.
+ ///
+ /// \returns If successful, returns the full path to an
+ /// Xcode SDK.
+ virtual llvm::Expected
+ ResolveSDKPathFromDebugInfo(CompileUnit &unit) {
+return llvm::createStringError(
+llvm::formatv("{0} not implemented for '{1}' platform.",
+ LLVM_PRETTY_FUNCTION, GetName()));
+ }
+
bool IsHost() const {
return m_is_host; // Is this the default host platform?
}
diff --git a/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
b/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
index ed0c614cb3576b..90324e388dbf5e 100644
--- a/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
+++ b/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
@@ -29,6 +29,7 @@
#include "lldb/Interpreter/OptionValueProperties.h"
#include "lldb/Interpreter/OptionValueString.h"
#include "lldb/Interpreter/Options.h"
+#include "lldb/Symbol/CompileUnit.h"
#include "lldb/Symbol/ObjectFile.h"
#include "lldb/Symbol/SymbolFile.h"
#include "lldb/Symbol/SymbolVendor.h"
@@ -1429,3 +1430,40 @@ PlatformDarwin::ResolveSDKPathFromDebugInfo(Module
&module) {
return path_or_err->str();
}
+
+llvm::Expected>
+PlatformDarwin::GetSDKPathFromDebugInfo(CompileUnit &unit) {
+ ModuleSP module_sp = unit.CalculateSymbolContextModule();
+ if (!module_sp)
+return llvm::createStringError("compile unit has no module");
+ SymbolFile *sym_file = module_sp->GetSymbolFile();
+ if (!sym_file)
+return llvm::createStringError(
+llvm::formatv("No symbol file available for module '{0}'",
+ module_sp->GetFileSpec().GetFilename()));
+
+ const bool found_mismatch = false;
+ return std::pair{sym_file->ParseXcodeSDK(unit), found_mismatch};
+}
+
+llvm::Expected
+PlatformDarwin::ResolveSDKPathFromDebugInfo(CompileUnit &unit) {
+ auto sdk_or_err = GetSDKPathFromDebugInfo(unit);
+ if (!sdk_or_err)
+return llvm::createStringError(
+llvm::inconvertibleErrorCode(),
+llvm::formatv("Failed to parse SDK path from debug-info: {0}",
+ llvm::toString(sdk_or_err.takeError(;
+
+ auto [sdk, _] = std::move(*sdk_or_err);
+
+ auto path_or_err = HostInfo::GetSDKRoot(HostInfo::SDKOptions{sdk});
+ if (!path_or_err)
+return llvm::createStringError(
+llvm::inconvertibleErrorCode(),
+llvm::formatv("Error while searching for SDK (XcodeSDK '{0}'): {1}",
+ sdk.GetString(),
+ llvm::toString(path_or_err.takeError(;
+
+ return path_or_err->str();
+}
diff --git a/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h
b/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h
index 66a26d2f496776..157709424893c2 100644
--- a/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h
+++ b/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h
@@ -130,6 +130,12 @@ class PlatformDarwin : public PlatformPOSIX {
llvm::Expected
ResolveSDKPathFromDebugInfo(Module &module) override;
+ llvm::Expected>
+ GetSDKPathFromDebugInfo(CompileUnit &unit) override;
+
+ llvm::Expected
+ ResolveSDKPathFromDebugInfo(CompileUnit &unit) override;
+
protected:
static const char *GetCompatibleArch(ArchSpec::Core core, size_t
[Lldb-commits] [lldb] [lldb] Add a per-CU API to read the SDK (PR #119022)
@@ -473,6 +473,38 @@ class Platform : public PluginInterface {
LLVM_PRETTY_FUNCTION, GetName()));
}
+ /// Search CU for the SDK paths the CUs was compiled against. In the
+ /// presence of different SDKs, we try to pick the most appropriate
+ /// one using \ref XcodeSDK::Merge.
+ ///
+ /// \param[in] unit The CU
+ ///
+ /// \returns If successful, returns a pair of a parsed XcodeSDK
+ /// object and a boolean that is 'true' if we encountered
+ /// a conflicting combination of SDKs when parsing the CUs
+ /// (e.g., a public and internal SDK).
+ virtual llvm::Expected>
medismailben wrote:
Not very related to this change but it looks like this base `Platform` class
which is supposed to be generic has some methods specific to the certain
platforms ...
This could be part of @bulbazord Platform refactor but maybe we should have a
`SDK` base class that'd be returned here instead of the the Darwin platform
specific `XcodeSDK` return type.
https://github.com/llvm/llvm-project/pull/119022
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add a per-CU API to read the SDK (PR #119022)
@@ -1429,3 +1430,40 @@ PlatformDarwin::ResolveSDKPathFromDebugInfo(Module
&module) {
return path_or_err->str();
}
+
+llvm::Expected>
+PlatformDarwin::GetSDKPathFromDebugInfo(CompileUnit &unit) {
+ ModuleSP module_sp = unit.CalculateSymbolContextModule();
+ if (!module_sp)
+return llvm::createStringError("compile unit has no module");
+ SymbolFile *sym_file = module_sp->GetSymbolFile();
+ if (!sym_file)
+return llvm::createStringError(
+llvm::formatv("No symbol file available for module '{0}'",
+ module_sp->GetFileSpec().GetFilename()));
+
+ const bool found_mismatch = false;
medismailben wrote:
Looks like this is never mutated and not used at all ... do we actually need
it ?
https://github.com/llvm/llvm-project/pull/119022
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add a per-CU API to read the SDK (PR #119022)
https://github.com/Alexizx0078 approved this pull request. https://github.com/llvm/llvm-project/pull/119022 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Convert the StackFrameList mutex to a shared mutex. (PR #117252)
@@ -128,30 +130,41 @@ bool StackFrameList::DecrementCurrentInlinedDepth() {
}
void StackFrameList::SetCurrentInlinedDepth(uint32_t new_depth) {
+ std::lock_guard guard(m_inlined_depth_mutex);
m_current_inlined_depth = new_depth;
if (new_depth == UINT32_MAX)
m_current_inlined_pc = LLDB_INVALID_ADDRESS;
else
m_current_inlined_pc = m_thread.GetRegisterContext()->GetPC();
}
-void StackFrameList::GetOnlyConcreteFramesUpTo(uint32_t end_idx,
- Unwind &unwinder) {
+void StackFrameList::GetOnlyConcreteFramesUpTo(
+uint32_t end_idx, Unwind &unwinder,
+std::shared_lock &guard) {
jimingham wrote:
I don't understand this comment. In the patch as posted, GetOnly
ConcreteFramesUpTo gets called before the shared lock is dropped and the
exclusive mutex acquired (since it returned right away in its only use, it
seemed nicer to put that dance in the function. That should be clear by moving
the equivalent "get concrete and inlined frames" code into its own function.
https://github.com/llvm/llvm-project/pull/117252
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Convert the StackFrameList mutex to a shared mutex. (PR #117252)
https://github.com/jimingham updated
https://github.com/llvm/llvm-project/pull/117252
>From b0d2179cf01cdd0b07bc43cef2a8c14d282e7ee7 Mon Sep 17 00:00:00 2001
From: Jim Ingham
Date: Tue, 19 Nov 2024 17:38:02 -0800
Subject: [PATCH 1/4] Convert the recursive StackFrameList mutex to a
non-recursive one.
---
lldb/include/lldb/Target/StackFrameList.h | 19 +++-
lldb/source/Target/StackFrameList.cpp | 104 +-
2 files changed, 81 insertions(+), 42 deletions(-)
diff --git a/lldb/include/lldb/Target/StackFrameList.h
b/lldb/include/lldb/Target/StackFrameList.h
index 7d0e7a5b9a71b2..1c59d2e97937da 100644
--- a/lldb/include/lldb/Target/StackFrameList.h
+++ b/lldb/include/lldb/Target/StackFrameList.h
@@ -103,11 +103,15 @@ class StackFrameList {
/// Realizes frames up to (and including) end_idx (which can be greater than
/// the actual number of frames.)
/// Returns true if the function was interrupted, false otherwise.
+ /// Does not hold the StackFrameList mutex.
bool GetFramesUpTo(uint32_t end_idx,
InterruptionControl allow_interrupt = AllowInterruption);
+ /// Does not hold the StackFrameList mutex.
void GetOnlyConcreteFramesUpTo(uint32_t end_idx, Unwind &unwinder);
+ // This gets called without the StackFrameList lock held, callers should
+ // hold the lock.
void SynthesizeTailCallFrames(StackFrame &next_frame);
bool GetAllFramesFetched() { return m_concrete_frames_fetched == UINT32_MAX;
}
@@ -122,6 +126,9 @@ class StackFrameList {
void SetCurrentInlinedDepth(uint32_t new_depth);
+ /// Calls into the stack frame recognizers and stop info to set the most
+ /// relevant frame. This can call out to arbitrary user code so it can't
+ /// hold the StackFrameList mutex.
void SelectMostRelevantFrame();
typedef std::vector collection;
@@ -142,7 +149,14 @@ class StackFrameList {
// TODO: This mutex may not always be held when required. In particular, uses
// of the StackFrameList APIs in lldb_private::Thread look suspect. Consider
// passing around a lock_guard reference to enforce proper locking.
- mutable std::recursive_mutex m_mutex;
+ mutable std::mutex m_mutex;
+
+ // llvm::sys::RWMutex m_stack_list_mutex;
+
+ // Setting the inlined depth should be protected against other attempts to
+ // change it, but since it doesn't mutate the list itself, we can limit the
+ // critical regions it produces by having a separate mutex.
+ mutable std::mutex m_inlined_depth_mutex;
/// A cache of frames. This may need to be updated when the program counter
/// changes.
@@ -171,6 +185,9 @@ class StackFrameList {
const bool m_show_inlined_frames;
private:
+ uint32_t SetSelectedFrameNoLock(lldb_private::StackFrame *frame);
+ lldb::StackFrameSP GetFrameAtIndexNoLock(uint32_t idx);
+
StackFrameList(const StackFrameList &) = delete;
const StackFrameList &operator=(const StackFrameList &) = delete;
};
diff --git a/lldb/source/Target/StackFrameList.cpp
b/lldb/source/Target/StackFrameList.cpp
index 94a381edd5e202..8dc358e492 100644
--- a/lldb/source/Target/StackFrameList.cpp
+++ b/lldb/source/Target/StackFrameList.cpp
@@ -38,7 +38,7 @@ using namespace lldb_private;
StackFrameList::StackFrameList(Thread &thread,
const lldb::StackFrameListSP &prev_frames_sp,
bool show_inline_frames)
-: m_thread(thread), m_prev_frames_sp(prev_frames_sp), m_mutex(),
m_frames(),
+: m_thread(thread), m_prev_frames_sp(prev_frames_sp), m_frames(),
m_selected_frame_idx(), m_concrete_frames_fetched(0),
m_current_inlined_depth(UINT32_MAX),
m_current_inlined_pc(LLDB_INVALID_ADDRESS),
@@ -63,6 +63,7 @@ void StackFrameList::CalculateCurrentInlinedDepth() {
}
uint32_t StackFrameList::GetCurrentInlinedDepth() {
+ std::lock_guard guard(m_inlined_depth_mutex);
if (m_show_inlined_frames && m_current_inlined_pc != LLDB_INVALID_ADDRESS) {
lldb::addr_t cur_pc = m_thread.GetRegisterContext()->GetPC();
if (cur_pc != m_current_inlined_pc) {
@@ -84,11 +85,6 @@ void StackFrameList::ResetCurrentInlinedDepth() {
if (!m_show_inlined_frames)
return;
- std::lock_guard guard(m_mutex);
-
- m_current_inlined_pc = LLDB_INVALID_ADDRESS;
- m_current_inlined_depth = UINT32_MAX;
-
StopInfoSP stop_info_sp = m_thread.GetStopInfo();
if (!stop_info_sp)
return;
@@ -98,6 +94,7 @@ void StackFrameList::ResetCurrentInlinedDepth() {
// We're only adjusting the inlined stack here.
Log *log = GetLog(LLDBLog::Step);
if (inline_depth) {
+std::lock_guard guard(m_inlined_depth_mutex);
m_current_inlined_depth = *inline_depth;
m_current_inlined_pc = m_thread.GetRegisterContext()->GetPC();
@@ -107,6 +104,9 @@ void StackFrameList::ResetCurrentInlinedDepth() {
"depth: %d 0x%" PRIx64 ".\n",
m_current_inlined_depth, m_current_inlined_pc);
} else {
+std::lock_guard guard(m_inlined_de
[Lldb-commits] [lldb] [lldb] Add lookup by name to SBValue.child (PR #118814)
@@ -23,6 +23,13 @@ STRING_EXTENSION_OUTSIDE(SBValue) if -count <= key < count: key %= count return self.sbvalue.GetChildAtIndex(key) +elif isinstance(key, str): +if child := self.sbvalue.GetChildMemberWithName(key): +return child +# Support base classes, which are children but not members. +for child in self.sbvalue: +if child.name == key: +return child jimingham wrote: Might be nice to have both "members" and "bases" so you could easily pull out base class values by name. https://github.com/llvm/llvm-project/pull/118814 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Reduce the frequency of DWARF index progress reporting (PR #118953)
https://github.com/clayborg commented:
Can we build this feature into the Progress class by calling an accessor?
Something like:
```
Progress progress("Manually indexing DWARF", module_desc.GetData(),
total_progress);
progress.SetMinimumNotificationTime(std::chrono::milliseconds(10));
```
Then any busy progress dialogs can take advantage of this timing feature?
https://github.com/llvm/llvm-project/pull/118953
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add lookup by name to SBValue.child (PR #118814)
https://github.com/jimingham edited https://github.com/llvm/llvm-project/pull/118814 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add lookup by name to SBValue.child (PR #118814)
@@ -23,6 +23,13 @@ STRING_EXTENSION_OUTSIDE(SBValue) if -count <= key < count: key %= count return self.sbvalue.GetChildAtIndex(key) +elif isinstance(key, str): +if child := self.sbvalue.GetChildMemberWithName(key): +return child +# Support base classes, which are children but not members. +for child in self.sbvalue: +if child.name == key: +return child kastiglione wrote: I'll introduce a `member` property. I haven't need to access a child base class, by name or otherwise. I'll leave a `bases` property for another time. https://github.com/llvm/llvm-project/pull/118814 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Reduce the frequency of DWARF index progress reporting (PR #118953)
clayborg wrote: And the Progress class can check if the an optional instance variable that contains the minimum time has a value and avoid taking the mutex to keep things faster even when building this into the Progress class? https://github.com/llvm/llvm-project/pull/118953 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add lookup by name to SBValue.child (PR #118814)
@@ -23,6 +23,13 @@ STRING_EXTENSION_OUTSIDE(SBValue) if -count <= key < count: key %= count return self.sbvalue.GetChildAtIndex(key) +elif isinstance(key, str): +if child := self.sbvalue.GetChildMemberWithName(key): +return child +# Support base classes, which are children but not members. +for child in self.sbvalue: +if child.name == key: +return child jimingham wrote: If you have a class with a base class, `SBValue::GetChildAtIndex(0)` and `var.child[0]` return the base class. So the "child" accessor currently returns both base classes and ivars. Moreover, GetChildMemberWithName actually looks into base classes to pull out ivars (it doesn't however handle duplicate names, it only returns the first one it finds with the matching name which isn't great...) So GetChildMemberWithName will pull out children that aren't even in the indexed `child` array. That does argue to me that `child` is the wrong property to use for this. https://github.com/llvm/llvm-project/pull/118814 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Add attach & corefile templates (PR #118894)
walter-erquinigo wrote: You are a good person, @JDevlieghere https://github.com/llvm/llvm-project/pull/118894 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
