[lldb-dev] Logging for multiple targets

[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 having an optional target_id/execution_context inside 
the Log class or having an additional map with target-dependent logs? Maybe 
there are other options I missed?

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[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 failing LLDB tests on Windows

Thanks for all the info and pointers.  That's helping me zero in on the problem.

This category of the failures appears to all be dotest.py tests, so it makes 
sense that it's the second import statement (per Pavel's explanation).

The module is not being found because it's actually named _lldb_d.pyd.  
Apparently the `_d` suffix is because I'm building debug.  That seems 
consistent with Stella's experience.

However, I've been building debug since before these problems arose.  (In fact, 
I've been working on fixes for a small number of tests that only fail in debug, 
because of an assertion that detects the problem.)

Ted's got me thinking that it was working due to a symlink that somehow got 
blown away and/or isn't being recreated by the build.  If I recall correctly, 
the symlinks on Windows are created using ln.exe, which may come from GnuWin32 
or from git/usr/bin.  In my case, it's git/usr/bin.  There seem to have been 
many git updates in the past couple months, so perhaps one of those updates 
tweaked ln.exe.  That could have been the trigger for me.  Folks who didn't 
take the git update or who are configured to prefer GnuWin32 tools might not 
have been affected.

I'll let you know what I eventually find.

On Wed, Nov 4, 2020 at 12:05 PM Ted Woodward 
mailto:tedw...@quicinc.com>> wrote:
To expand a bit on what Pavel has written, the lldb module should be in 
\lib\site-packages\lldb . In that directory is a file, _lldb.pyd, that 
should be a copy of \bin\liblldb.dll .

Do both files exist? Is _lldb.pyd a copy of liblldb.dll?
See function create_relative_symlink in llvm-project/lldb/CMakeLists.txt for 
the copy (on non-unix hosts) procedure.

Did you recently change your version of swig? LLDB requires swig 2, but, as you 
pointed out last year, there are issues with some versions of swig. We use 
4.0.1 on Windows.

