Re: [lldb-dev] Disassembling issue

[Ted Woodward via lldb-dev]

Hi Romaric,

The call to Disassembler::FindPlugin should have arch set to your triple. If 
m_options.arch is not set on the disassembly command line, it will get it from 
the target:

  if (!m_options.arch.IsValid())
m_options.arch = target->GetArchitecture();


That leads me to wonder if your triple is set correctly after you do the run. 
What is the output from these commands, when you’re stopped?:

target list
platform status

My guess is you’re connected to a remote gdb-server on a simulator for dpu, and 
it’s telling lldb that the triple is x86_64.x.x.

If target list says the arch is dpu before the run, and x86_64 after the run, 
we should look at the RSP log. Before the run, type
log enable -f  gdb-remote packets

Attach the file to your next message.

Ted

From: Romaric Jodin 
Sent: Thursday, June 13, 2019 1:16 AM
To: Ted Woodward 
Cc: LLDB 
Subject: [EXT] Re: [lldb-dev] Disassembling issue

Hi Ted,

Thank you for the answer.
I'm not sure I understand you well. It seems to me that my program call 
"Disassembler::FindPlugin" with the "m_options.arch" set to "x86_64". But my 
toolchain does not contain a LLVM supporting x86_64, so it feels normal to me 
that it is not able to create this disassembler. What is weird is that the 
first time I'm executing it, it managed to do so.

I also have kind of the same issue with breakpoint. It's like if I'm missing 
the debug information after I do the "run" command:

(lldb) file test
Current executable set to 'test' (dpu).
(lldb) b main
Breakpoint 1: where = test`main + 24 at test.c:8, address = 0x8078
(lldb) r
Process 21312 launched: '/home/rjodin/work/dpu_tools/llvm/lldb/test/test' (dpu)
Process 21312 stopped
* thread #1, name = 'DPUthread0', stop reason = Thread finished
frame #0: 0x80c0
(lldb) b main
Breakpoint 2: no locations (pending).
WARNING:  Unable to resolve breakpoint to any actual locations.

When I'm doing the disassembly, I can manage to disassemble if I add the option 
with my architecture to the command line, but as you can see below, I also do 
not have the debug information that I had at the first disassembly:

(lldb) file test
Current executable set to 'test' (dpu).
(lldb) dis -s 0x8000
test`__bootstrap:
test[0x8000] <+0>:  jnzid, 0x8020
test[0x8008] <+8>:  move   r0, 0xff
test[0x8010] <+16>: release r0, 0x0, nz, 0x8018
test[0x8018] <+24>: subr0, r0, 0x1, pl, 0x8010
(lldb) r
Process 21312 launched: '/home/rjodin/work/dpu_tools/llvm/lldb/test/test' (dpu)
Process 21312 stopped
* thread #1, name = 'DPUthread0', stop reason = Thread finished
frame #0: 0x80a0
(lldb) dis -s 0x8000
error: Unable to find Disassembler plug-in for the 'x86_64' architecture.
(lldb) dis -s 0x8000 -A dpu
0x8000: jnzid, 0x8020
0x8008: move   r0, 0xff
0x8010: release r0, 0x0, nz, 0x8018
0x8018: subr0, r0, 0x1, pl, 0x8010

Any ideas about it?
Thanks,
Romaric

On Wed, Jun 12, 2019 at 6:55 PM Ted Woodward 
mailto:tedw...@quicinc.com>> wrote:
The error is coming from source/Commands/CommandObjectDisassemble.cpp . It’s 
not able to create the disassembler for your architecture. The call to 
Disassembler::FindPlugin fails.
My guess is something in the call to MCDisasmInstance::Create in 
source/Plugins/Disassembler/llvm/DisassemblerLLVMC.cpp is failing. Step through 
that and make sure everything there is working.

Ted

From: lldb-dev 
mailto:lldb-dev-boun...@lists.llvm.org>> On 
Behalf Of Romaric Jodin via lldb-dev
Sent: Wednesday, June 12, 2019 8:23 AM
To: lldb-dev@lists.llvm.org
Subject: [EXT] [lldb-dev] Disassembling issue

Hi everyone,

I'm trying to have lldb being able to debug my architecture. It does it well 
after loading my elf. But then I run it, stop it in middle, try to disassemble 
and at that point it seems that I lost some information about my architecture. 
lldb tries to disassemble it for x86, which in not possible with my toolchain.

Here is a log of what I am doing:

