[lldb-dev] Logging for multiple targets

2020-11-30 Thread Tatyana Krasnukha via lldb-dev
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

2020-11-10 Thread Tatyana Krasnukha via lldb-dev
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

2020-07-30 Thread Tatyana Krasnukha via lldb-dev
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 de

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

2019-11-07 Thread Tatyana Krasnukha via lldb-dev
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 Vangelis

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

2019-02-25 Thread Tatyana Krasnukha via lldb-dev
> Cc: Alexander 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::SetPrivate

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

2019-02-21 Thread Tatyana Krasnukha via lldb-dev
ject: 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 = 2 > > error: error: process must be stopped. > > T

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

2019-02-21 Thread Tatyana Krasnukha via lldb-dev
> 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?

2018-08-07 Thread Tatyana Krasnukha via lldb-dev
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 ma

Re: [lldb-dev] Handling callable addresses

2018-06-22 Thread Tatyana Krasnukha via lldb-dev
et code. 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 o

[lldb-dev] Handling callable addresses

2018-06-21 Thread Tatyana Krasnukha via lldb-dev
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 http://lists.llvm.org/cgi-bin/mailman/l

[lldb-dev] NativeThreadProtocol

2018-03-28 Thread Tatyana Krasnukha via lldb-dev
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 lldb-dev@l

Re: [lldb-dev] Question about LLVMCDisassembler

2017-12-26 Thread Tatyana Krasnukha via lldb-dev
-boun...@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::LLVMCDisasse

[lldb-dev] Question about LLVMCDisassembler

2017-12-22 Thread Tatyana Krasnukha via lldb-dev
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, featur

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

2017-11-03 Thread Tatyana Krasnukha via lldb-dev
rs 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 mailto:lldb-dev@lists.llvm.org>> wrote: Hello, I have questions about ProcessGDBRemote::m_flags member. Seems like it is never used. What is the purpose of it

[lldb-dev] purpose of ProcessGDBRemote::m_flags

2017-11-03 Thread Tatyana Krasnukha via lldb-dev
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 d

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

2017-10-28 Thread Tatyana Krasnukha via lldb-dev
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 (platform-

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

2017-10-27 Thread Tatyana Krasnukha via lldb-dev
It seems that ‘process launch’ tries to launch gdb-server that is already started manually, try to attach instead. I also met ‘remote-gdb-server’ platform, maybe it fits your goal better? Didn’t you try to do something like this? dotest.py --platform-name=remote-gdb-server --platfrom-url=connec

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

2017-09-19 Thread Tatyana Krasnukha via lldb-dev
> -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 problem is bare boards have no dyna

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

2017-09-19 Thread Tatyana Krasnukha via lldb-dev
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 setti

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

2017-09-13 Thread Tatyana Krasnukha via lldb-dev
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

2017-08-31 Thread Tatyana Krasnukha via lldb-dev
features need to be built into llvm::MCInst. On Aug 31, 2017, at 10:42 AM, Tatyana Krasnukha via lldb-dev 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 of an instruct

[lldb-dev] Symbolic information in disassembler output

2017-08-31 Thread Tatyana Krasnukha via lldb-dev
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 considered

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

2017-07-14 Thread Tatyana Krasnukha via lldb-dev
ct 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 wrote: > I'm porting lldb to baremetal ARC target and now I try

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

2017-07-13 Thread Tatyana Krasnukha via lldb-dev
3 July 2017 at 12:26, Tatyana Krasnukha via lldb-dev 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 > register state. In that moment my gdb-server crashes because of

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

2017-07-13 Thread Tatyana Krasnukha via lldb-dev
have a solution) On 13 July 2017 at 12:06, Tatyana Krasnukha via lldb-dev 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 “save-restore” > register property. Is there any

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

2017-07-13 Thread Tatyana Krasnukha via lldb-dev
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 GDBRemoteRegisterContext::WriteAllRegisterVa