> -Original Message-
> From: lldb-dev 
> mailto:lldb-dev-boun...@lists.llvm.org>> On 
> Behalf Of Pavel Labath
> via lldb-dev
> Sent: Wednesday, November 4, 2020 2:49 AM
> To: Adrian McCarthy mailto:amcca...@google.com>>; LLDB 
>  d...@lists.llvm.org>
> Subject: [EXT] Re: [lldb-dev] Need help with failing LLDB tests on Windows
>
> On 04/11/2020 01:53, Adrian McCarthy via lldb-dev wrote:
> > For the past couple weeks, I've been trying to figure out why
> > approximately 900+ LLDB tests have been failing for me on my local
> > Windows builds.  Bisect turned up nothing--the "good" version that was
> > working for me no longer works.  Since nobody else seems to be seeing
> > these failures, I suspect it's something environmental.
> >
> > There are three categories of errors.  I'm currently focused on
> > failures that look like this:
> >
> > FAIL: lldb-api :: lang/objc/unicode-string/TestUnicodeString.py (732
> > of 2180)
> >  TEST 'lldb-api ::
> > lang/objc/unicode-string/TestUnicodeString.py' FAILED
> > 
> > Script:
> > --
> > C:/Program Files/Python38/python.exe
> > D:/src/llvm/llvm-project/lldb\test\API\dotest.py -S nm -u CXXFLAGS
> > -u CFLAGS --enable-crash-dialog --env
> > LLVM_LIBS_DIR=D:/src/llvm/build/ninja_dbg/./lib --arch x86_64
> > --build-dir D:/src/llvm/build/ninja_dbg/lldb-test-build.noindex -s
> > D:/src/llvm/build/ninja_dbg/lldb-test-traces --lldb-module-cache-dir
> > D:/src/llvm/build/ninja_dbg/lldb-test-build.noindex/module-cache-
> lldb\lldb-api
> > --clang-module-cache-dir
> > D:/src/llvm/build/ninja_dbg/lldb-test-build.noindex/module-cache-
> clang\lldb-api
> > --executable D:/src/llvm/build/ninja_dbg/./bin/lldb.exe --compiler
> > D:/src/llvm/build/ninja_dbg/bin/clang.exe --dsymutil
> > D:/src/llvm/build/ninja_dbg/./bin/dsymutil.exe --filecheck
> > D:/src/llvm/build/ninja_dbg/./bin/FileCheck.exe --yaml2obj
> > D:/src/llvm/build/ninja_dbg/./bin/yaml2obj.exe --lldb-libs-dir
> > D:/src/llvm/build/ninja_dbg/./lib
> > D:\src\llvm\llvm-project\lldb\test\API\lang\objc\unicode-string -p
> > TestUnicodeString.py
> > --
> > Exit Code: 1
> >
> > Command Output (stdout):
> > --
> > lldb version 12.0.0 
> > (https://github.com/llvm/llvm-project.git
> > 
> > >
> >  revision
> > 

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

[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 debug firmware running on a stm32 using OpenOCD and LLDB.
GNU-GDB provides a 'load' command to load the sections from an ELF file to the 
target device.
We have tried to use 'target modules load --load' command to load ELF sections 
to a specific address, but that didn't work.
If there is a way at all, what is the proper way to load the executable to the 
target device with LLDB?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[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 
Tsiatsianas via lldb-dev
Sent: Tuesday, November 5, 2019 3:43 PM
To: via lldb-dev 
Cc: Vangelis Tsiatsianas 
Subject: Re: [lldb-dev] Identifying instructions that definitely access memory

Hello,

I decided to try once more with a follow-up email, since my previous one got no 
responses (I hope it’s not considered rude to send more than one message in a 
row for a particular question).

To sum up and clarify my previous question, what I need is a way to track 
memory stores and save both the old and the new value of the memory location 
being modified.

My thinking so far:

  1.  Recognize the instructions that definitely access memory before they 
execute, based on their opcode.
  2.  Tell whether each operand is a register or a memory location.
  3.  If it’s a memory location, check whether it is a load or store 
destination.
  4.  In case it is a store destination, fetch and save current value from 
memory.
  5.  Execute instruction.
  6.  Fetch and save new value from memory.

However, I was not able to find a cross-architecture API that covers all of the 
conditions above and more specifically Instruction::DoesStore() and 
Operand::IsStoreDestination().

Last but not least, I should notice that the target is executed in single-step 
mode, so I do have control right before and after the execution of every 
instruction.

Thanks, again, in advance! 


― Vangelis



On 21 Oct 2019, at 08:54, Vangelis Tsiatsianas 
mailto:vangeli...@icloud.com>> wrote:

Hello,

I am looking for a way to identify loads, stores and any other kind of 
instruction that definitely perform memory access and extract the address 
operand(s), however I was not able to find a cross-architecture API. The 
closest I stumbled upon are "MCInstrDesc::mayLoad()" and 
"MCInstrDesc::mayStore()", but I understand that their results are just a hint, 
so I would then need to examine the instruction name or opcode in order to find 
out whether it’s actually a load or store and which operand(s) is (are) memory 
address(es) and also do so for each architecture separately, which I would 
really like to avoid.

Is there a way to identify such instructions either by examining them through 
the disassembler (e.g. "DoesLoad()" | "DoesStore()") before they execute or 
right after they perform any kind of memory access?

Thank you very much, in advance! 


― Vangelis



___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Tatyana Krasnukha via lldb-dev]

This is ThreadList::GetSelectedThread, it calls 
OperatingSystemPython::UpdateThreadList indirectly.

However, I cannot reproduce the error Alexander gets, due to a deadlock.

-Original Message-
From: jing...@apple.com  
Sent: Friday, February 22, 2019 2:14 AM
To: Tatyana Krasnukha 
Cc: Alexander Polyakov ; LLDB 
Subject: Re: [lldb-dev] SB API is not working properly with OSPython plugin

What's triggering one of the OS Plugin methods to get run on this separate 
thread?  I would expect SetPrivateState would just cause the private stop event 
to get broadcast to the private state thread, and then that would wake up and 
then it would be the one to call the OS Plugin to do it's job.  That's how the 
GDBRemote plugin works, for instance.

Jim


> On Feb 21, 2019, at 2:54 PM, Tatyana Krasnukha 
>  wrote:
> 
> That clarified things, thanks!
> 
> I think, this is the reason:
> 
> ProcessRunLock ::GetRunLock() {  if 
> (m_private_state_thread.EqualsThread(Host::GetCurrentThread()))
>return m_private_run_lock;
>  else
>return m_public_run_lock;
> }
> 
> In our case the current thread is not m_private_state_thread. I create a 
> separate thread for waiting a processor to halt and then SetPrivateState. It 
> seems, that was an inappropriate approach.
> 
> -Original Message-
> From: jing...@apple.com 
> Sent: Thursday, February 21, 2019 11:58 PM
> To: Tatyana Krasnukha 
> 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::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 
>> comes (correct me if I’m wrong about that).
> 
> That's not right.  When the process stops, but before lldb broadcasts a 
> public stop event, it will query the OS Plugin directly to build up the 
> thread list.  It needs to do that before it declares a public stop because it 
> uses the thread list to reason about whether to declare a public stop or not. 
>  So the OS Plugin (and BTW the Thread Step Plan plugin is in the same boat) 
> have to run after a private stop but before public one.  There isn't a 
> principled way to do that.  The best we have at present is a hack that says 
> "if you are running on the private state thread, then you get to do things 
> between private & public stop as if there were a public stop".  Cleaning that 
> up is item 5 on the lldb Projects page if anyone is interested...
> 
> Jim
> 
>> 
>> From: lldb-dev  On Behalf Of 
>> Alexander Polyakov via lldb-dev
>> Sent: Thursday, February 21, 2019 9:54 PM
>> To: Jim Ingham 
>> Cc: LLDB 
>> Subject: Re: [lldb-dev] SB API is not working properly with OSPython 
>> plugin
>> 
>> It seems that the process plugin uses the Process::SetPrivateState at the 
>> right time. If you look at the log, you will see that the process is already 
>> in the 'private stopped' state when the OS plugin is invoked.
>> 
>> (lldb) c
>> lldb Process::Resume -- locking run lock
>> lldb Process::PrivateResume() m_stop_id = 1, public state: 
>> stopped private state: stopped
>> lldb Process::SetPrivateState (running)
>> intern-state Process::ShouldBroadcastEvent (0x1abea90) => new state: 
>> running, last broadcast state: running - YES
>> intern-state Process::HandlePrivateEvent (pid = 1) broadcasting new 
>> state running (old state stopped) to public
>> intern-state Process::PushProcessIOHandler pushing IO handler
>> intern-state Process::HandlePrivateEvent updated m_iohandler_sync to 1
>> lldb Process thinks the process has resumed.
>> intern-state timeout = , event_sp)...
>> lldb waited from m_iohandler_sync to change from 0. New value is 
>> 1.
>> dbg.evt-handler  Process::SetPublicState (state = running, restarted 
>> =
>> 0) Process 1 resuming
>> lldb Process::SetPrivateState (stopped)
>> lldb Process::SetPrivateState (stopped) stop_id = 2
>> error: error: process must be stopped.
>> intern-state Process::ShouldBroadcastEvent (0x7f3e9c007450) => new 
>> state: stopped, last broadcast state: stopped - YES
>> intern-state Process::HandlePrivateEvent (pid = 1) broadcasting new 
>> state stopped (o

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

[Tatyana Krasnukha via lldb-dev]

That clarified things, thanks!

I think, this is the reason:

ProcessRunLock ::GetRunLock() {
  if (m_private_state_thread.EqualsThread(Host::GetCurrentThread()))
return m_private_run_lock;
  else
return m_public_run_lock;
}

In our case the current thread is not m_private_state_thread. I create a 
separate thread for waiting a processor to halt and then SetPrivateState. It 
seems, that was an inappropriate approach.

-Original Message-
From: jing...@apple.com  
Sent: Thursday, February 21, 2019 11:58 PM
To: Tatyana Krasnukha 
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::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 
> comes (correct me if I’m wrong about that).

That's not right.  When the process stops, but before lldb broadcasts a public 
stop event, it will query the OS Plugin directly to build up the thread list.  
It needs to do that before it declares a public stop because it uses the thread 
list to reason about whether to declare a public stop or not.  So the OS Plugin 
(and BTW the Thread Step Plan plugin is in the same boat) have to run after a 
private stop but before public one.  There isn't a principled way to do that.  
The best we have at present is a hack that says "if you are running on the 
private state thread, then you get to do things between private & public stop 
as if there were a public stop".  Cleaning that up is item 5 on the lldb 
Projects page if anyone is interested...

Jim

>  
> From: lldb-dev  On Behalf Of 
> Alexander Polyakov via lldb-dev
> Sent: Thursday, February 21, 2019 9:54 PM
> To: Jim Ingham 
> Cc: LLDB 
> Subject: Re: [lldb-dev] SB API is not working properly with OSPython 
> plugin
>  
> It seems that the process plugin uses the Process::SetPrivateState at the 
> right time. If you look at the log, you will see that the process is already 
> in the 'private stopped' state when the OS plugin is invoked.
> 
> (lldb) c
> lldb Process::Resume -- locking run lock
> lldb Process::PrivateResume() m_stop_id = 1, public state: 
> stopped private state: stopped
> lldb Process::SetPrivateState (running)
> intern-state Process::ShouldBroadcastEvent (0x1abea90) => new state: 
> running, last broadcast state: running - YES
> intern-state Process::HandlePrivateEvent (pid = 1) broadcasting new state 
> running (old state stopped) to public
> intern-state Process::PushProcessIOHandler pushing IO handler
> intern-state Process::HandlePrivateEvent updated m_iohandler_sync to 1
> lldb Process thinks the process has resumed.
> intern-state timeout = , event_sp)...
> lldb waited from m_iohandler_sync to change from 0. New value is 
> 1.
> dbg.evt-handler  Process::SetPublicState (state = running, restarted = 
> 0) Process 1 resuming
> lldb Process::SetPrivateState (stopped)
> lldb Process::SetPrivateState (stopped) stop_id = 2
> error: error: process must be stopped.
> intern-state Process::ShouldBroadcastEvent (0x7f3e9c007450) => new state: 
> stopped, last broadcast state: stopped - YES
> intern-state Process::HandlePrivateEvent (pid = 1) broadcasting new state 
> stopped (old state running) to public
> intern-state timeout = , event_sp)...
> dbg.evt-handler  Process::SetPublicState (state = stopped, restarted = 
> 0) dbg.evt-handler  Process::SetPublicState (stopped) -- unlocking run 
> lock
> 
>  
> On Fri, Feb 15, 2019 at 1:38 AM Jim Ingham  wrote:
> Your plugin should have set the private state to stopped when it figures out 
> however it does that the process has stopped.  The API is 
> Process::SetPrivateState.  Is that happening at the right time?
>  
> Jim
>  
> 
> 
> On Feb 14, 2019, at 1:50 PM, Alexander Polyakov  
> wrote:
>  
> I found out that the plugin works well with an x86 application, so I think 
> that the problem is in my process plugin. Maybe you know a place where to 
> start looking for an issue?
>  
> On Thu, Feb 14, 2019 at 10:56 PM Jim Ingham  wrote:
> The simplest thing possible to reproduce the failure.  So some OS_Plugin 
> implementation which tries to look up a global like this and fails, and some 
> program source I can run it under that provides said global.  That way I can 
> easily watch it fails as you describe when the plugin gets activated, and see 
> why it i

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

[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 
comes (correct me if I’m wrong about that).

From: lldb-dev  On Behalf Of Alexander 
Polyakov via lldb-dev
Sent: Thursday, February 21, 2019 9:54 PM
To: Jim Ingham 
Cc: LLDB 
Subject: Re: [lldb-dev] SB API is not working properly with OSPython plugin

It seems that the process plugin uses the Process::SetPrivateState at the right 
time. If you look at the log, you will see that the process is already in the 
'private stopped' state when the OS plugin is invoked.
(lldb) c
lldb Process::Resume -- locking run lock
lldb Process::PrivateResume() m_stop_id = 1, public state: stopped 
private state: stopped
lldb Process::SetPrivateState (running)
intern-state Process::ShouldBroadcastEvent (0x1abea90) => new state: 
running, last broadcast state: running - YES
intern-state Process::HandlePrivateEvent (pid = 1) broadcasting new state 
running (old state stopped) to public
intern-state Process::PushProcessIOHandler pushing IO handler
intern-state Process::HandlePrivateEvent updated m_iohandler_sync to 1
lldb Process thinks the process has resumed.
intern-state timeout = , event_sp)...
lldb waited from m_iohandler_sync to change from 0. New value is 1.
dbg.evt-handler  Process::SetPublicState (state = running, restarted = 0)
Process 1 resuming
lldb Process::SetPrivateState (stopped)
lldb Process::SetPrivateState (stopped) stop_id = 2
error: error: process must be stopped.
intern-state Process::ShouldBroadcastEvent (0x7f3e9c007450) => new state: 
stopped, last broadcast state: stopped - YES
intern-state Process::HandlePrivateEvent (pid = 1) broadcasting new state 
stopped (old state running) to public
intern-state timeout = , event_sp)...
dbg.evt-handler  Process::SetPublicState (state = stopped, restarted = 0)
dbg.evt-handler  Process::SetPublicState (stopped) -- unlocking run lock

On Fri, Feb 15, 2019 at 1:38 AM Jim Ingham 
mailto:jing...@apple.com>> wrote:
Your plugin should have set the private state to stopped when it figures out 
however it does that the process has stopped.  The API is 
Process::SetPrivateState.  Is that happening at the right time?

Jim



On Feb 14, 2019, at 1:50 PM, Alexander Polyakov 
mailto:polyakov@gmail.com>> wrote:

I found out that the plugin works well with an x86 application, so I think that 
the problem is in my process plugin. Maybe you know a place where to start 
looking for an issue?

On Thu, Feb 14, 2019 at 10:56 PM Jim Ingham 
mailto:jing...@apple.com>> wrote:
The simplest thing possible to reproduce the failure.  So some OS_Plugin 
implementation which tries to look up a global like this and fails, and some 
program source I can run it under that provides said global.  That way I can 
easily watch it fails as you describe when the plugin gets activated, and see 
why it isn’t allowing this call on private stop.

Jim



On Feb 14, 2019, at 11:50 AM, Alexander Polyakov 
mailto:polyakov@gmail.com>> wrote:

Sure, could you describe in more detail which example may help you?

чт, 14 февр. 2019 г. в 22:36, Jim Ingham 
mailto:jing...@apple.com>>:
That’s a little complicated…

lldb has two levels of stop state - private stops and public stops.  When the 
process gets notification from the underlying process plugin that the process 
stopped, it raises a private stop event.  That gets handled by the ShouldStop 
mechanism on the private state thread in lldb, and then if the stop is judged 
interesting to the user, it gets rebroadcast as a public stop.

For instance, when you issue a “step” command, lldb will stop and start the 
process multiple times as it walks through the source line.  But only the last 
of those stops are relevant to the user of LLDB, so all the other ones exist 
only as private stops.