(lldb) file test
Current executable set to 'test' (dpu).
(lldb) dis -s 0x8000
test`__bootstrap:
test[0x8000] <+0>:  jnzid, 0x8020
test[0x8008] <+8>:  move   r0, 0xff
test[0x8010] <+16>: release r0, 0x0, nz, 0x8018
test[0x8018] <+24>: subr0, r0, 0x1, pl, 0x8010
(lldb) r
Process 21312 launched: '/home/rjodin/work/dpu_tools/llvm/lldb/test/test' (dpu)
Process 21312 stopped
* thread #1, name = 'DPUthread0', stop reason = Thread stopped
frame #0: 0x8090
(lldb) dis -s 0x8000
error: Unable to find Disassembler plug-in for the 'x86_64' architecture.
(lldb)

Any ideas of what I am missing in my implementation?
Thanks,
--
Romaric JODIN
UPMEM
Software Engineer

[cid:image001.png@01D521DB.DDFD0A00]


--
Romaric JODIN
UPMEM
Software Engineer

[cid:image001.png@01D521DB.DDFD0A00]
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://li

[lldb-dev] [Bug 42271] New: Hanging lldb-vscode test: TestVSCode_setBreakpoints

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=42271

Bug ID: 42271
   Summary: Hanging lldb-vscode test: TestVSCode_setBreakpoints
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Keywords: code-quality
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: kkle...@redhat.com
CC: clayb...@gmail.com, jan.kratoch...@redhat.com,
jdevliegh...@apple.com, llvm-b...@lists.llvm.org

Created attachment 22096
  --> https://bugs.llvm.org/attachment.cgi?id=22096&action=edit
Patch to have test timeout after 1 second instead of hanging forever.

Summary
===

On one of our build bots and with local builds a test related to the
lldb-vscode binary is sporadically hanging: TestVSCode_setBreakpoints.py. When
I run it 100 times it eventually hangs after an arbitrary number of times.

How to reproduce


In order to produce some load on my developer machine it is enough to run
"ninja check-lldb" in a separate terminal. Then in another terminal you can run
the hanging test manually in a loop:

cd ~/llvm/lldb/test/
for i in {1..100}; do
  echo "=== TEST $i "; 
  
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:~/llvm-builds/relwithdebinfo-ninja-clang-gold-ccache-distcc/lib
python dotest.py \
-v \
--executable
~/llvm-builds/relwithdebinfo-ninja-clang-gold-ccache-distcc/bin/lldb \
-p TestVSCode_setBreakpoints.py \
../../lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/breakpoint; 
  if [ $? -ne 0 ]; then
echo "ERROR IN TEST $i";
break;
  fi
done

Locally I have my LLVM monorepo checked out in ~/llvm and my build directory is
~/llvm-builds/relwithdebinfo-ninja-clang-gold-ccache-distcc . It doesn't matter
how you've compiled lldb.

Once you've reproduced that you sometimes (with a pretty high chance though)
get a hanging test, you might want to apply the attached patch and retry to
reproduce problem. You'll notice that it is gone. I'm not sure this really is
the proper patch to address the problem which is why I haven't created a
revision phabricator yet.


First analysis
==

I've augmented the Python test scripts with print()'s to show what's going on.
That's when I found out that there's this a simplified call graph (at the
bottom is the hanging part): 


class VSCodeTestCaseBase: def verify_breakpoint_hit(self, breakpoint_ids):

  stopped_events = self.vscode.wait_for_stopped()

class DebugCommunication: def wait_for_stopped(self, timeout=None):

  stopped_event = self.wait_for_event(filter=['stopped', 'exited'],
timeout=timeout)

  def wait_for_event(self, filter=None, timeout=None):

self.recv_packet(filter_type='event', filter_event=filter, timeout=timeout)

  def recv_packet(self, filter_type=None, filter_event=None, timeout=None):

self.recv_condition.wait(timeout)

  threading.Condition.wait(timeout=None)


This is where our test hangs. One thing to note here is that from the call
side, there's no timeout passed along, so it evaluates to None in
threading.Condition.wait(timeout). The documentation for this function
(https://docs.python.org/3/library/threading.html#threading.Condition.wait)
says "Wait until notified or until a timeout occurs." Somehow it waits forever
because it is not notified?

My question is why there's no timeout passed along to avoid those hanging
problems altogether? Just do a simple grep for "wait_for_stopped",
"wait_for_event", or "recv_packet" to find out how many times those functions
are called without a proper timeout.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev