[lldb-dev] Logging for multiple targets

Hi lldb-dev, Looking at a log produced by multiple targets I hardly can find out which message corresponds to which target. I find a way to distinct them, e.g. by prepending messages with "[target_id]". Putting an id to every message manually is not a choice obviously. What do you think about

Re: [lldb-dev] Need help with failing LLDB tests on Windows

On Windows one should run debug version of Python (python_d.exe) to load debug version of liblldb.dll. I hope this will help you. From: lldb-dev On Behalf Of Adrian McCarthy via lldb-dev Sent: Tuesday, November 10, 2020 4:00 AM To: Ted Woodward Cc: LLDB Subject: Re: [lldb-dev] Need help with

Re: [lldb-dev] Remote debug arm bare metal target with lldb - load executable to target

Try this: `target modules load --load --set-pc-to-entry --slide 0`. From: lldb-dev On Behalf Of via lldb-dev Sent: Wednesday, July 22, 2020 7:10 PM To: lldb-dev@lists.llvm.org Subject: [lldb-dev] Remote debug arm bare metal target with lldb - load executable to target Hello, we are trying to

Re: [lldb-dev] Identifying instructions that definitely access memory

Hi Vangelis, Not sure this will help you, but you can try to compare llvm::MachineInstr::getOpcode() with TargetOpcode::G_LOAD and TargetOpcode::G_STORE if you can obtain a MachineInstr instance. It also may have sense to ask llvm-dev for a proper solution. From: lldb-dev On Behalf Of

Re: [lldb-dev] SB API is not working properly with OSPython plugin

r Polyakov ; LLDB > > Subject: Re: [lldb-dev] SB API is not working properly with OSPython > plugin > > > >> On Feb 21, 2019, at 11:22 AM, Tatyana Krasnukha via lldb-dev >> wrote: >> >>> lldb Process::SetPrivateState (stopped) stop_id =

Re: [lldb-dev] SB API is not working properly with OSPython plugin

-dev] SB API is not working properly with OSPython plugin > On Feb 21, 2019, at 11:22 AM, Tatyana Krasnukha via lldb-dev > wrote: > > > lldb Process::SetPrivateState (stopped) stop_id = 2 > > error: error: process must be stopped. > > These two lines

Re: [lldb-dev] SB API is not working properly with OSPython plugin

> lldb Process::SetPrivateState (stopped) stop_id = 2 > error: error: process must be stopped. These two lines are printed from different threads, you cannot be sure the real order of execution is the same. The plugin should subscribe on public state change events and wait until one

[lldb-dev] Remove "Either" or not?

Hello, lldb\include\lldb\Utility\Either.h seems dead, at least I couldn't find any usages. I could enhance it with Bind function for composing monadic functions and add tests to show usage examples. Or just remove it if no one needs it? ___ lldb-dev

Re: [lldb-dev] Handling callable addresses

de. This should be gotten from the architecture plugin. > GetBreakableLoadAddress is even worse, there's ~150 lines of MIPS specific > code in Target.cpp, which seems really wrong to me. > > > > > > Not really answering your question except formally none of this cod

[lldb-dev] Handling callable addresses

Hi, It seems Target::GetCallableLoadAddress does equivalent things for arm/thumb and for mipses, just written in different forms. May I join these cases together? ___ lldb-dev mailing list lldb-dev@lists.llvm.org

[lldb-dev] NativeThreadProtocol

Hello, I glanced cursorily at the NativeThreadProtocol.cpp and was confused with SaveAllRegisters method calls WriteAllRegisterValues and RestoreAllRegisters calls ReadAllRegisterValues. It seems they are inverted. ___ lldb-dev mailing list

Re: [lldb-dev] Question about LLVMCDisassembler

...@lists.llvm.org] On Behalf Of Tatyana Krasnukha via lldb-dev Sent: Friday, 22 December, 2017 9:06 PM To: lldb-dev@lists.llvm.org Subject: [lldb-dev] Question about LLVMCDisassembler Hello, Could someone answer two questions about this code, please DisassemblerLLVMC::LLVMCDisassembler::LLVMCDisassembler

[lldb-dev] Question about LLVMCDisassembler