The SB API’s for the most part should only consider a “publicly stopped” 
process accessible.  After all, you wouldn’t want some API to succeed sometimes 
if you happen to catch it in the middle of a private stop.

But the OperatingSystem plugin needs to get called right after a private stop, 
so it can provide threads for the ShouldStop mechanism.  We should really have 
some formal mechanism whereby things like the OS plugin can request elevated 
rights in the SB API’s, so that they can run at private stop time.  IIRC, we 
instead have a hack where SB API calls that run on the private state thread are 
blanket allowed to run at private stop.  The xnu Operating System plugin 
successfully gets global values to look up its threads.  So I’m not sure why 
that isn’t working for you.

Can you cook up a simple example showing the failure and I’ll have a look?

Jim



On 

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

[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 mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Handling callable addresses

[Tatyana Krasnukha via lldb-dev]

Could you suggest any public buildbots where I can test such things for ARM, 
MIPS and others?

> -Original Message-
> From: Pavel Labath 
> Sent: Friday, 22 June, 2018 1:23 PM
> To: Tatyana Krasnukha 
> Cc: Jim Ingham ; LLDB ; Greg
> Clayton 
> Subject: Re: [lldb-dev] Handling callable addresses
> 
> +1
> 
> While creating the architecture plugin, I noticed that this code could be
> moved there, but never got around to doing that. If the code is indeed
> equivalent, then we can make a utility function or a common base class that
> both plugins can then reuse.
> On Thu, 21 Jun 2018 at 23:34, Greg Clayton via lldb-dev  d...@lists.llvm.org> wrote:
> >
> > We now have architecture plug-ins. Target::GetCallableLoadAddress should
> defer to the architecture plug-ins and any functionality should be moved into
> those plug-ins. There is one for ARM. We will need to make one for MIPS.
> >
> > > On Jun 21, 2018, at 1:58 PM, Jim Ingham via lldb-dev  d...@lists.llvm.org> wrote:
> > >
> > > It's actually a little lame that we have a switch over architectures in
> generic Target 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 of this code
> should be in Target.cpp...
> > >
> > > Jim
> > >
> > >
> > >> On Jun 21, 2018, at 11:52 AM, Tatyana Krasnukha via lldb-dev  d...@lists.llvm.org> wrote:
> > >>
> > >> 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
> > >> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_
> > >> cgi-2Dbin_mailman_listinfo_lldb-
> 2Ddev=DwIFaQ=DPL6_X_6JkXFx7AXWq
> > >> B0tg=yfnu24japkhNGh-
> WqJObHXmH3mINtC_2FO828lrNpM0=zeb97axU-KzSUy
> > >> ceCOnTX3EVhAWc4wKeo1VXIpAS8_A=CUWr4NMXX26fzc73yt53_-
> B6KZ6mC197fuJ
> > >> GVwx08xk=
> > >
> > > ___
> > > lldb-dev mailing list
> > > lldb-dev@lists.llvm.org
> > > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_c
> > > gi-2Dbin_mailman_listinfo_lldb-
> 2Ddev=DwIFaQ=DPL6_X_6JkXFx7AXWqB0
> > > tg=yfnu24japkhNGh-
> WqJObHXmH3mINtC_2FO828lrNpM0=zeb97axU-KzSUyceC
> > > OnTX3EVhAWc4wKeo1VXIpAS8_A=CUWr4NMXX26fzc73yt53_-
> B6KZ6mC197fuJGVwx
> > > 08xk=
> >
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi
> > -2Dbin_mailman_listinfo_lldb-
> 2Ddev=DwIFaQ=DPL6_X_6JkXFx7AXWqB0tg
> > =yfnu24japkhNGh-WqJObHXmH3mINtC_2FO828lrNpM0=zeb97axU-
> KzSUyceCOnTX3E
> > VhAWc4wKeo1VXIpAS8_A=CUWr4NMXX26fzc73yt53_-
> B6KZ6mC197fuJGVwx08xk=
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Handling callable addresses

[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/listinfo/lldb-dev

[lldb-dev] NativeThreadProtocol

[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@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Question about LLVMCDisassembler

[Tatyana Krasnukha via lldb-dev]

Want to answer my second question: in that case LLVMCDisassembler will be 
created with m_is_valid = false as it should, but what can happen in 
create{Target}MCAsmInfo is UB nevertheless. Suppose it is not good, that's why 
I created revision D41584.

From: lldb-dev [mailto: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::LLVMCDisassembler starting from line 897:

  m_reg_info_ap.reset(curr_target->createMCRegInfo(triple));

  m_subtarget_info_ap.reset(
  curr_target->createMCSubtargetInfo(triple, cpu, features_str));

  std::unique_ptr reg_info(
  curr_target->createMCRegInfo(triple));
  m_asm_info_ap.reset(curr_target->createMCAsmInfo(*reg_info, triple));


  1.  Why it cannot reuse m_reg_info_ap  for createMCAsmInfo instead of 
creation reg_info again?
  2.  It seems that createMCRegInfo can return nullptr. Is it safe to 
dereference reg_info in createMCAsmInfo (line 904)?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Question about LLVMCDisassembler

[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, features_str));

  std::unique_ptr reg_info(
  curr_target->createMCRegInfo(triple));
  m_asm_info_ap.reset(curr_target->createMCAsmInfo(*reg_info, triple));


  1.  Why it cannot reuse m_reg_info_ap  for createMCAsmInfo instead of 
creation reg_info again?
  2.  It seems that createMCRegInfo can return nullptr. Is it safe to 
dereference reg_info in createMCAsmInfo (line 904)?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Tatyana Krasnukha via lldb-dev]

Sorry, I was unclear – I mean existing recently added plugin “Architecture”. 
And “dynamic” configuration is not necessary retrieved from gdb-server.

From: Greg Clayton [mailto:clayb...@gmail.com]
Sent: Friday, 3 November, 2017 9:37 PM
To: Tatyana Krasnukha <tatyana.krasnu...@synopsys.com>
Cc: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] purpose of ProcessGDBRemote::m_flags

If this isn't used, then this should be removed. Anything dynamic settings that 
are retrieved need to be abstracted into this class. There isn't a need for an 
extra plug-in as ProcessGDBRemote handles all variants 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 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 dynamic architecture 
features (read from target’s configuration registers, for example)?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org<mailto:lldb-dev@lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_lldb-2Ddev=DwMFaQ=DPL6_X_6JkXFx7AXWqB0tg=yfnu24japkhNGh-WqJObHXmH3mINtC_2FO828lrNpM0=TPGuCrskMMaB7m6l1CDkxftg4_0EFERP7gNT0_znGHc=zE0tNmv1hqZKYmVJ27YFB_VSv_0ZDpercK61ZVsfUKc=>

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] purpose of ProcessGDBRemote::m_flags

