[lldb-dev] lldb10 can not hit break point on windows platform

2020-10-17 Thread le wang via lldb-dev
Hello,everyone:
  I have a problem when download llvm10.0.1 and use lldb to debug my
process on windows10 x64 platform. but with no debug point hit.
the command is
(lldb)target create "D:/code/MLExecuteTest.exe"
Current executable set to 'D:/code/MLExecuteTest.exe'  (x86_64)
(lldb)br s -fE:/test/TestFunction.cpp -l1
Breakpoint 1: no locations(pending).
WARNING :  Unable to resolve breakpoint to any actual locations.
(lldb)r
Process 16228 launched 'D:/code/MLExecuteTest.exe'
Process 16228 exited with status = 1(0x0001)
my using detail is  this below:
MLExecuteTest.exe is my process which will first compile the script
 TestFunction.cpp on debug mode  and generate binary code in its memory, of
course binary code has debug information, and then  it use JIT
ExecuteEngine to execute the binary code. I want to know, is llvm 10.0.1
support this using on windows platform. since before we use llvm5.0 on
windows platform is OK, breakpoints can be hit. but while update version to
10.0.1, with same operation ,breakpoints can not be hit. so is llvm10.0.1
support or has any changes on this using on windows platform?

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


[lldb-dev] [Bug 47888] New: feature request: builtin support for indirect breakpoints

2020-10-17 Thread via lldb-dev
https://bugs.llvm.org/show_bug.cgi?id=47888

Bug ID: 47888
   Summary: feature request: builtin support for indirect
breakpoints
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: james.wid...@gmail.com
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org

Hi all, 

Suppose you have two breakpoints, X and Y, and you want Y to be enabled only
after X is hit, and at-most only once for each time X is hit. So you:

- disable Y
- enable X
- add a command to X: 'breakpoint enable Y'
- configure X to auto-continue after running its commands ('-G true')
- add a command to Y: 'breakpoint disable Y'

This works nicely, and you can chain it further so that when you hit breakpoint
b_1, it enables b_2, which enables b_3, ... which enables b_N, and each b_i in
b_2...b_N will disable itself when hit.

But it can get a little unwieldy, especially since there are several steps to
setting up each link in the chain.

So I'm wondering if it would make sense to have a built-in command for this;
maybe like:

breakpoint sequence create b_1 b_2 [... b_N]

... which would arrange for each breakpoint in the sequence, except the last,
to one-shot-enable the next breakpoint in the sequence. It would also have
these effects by default:

1. disable every breakpoint in the sequence except b_1, and

2. set every breakpoint in the sequence, except the last, to auto-continue

... but this could possibly be controlled with options.

I'm not sure whether this is the best way to design the feature; e.g. you might
alternatively want to declare the sequence first and then add new breakpoints
to that sequence (i.e., breakpoints that didn't exist previously).

On the other hand, when I create a bp sequence, here's how that tends to
happen:

0. Initially, I don't know that I want a bp sequence.

1. I create b_N first.

3. Then then I find out that b_N is being hit in contexts that I _don't_
want, and then...

4. I create b_(N-1) and chain it to b_N.

...which seems like an argument in favor of
create-breakpoints-first-and-then-construct-a-sequence-from-existing-breakpoints.

Here are a couple of features I looked for before submitting this request:

- a "one-shot" option to 'breakpoint enable' (so that, if the breakpoint
was disabled before this 'break enable' command, it will go back to being
disabled after it's hit)

- an '--until-breakpoint ' option to 'process continue', which
would one-shot-enable the breakpoint before continuing


Looking forward to feedback!

--James

-- 
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