Hello, Could someone answer two questions about this code, please DisassemblerLLVMC::LLVMCDisassembler::LLVMCDisassembler starting from line 897: m_reg_info_ap.reset(curr_target->createMCRegInfo(triple)); m_subtarget_info_ap.reset( curr_target->createMCSubtargetInfo(triple, cpu,

Re: [lldb-dev] purpose of ProcessGDBRemote::m_flags

riants of GDB remote servers and it should encapsulate all that is needed to use any GDB server. On Nov 3, 2017, at 7:27 AM, Tatyana Krasnukha via lldb-dev <lldb-dev@lists.llvm.org<mailto:lldb-dev@lists.llvm.org>> wrote: Hello, I have questions about ProcessGDBRemote::m_flags

[lldb-dev] purpose of ProcessGDBRemote::m_flags

Hello, I have questions about ProcessGDBRemote::m_flags member. Seems like it is never used. What is the purpose of it and what is the reason to do accessors protected, even constant getter? And other question: isn't it better to move this member to new plugin Architecture to be able to store

Re: [lldb-dev] did anyone konw LLDB support lldb + openocd to run dotest.py in bare board like ARM or other non-x86 architecture?

I guess 2 ways of remote debugging: * “remote-linux” platform with process attach instead of process launch * “remote-gdb-server” platform with process launch. As I understood, both of them use lldb-server. To execute tests remotely you may run dotest.py with according options

Re: [lldb-dev] How can lldb debug a remote bare-metal platform?

> -Original Message- > From: Greg Clayton [mailto:clayb...@gmail.com] > Sent: Tuesday, 19 September, 2017 9:48 PM > To: Tatyana Krasnukha > Cc: lldb-dev@lists.llvm.org > Subject: Re: [lldb-dev] How can lldb debug a remote bare-metal platform? > > So the

Re: [lldb-dev] How can lldb debug a remote bare-metal platform?

Hello, ‘target modules load -lp’ fails with error “one or more section name + load address pair must be specified”, works only with --slide option. Another issue is that if breakpoint is set, Process::WriteMemory return zero and ObjectFile::LoadInMemory interprets it as an error without

Re: [lldb-dev] lldb_private::RegisterContext vs lldb_private::RegisterInfoInterface

Hi Ramana, Looks like just a naming issue - classes derived from RegisterInfoInterface should be named as RegisterInfo_, because they just implement a common interface to access targets's register info structures. Whereas RegisterContext relates to certain execution context and concrete frame,

Re: [lldb-dev] Symbolic information in disassembler output

o be built into llvm::MCInst. On Aug 31, 2017, at 10:42 AM, Tatyana Krasnukha via lldb-dev <lldb-dev@lists.llvm.org<mailto:lldb-dev@lists.llvm.org>> wrote: Hello, As I understand it, old disassembler (based on libedis) could print symbolic information instead/beside address operand

[lldb-dev] Symbolic information in disassembler output

Hello, As I understand it, old disassembler (based on libedis) could print symbolic information instead/beside address operand of an instruction. And it looks like there is not such ability in disassembler now. Is this responsibility shifted on some other component of lldb? Or it was

Re: [lldb-dev] Skipping registers when restore register state after a function call

re machinery might get confused by the fact that the register write failed. Maybe we could try adding a read-only field to the register info struct to let the machinery know it should not touch this register? On 13 July 2017 at 12:26, Tatyana Krasnukha via lldb-dev <lldb-dev@lists.

Re: [lldb-dev] Skipping registers when restore register state after a function call

y know it should not touch this register? On 13 July 2017 at 12:26, Tatyana Krasnukha via lldb-dev <lldb-dev@lists.llvm.org> wrote: > I'm porting lldb to baremetal ARC target and now I try to call functions from > expressions. It works well until ThreadPlanCallFunction tries to restore > reg

Re: [lldb-dev] Skipping registers when restore register state after a function call

gister, for which we do have a solution) On 13 July 2017 at 12:06, Tatyana Krasnukha via lldb-dev <lldb-dev@lists.llvm.org> wrote: > Hi, > > I need an ability to skip some registers when lldb restores register > state after a function call. Didn’t find something like gdb “

[lldb-dev] Skipping registers when restore register state after a function call

Hi, I need an ability to skip some registers when lldb restores register state after a function call. Didn't find something like gdb "save-restore" register property. Is there any way to avoid restoring of some registers beside hardcoding its names in