[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 dynamic architecture 
features (read from target's configuration registers, for example)?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[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-name and platfrom-url).

As for openocd and other gdb servers, there is no way to use them for remote 
testing. I haven’t found, at least.

Thanks,
Tatyana

From: cuibixiong [mailto:cuibixi...@gmail.com]
Sent: Saturday, 28 October, 2017 12:40 PM
To: Tatyana Krasnukha 
Cc: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] did anyone konw LLDB support lldb + openocd to run 
dotest.py in bare board like ARM or other non-x86 architecture?

Hi

  You mean should use “platform select remote-linux” ? I use it but 
also report error: unable to launch a GDB server on 'debian-armhf.""'

  in-addition, you said gdb-server is “GNU GDB server” or just 
lldb-server services ?

Best Regards
—cuibixiong

发件人: Tatyana Krasnukha 
>
日期: 2017年10月27日 星期五 21:53
至: cuibixiong >
抄送: "lldb-dev@lists.llvm.org" 
>
主题: RE: [lldb-dev] did anyone konw LLDB support lldb + openocd to run dotest.py 
in bare board like ARM or other non-x86 architecture?

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=connect://hostname:port --arch=architecture ...

From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of cui 
bixiong via lldb-dev
Sent: Friday, 27 October, 2017 9:41 AM
To: Greg Clayton >
Cc: lldb-dev >
Subject: Re: [lldb-dev] did anyone konw LLDB support lldb + openocd to run 
dotest.py in bare board like ARM or other non-x86 architecture?

Hi :

I build a armhf qemu enviroment to test ARM lldb + lldb-server testsuite.  
source code base on LLVM + LLDB + LLD + CLANG formal release 5.0.0.

Target: lldb-server platform --listen *： --server

Host :

(lldb) platform select remote-linux
Platform: remote-linux
Connected: no
(lldb) platform connect 
connect://0.0.0.0:
Platform: remote-linux
Triple: arm-*-linux-gnueabihf
OS Version: 3.2.0 (3.2.0-4-vexpress)
Kernel: #1 SMP Debian 3.2.51-1
Hostname: debian-armhf.""
Connected: yes
WorkingDir: /root
(lldb) file ./hello.exe
Current executable set to './hello.exe' (arm).
(lldb) log enable gdb-remote packets
(lldb) process launch
history[1] tid=0x6192 <   1> send packet: +
history[2] tid=0x6192 <  19> send packet: $QStartNoAckMode#b0
history[3] tid=0x6192 <   1> read packet: +
history[4] tid=0x6192 <   6> read packet: $OK#9a
history[5] tid=0x6192 <   1> send packet: +
history[6] tid=0x6192 <  13> send packet: $qHostInfo#9b
history[7] tid=0x6192 < 297> read packet:  
$triple:61726d2d2d6c696e75782d676e75656162696866;ptrsize:4;distribution_id:64656269616e;watchpoint_exceptions_received:before;endian:little;os_version:3.2.0;os_build:332e322e302d342d7665787072657373;os_kernel:233120534d502044656269616e20332e322e35312d31;hostname:64656269616e2d61726d68662e;#1a
history[8] tid=0x6192 <  18> send packet: $qGetWorkingDir#91
history[9] tid=0x6192 <  14> read packet: $2f726f6f74#a4
history[10] tid=0x6192 <  19> send packet: $qQueryGDBServer#cb
history[11] tid=0x6192 <   7> read packet: $E04#a9
history[12] tid=0x6192 <  73> send packet: 
$qModuleInfo:2e2f68656c6c6f2e657865;61726d2d2d6c696e75782d656162696866#b7
history[13] tid=0x6192 <   7> read packet: $E03#a8
history[14] tid=0x6192 <  69> send packet: 
$qModuleInfo:6c6962632e736f2e36;61726d2d2d6c696e75782d656162696866#7b
history[15] tid=0x6192 <   7> read packet: $E03#a8
<  36> send packet: $qLaunchGDBServer;host:mtkslt202;#b1
error: unable to launch a GDB server on 'debian-armhf.""'

 i show host and port is uncorrect, is it a bug?


Best Regards
--cuibixiong

On Tue, Oct 24, 2017 at 11:04 PM, Greg Clayton 
> wrote:

On Oct 24, 2017, at 12:02 AM, cui bixiong 
> wrote:

Hi

sorry， i'm confuse, in my mind, lldb-server maybe like gdb-server, running 
on Linux-like platform  listening 

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

[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 dynamic loader. There is a
> DynamicLoaderStatic which will load files at the address that they are
> specified in the object files. When you load your ELF file using:
> 
> (lldb) file /path/to/foo.elf
> 
> What does:
> 
> (lldb) target list
> 
> show as the output? You might want to specify "none" for both the vendor
> and OS in your target triple when creating your target:
> 

It shows just what expected: * target #0: xxx.elf ( arch=arc-*-*, platform=host 
)

> (lldb) file --arch armv7-none-none /path/to/foo.elf
> 
> This specifies there is no vendor (first "none" in the triple) and no 
> operating
> system  (second "none" in the triple). The target's triple helps it select the
> right plug-ins to use like the dynamic load plug-in (which tells LLDB where
> sections from binaries got loaded), runtime plug-ins and much more.
> 
> 
> So you might try:
> 
> (lldb) target modules load --load --set-pc-to-entry --slide 0 --file
> /path/to/foo.elf

set-pc-to-entry, not --set-pc-to-entry. May by typo in sources.

‘target modules load --load set-pc-to-entry --slide 0’ is enough, but just 
compare this text with ‘load’ in gdb… Looks like someone hates bare-metal 
developers))

> 
> Or, you can specify the addresses of all the sections using:
> 
> (lldb) target modules load --load --set-pc-to-entry --file /path/to/foo.elf 
> .text
> 0x1000 .data 0x2000 

This is a good feature, but again, how often is it needed comparing with simple 
load…

> 
> This allows you to completely control where each section goes and possibly
> skip other sections. It also informs LLDB that sections have been loaded at
> specific addresses.
> 
> FYI: We will have to tweak LLDB for baseboard support as it has been used bit
> by a few folks (check the "svn blame" for who added the "--load" option and
> possibly contact them) but I am sure it needs to be improved.
> 
> So try specifying "--arch -none-none" and see where that gets you. It
> should select the right dynamic loader plug-in for you.
> 
> A bit more explanation about loading. LLDB has the notion of "file addresses"
> and "load addresses". A file address is valid for one file only, and it is the
> same as the addresses that are contained within the object file (ELF, Mach-O,
> COFF). When breakpoints are set by file + line or by name, we resolve these
> to "section .text + 100 in file foo.elf". Breakpoints can't be set until a 
> section
> has a "load address" which will tell us where each section actually is mapped
> inside the process being debugged. For bare boards there is no dynamic
> linker that tell us '".text" was loaded at address 0x123'. If the
> DynamicLoaderStatic is selected for a target, which is done by having no OS in
> the target triple for the target, it will set the load address for the 
> sections to
> match the "file addresses" and breakpoints will then be set. When a section
> is "loaded", a message is sent around LLDB to indicate a section was loaded,
> and all breakpoints will now be able to resolve themselves (get the "load
> address" for each "file address" for each breakpoint) and they will be set in
> the debugged process. Your extra step where you need LLDB to load your
> ELF file is now in the mix as well.
> 
> So I would recommend:
> 1 - create your target first:
> (lldb) file --arch armv7-none-none /path/to/foo.elf
> 2 - attach to the baseboard
> (lldb) gdb-remote 
> 3 - load the file in memory
> (lldb) target modules load --load --set-pc-to-entry --slide 0 --file
> /path/to/foo.elf
> 4 - set breakpoints now
> (lldb) breakpoint set ...
> 

Of course I used incorrect order of commands, I just wanted to note that 
ObjectFile::LoadInMemory should set error status when it cannot write memory.

> 
> Usually you can set the breakpoints before your attach, but in your case you
> probably want to load the ELF file before you set breakpoints, otherwise you
> might end up setting breakpoints as soon as the "gdb-remote ..." attach
> happens since the DynamicLoaderStatic will correctly set the load addresses
> of all your sections after attaching which will cause breakpoint to resolve 
> and
> attempt write traps to memory. Then if we load the ELF file in step #3 and
> when it writes all of the ELF sections to memory it will overwrite the
> breakpoint traps we set. So try the above flow and let us know how things
> go.
> 
> Greg Clayton
> 
> 
> 
> 
>   On Sep 19, 2017, at 11:21 AM, Tatyana Krasnukha
>   > wrote:
> 
>   Hello,
> 
>   ‘target modules load -lp’  fails with error “one or more section name
> + load address pair 

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

[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 setting 
appropriate status. Thus, user sees nothing in output as if command succeeds.

Thanks,
Tatyana

From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Greg 
Clayton via lldb-dev
Sent: Tuesday, 19 September, 2017 6:06 PM
To: cui bixiong 
Cc: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] How can lldb debug a remote bare-metal platform?

Load like "target modules load" has a --load option that will load the ELF into 
memory. I think it should do what you want. Let me know how it goes.

Greg Clayton

On Sep 18, 2017, at 9:58 PM, cui bixiong 
> wrote:

Hi Greg:

It's worked, thank you!, but I still have a question, in GNU-GDB which 
provide `load` command to download a ELF file into bare-board, in LLDB support 
those features? should I dump a binary file and use lldb "target module load" 
to replace 'load' command?

​Best Regards
--cuibixiong​


2017-09-18 23:53 GMT+08:00 Greg Clayton 
>:
So when launching a GDB server there are two flows:

1 - When you connect you already have a process
2 - You will connect, then launch or attach to a process

LLDB tries to see if there is a process by sending the "qfThreadInfo" packet. 
As you see below, it responds with on character "l" which means  "end of the 
thread list". Since no thread IDs were returned, this makes LLDB believe that 
there is no process on the other end. So later when you try to say "process 
launch", it tries to send the "A" packet which tries to launch your program by 
sending the name of the process file to launch.

There was recently an OpenOCD patch to work around this with:

https://reviews.llvm.org/D37934

This fixed this issue and also made it read both sets of registers via the XML 
target packets.

That should make things work, but it would be better if we modified the OpenOCD 
GDB server to respond with a thread ID when asked about its thread with the 
"qfThreadInfo" packet. Since it is a bare board connection, it should respond 
with "1" (one) to the "qfThreadInfo" packet followed by "l" to the next 
ThreadInfo packet (read GDB protocol docs on this.

Let me know if the patch mentioned above (which is already checked in) fixed 
your issues.



On Sep 17, 2017, at 3:50 AM, cui bixiong via lldb-dev 
> wrote:

Hi：

Currently I porting lldb for Hifive1 (riscv bare board) w/ openocd 0.10.0, 
but it always show "error: Process must be launched."

I use GNU gdb to remote connect and debugging w/ the same openocd + elf, it 
work OK.

I want to know how to launch Process in bare board?

thanks a lot!

$ lldb
(lldb) log enable gdb-remote packets
(lldb) target create Build3/riscv-hello.elf
Current executable set to 'Build3/riscv-hello.elf' (riscv).
(lldb) gdb-remote 
172.27.113.29:
<   1> send ack packet: +
history[1] tid=0x44c8 <   1> send packet: +
<   1> read packet: +
<  19> send SendPacketNoLock 2 packet: $QStartNoAckMode#b0
<   1> read packet: +
<   6> read packet: $OK#9a
<   1> send ack packet: +
<  41> send SendPacketNoLock 2 packet: $qSupported:xmlRegisters=i386,arm,mips#12
<  80> read packet: 
$PacketSize=3fff;qXfer:memory-map:read+;qXfer:features:read-;QStartNoAckMode+#08
<  26> send SendPacketNoLock 2 packet: $QThreadSuffixSupported#e4
<   4> read packet: $#00
<  27> send SendPacketNoLock 2 packet: $QListThreadsInStopReply#21
<   4> read packet: $#00
<  13> send SendPacketNoLock 2 packet: $qHostInfo#9b
<   4> read packet: $#00
<  10> send SendPacketNoLock 2 packet: $vCont?#49
<   4> read packet: $#00
<  27> send SendPacketNoLock 2 packet: $qVAttachOrWaitSupported#38
<   4> read packet: $#00
<  16> send SendPacketNoLock 2 packet: $qProcessInfo#dc
<   4> read packet: $#00
<   6> send SendPacketNoLock 2 packet: $qC#b4
<   7> read packet: $QC0#c4
<  16> send SendPacketNoLock 2 packet: $qfThreadInfo#bb
<   5> read packet: $l#6c
(lldb) thread list
error: Process must be launched.
(lldb) b main
Breakpoint 1: where = riscv-hello.elf`main at hello.c:3, address = 0x20400230
(lldb) thread continue
error: invalid thread
(lldb) process launch
<  38> send SendPacketNoLock 2 

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

[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, and 
implements process-specific functions, for example restoring registers state 
after expression evaluation.

Please, correct me anyone, if I'm wrong.

Tatyana

-Original Message-
From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Ramana via 
lldb-dev
Sent: Wednesday, 13 September, 2017 9:00 AM
To: lldb-dev@lists.llvm.org
Subject: [lldb-dev] lldb_private::RegisterContext vs 
lldb_private::RegisterInfoInterface

Hi,

When deriving RegisterContext_, why some platforms (Arch+OS) are 
deriving it from lldb_private::RegisterContext while others are deriving from 
lldb_private::RegisterInfoInterface or in other words how to decide on the base 
class to derive from between those two and what are the implications?

Thanks,
Ramana
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_lldb-2Ddev=DwIGaQ=DPL6_X_6JkXFx7AXWqB0tg=8NZfjV_ZLY_S7gZyQMq8mj7tiN4vlymPiSt0Wl0jegw=YZ3Zmbvj4mvkuTSfZ9-gC0Gi1rMMrrPaSTL8YBCytAM=55CKoDxnRsC-dUPbL7T3sQ2HL74C2foFRhvssSATbbw=
 
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Tatyana Krasnukha via lldb-dev]

I got it. I hoped that this work was just removed in other library, despite I 
didn't find something like that anywhere in lldb. Also I supposed there were 
some certain reason to remove it. But since it is just not implemented yet, I 
have no questions more) Thank you all for explanation!

Due to complicated instruction formats it is very undesired for me to implement 
instruction tables again. DoGuessValueAt in StackFrame looks like what I need, 
thanks for this hint!

From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Sean 
Callanan via lldb-dev
Sent: Thursday, 31 August, 2017 9:35 PM
To: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] Symbolic information in disassembler output

Greg is right that this was a libedis feature and has no equivalent in LLDB 
today.

MCInst, however, doesn't have enough information by itself to do this.  The 
reason is that for many things that are considered "operands," the MCInst has 
several underlying operands.  For example, an operand that was expressed as a 
register + an offset would be represented in MCInst as a register operand and 
in immediate operand, and only correlating the opcode with the LLVM instruction 
tables (and possibly some special knowledge) would tell you that the two belong 
together.

Additionally, libedis could express the semantics of the instruction operands 
(e.g., "this is a source operand and represents the result of dereferncing rbp 
- 4") , and inform the client what ranges of characters in the generated string 
represented each high level operand.  Both of these features are not exposed 
anywhere at the moment, and in fact the underlying knowledge was lost when the 
edis TableGen backend was deprecated.

There are a few LLDB features that reads instructions and attempt to interpret 
them:

  *   The fast unwinder looks for specific bit patterns (see 
UnwindAssembly_x86::GetFastUnwindPlan in UnwindAssembly-x86.cpp);
  *   The ARM instruction emulator has its own home-grown instruction table 
(see EmulateInstructionARM64.cpp); and
  *   The crash diagnose functionality actually parses the output strings from 
the disassembler (see DoGuessValueAt in StackFrame.cpp).
Sean
On 8/31/17 11:09 AM, Greg Clayton via lldb-dev wrote:
I believe libedis was deprecated many years ago and hasn't returned. We use the 
standard LLVM disassembler, so any features need to 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 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 as useless and was 
removed at all?

Thanks,
Tatyana
___
lldb-dev mailing list
lldb-dev@lists.llvm.org<mailto:lldb-dev@lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_lldb-2Ddev=DwMD-g=DPL6_X_6JkXFx7AXWqB0tg=yfnu24japkhNGh-WqJObHXmH3mINtC_2FO828lrNpM0=7vyzoeGsRVHSuFRMjc2lR2qriX_mHH__tvmVgk8GZ2k=Vg84RxY-kTR1thZ-fnYnj9AKqhzYs2FclhOLFvamrNg=>





___

lldb-dev mailing list

lldb-dev@lists.llvm.org<mailto:lldb-dev@lists.llvm.org>

http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_lldb-2Ddev=DwMD-g=DPL6_X_6JkXFx7AXWqB0tg=yfnu24japkhNGh-WqJObHXmH3mINtC_2FO828lrNpM0=7vyzoeGsRVHSuFRMjc2lR2qriX_mHH__tvmVgk8GZ2k=Vg84RxY-kTR1thZ-fnYnj9AKqhzYs2FclhOLFvamrNg=>

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Symbolic information in disassembler output

[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 as useless and was 
removed at all?

Thanks,
Tatyana
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Tatyana Krasnukha via lldb-dev]

Trying to add new field to RegisterInfo I ran into the problem that it requires 
modifying all hardcoded register infos (for each target's ABI and 
RegisterContext), despite almost all targets never need this field. Another 
decision is to add a set with such register names into DynamicRegisterInfo and 
skip restoring of a register if it exists in this set. This solution works for 
me as needed and it seems less invasive in terms of other targets. I can 
prepare a patch if you'll consider it useful.

Thanks,
Tatyana

-Original Message-
From: Tatyana Krasnukha 
Sent: Thursday, 13 July, 2017 3:01 PM
To: 'Pavel Labath' <lab...@google.com>
Cc: lldb-dev@lists.llvm.org
Subject: RE: [lldb-dev] Skipping registers when restore register state after a 
function call

Yes, you are right about bug in the stub, and that returning of an error will 
not solve the problem. I like the idea to add a field to register info. But I 
doubt that "read-only" may confuse someone, because such registers are not 
really read-only - just its modifying leads to undesirable behavior.

Thanks,
Tatyana

-Original Message-
From: Pavel Labath [mailto:lab...@google.com]
Sent: Thursday, 13 July, 2017 2:37 PM
To: Tatyana Krasnukha <tatyana.krasnu...@synopsys.com>
Cc: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] Skipping registers when restore register state after a 
function call

Aha, I see. I take it these are some registers which provide the state of the 
cpu, but are not modifiable by user code. Presumably the same crash would 
happen if the user manually issued a "register write"
command (?)

The fact that the stub crashes after this command sounds like a bug in the stub 
for me. However, even if it is fixed to return error, the register save-restore 
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.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 
> register state. In that moment my gdb-server crashes because of attempt to 
> write some registers that shouldn't be written.
>
> Thanks,
> Tatyana
>
> -Original Message-
> From: Pavel Labath [mailto:lab...@google.com]
> Sent: Thursday, 13 July, 2017 2:16 PM
> To: Tatyana Krasnukha <tatyana.krasnu...@synopsys.com>
> Cc: lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] Skipping registers when restore register state 
> after a function call
>
> I'm not sure there is a good way to do that currently.
>
> However, if you tell us what is the higher level problem you are 
> trying to solve, we may be able to provide an alternative (right now, 
> the only reason I can think of why you would *not* want to 
> save/restore all registers is the orig_rax pseudo-register, 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 “save-restore”
>> register property. Is there any way to avoid restoring of some 
>> registers beside hardcoding its names in 
>> GDBRemoteRegisterContext::WriteAllRegisterValues like it is done for 
>> arm debugserver?
>>
>>
>>
>> Thanks for any suggestions,
>>
>> Tatyana
>>
>>
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cg
>> i
>> -2Dbin_mailman_listinfo_lldb-2Ddev=DwIFaQ=DPL6_X_6JkXFx7AXWqB0tg&
>> r
>> =yfnu24japkhNGh-WqJObHXmH3mINtC_2FO828lrNpM0=xQwSXvPwlPz8CJ0HNdZzGQ
>> K
>> bqJgS9_gurfUe7UBAJc4=wHAU8LK6EtYfrxcSHTTJDCUlZ9yxQW72oPMlQK9KJSU=
>>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi
> -2Dbin_mailman_listinfo_lldb-2Ddev=DwIFaQ=DPL6_X_6JkXFx7AXWqB0tg
> =yfnu24japkhNGh-WqJObHXmH3mINtC_2FO828lrNpM0=X2B3EThXxPLbgM5Du4XBwo2
> Oby1TAS_qzsSn19dGNU8=bg2WaOthZ_IMN1zNqRVjDVoz3hbHOrfKkc5oVe_SFI4=
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Tatyana Krasnukha via lldb-dev]

Yes, you are right about bug in the stub, and that returning of an error will 
not solve the problem. I like the idea to add a field to register info. But I 
doubt that "read-only" may confuse someone, because such registers are not 
really read-only - just its modifying leads to undesirable behavior.

Thanks,
Tatyana

-Original Message-
From: Pavel Labath [mailto:lab...@google.com] 
Sent: Thursday, 13 July, 2017 2:37 PM
To: Tatyana Krasnukha <tatyana.krasnu...@synopsys.com>
Cc: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] Skipping registers when restore register state after a 
function call

Aha, I see. I take it these are some registers which provide the state of the 
cpu, but are not modifiable by user code. Presumably the same crash would 
happen if the user manually issued a "register write"
command (?)

The fact that the stub crashes after this command sounds like a bug in the stub 
for me. However, even if it is fixed to return error, the register save-restore 
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.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 
> register state. In that moment my gdb-server crashes because of attempt to 
> write some registers that shouldn't be written.
>
> Thanks,
> Tatyana
>
> -Original Message-
> From: Pavel Labath [mailto:lab...@google.com]
> Sent: Thursday, 13 July, 2017 2:16 PM
> To: Tatyana Krasnukha <tatyana.krasnu...@synopsys.com>
> Cc: lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] Skipping registers when restore register state 
> after a function call
>
> I'm not sure there is a good way to do that currently.
>
> However, if you tell us what is the higher level problem you are 
> trying to solve, we may be able to provide an alternative (right now, 
> the only reason I can think of why you would *not* want to 
> save/restore all registers is the orig_rax pseudo-register, 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 “save-restore”
>> register property. Is there any way to avoid restoring of some 
>> registers beside hardcoding its names in 
>> GDBRemoteRegisterContext::WriteAllRegisterValues like it is done for 
>> arm debugserver?
>>
>>
>>
>> Thanks for any suggestions,
>>
>> Tatyana
>>
>>
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cg
>> i 
>> -2Dbin_mailman_listinfo_lldb-2Ddev=DwIFaQ=DPL6_X_6JkXFx7AXWqB0tg&
>> r 
>> =yfnu24japkhNGh-WqJObHXmH3mINtC_2FO828lrNpM0=xQwSXvPwlPz8CJ0HNdZzGQ
>> K 
>> bqJgS9_gurfUe7UBAJc4=wHAU8LK6EtYfrxcSHTTJDCUlZ9yxQW72oPMlQK9KJSU=
>>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi
> -2Dbin_mailman_listinfo_lldb-2Ddev=DwIFaQ=DPL6_X_6JkXFx7AXWqB0tg
> =yfnu24japkhNGh-WqJObHXmH3mINtC_2FO828lrNpM0=X2B3EThXxPLbgM5Du4XBwo2
> Oby1TAS_qzsSn19dGNU8=bg2WaOthZ_IMN1zNqRVjDVoz3hbHOrfKkc5oVe_SFI4=
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Tatyana Krasnukha via lldb-dev]

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 attempt to 
write some registers that shouldn't be written.

Thanks,
Tatyana

-Original Message-
From: Pavel Labath [mailto:lab...@google.com] 
Sent: Thursday, 13 July, 2017 2:16 PM
To: Tatyana Krasnukha <tatyana.krasnu...@synopsys.com>
Cc: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] Skipping registers when restore register state after a 
function call

I'm not sure there is a good way to do that currently.

However, if you tell us what is the higher level problem you are trying to 
solve, we may be able to provide an alternative (right now, the only reason I 
can think of why you would *not* want to save/restore all registers is the 
orig_rax pseudo-register, 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 “save-restore”
> register property. Is there any way to avoid restoring of some 
> registers beside hardcoding its names in 
> GDBRemoteRegisterContext::WriteAllRegisterValues like it is done for 
> arm debugserver?
>
>
>
> Thanks for any suggestions,
>
> Tatyana
>
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi
> -2Dbin_mailman_listinfo_lldb-2Ddev=DwIFaQ=DPL6_X_6JkXFx7AXWqB0tg
> =yfnu24japkhNGh-WqJObHXmH3mINtC_2FO828lrNpM0=xQwSXvPwlPz8CJ0HNdZzGQK
> bqJgS9_gurfUe7UBAJc4=wHAU8LK6EtYfrxcSHTTJDCUlZ9yxQW72oPMlQK9KJSU=
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[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::WriteAllRegisterValues like 
it is done for arm debugserver?

Thanks for any suggestions,
Tatyana
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev