[lldb-dev] [Bug 45902] New: Wrong Debug Information at O3

[via lldb-dev]

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

Bug ID: 45902
   Summary: Wrong Debug Information at O3
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: massare...@diag.uniroma1.it
CC: ditali...@apple.com, jdevliegh...@apple.com,
llvm-b...@lists.llvm.org

Debug information seems wrong at O3.
At line 7 variable j and k should not be visible. 

$ cat a.c
int a[56];
int b ;
int c[1] ;
int d[1][9][8] ;
void
e (f) {
 b = 
 b  & 5 ^ 
 a[b ^ f ];
}

void h (f) {
 long g = f;
 {
b = b  & 5 ^ a[b ];
b = b  & 5 ^ a[b ^ 8 ];
b = b  & 5 ^ a[b ^ g ];
b = b  & 5 ^ a[b ^ g ];
  }
  e (g & 5);
  e (g>>48 & 5);
  e (g>>56 & 5);
 }

int main ()
{
int i, j, k,  dm ;
{
d[0][1][0] = 0;
}
printf("ciao");
h(0);
j = 0;
for (; j < 9; j++)
{
k = 0;
for (; k < 8; k++)
h(d[0][j][k]);
}
}

$ clang -v
clang version 11.0.0 (https://github.com/llvm/llvm-project.git
c25b20c0f6c13d68dbc2e185764082d61ae4a132)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Found candidate GCC installation:
/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/11.0.0
Selected GCC installation: /usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/11.0.0
Candidate multilib: .;@m64
Selected multilib: .;@m64

$ lldb -v
lldb version 11.0.0
  clang revision c25b20c0f6c13d68dbc2e185764082d61ae4a132
  llvm revision c25b20c0f6c13d68dbc2e185764082d61ae4a132

$ clang -O3 -g -o opt a.c

$ lldb opt 
(lldb) target create "opt"
Current executable set to 'opt' (x86_64).
(lldb) b -l 7
Breakpoint 1: 3 locations.
(lldb) r
Process 60 launched: 'opt' (x86_64)
Process 60 stopped
* thread #1, name = 'opt', stop reason = breakpoint 1.3
frame #0: 0x00400618 opt`main [inlined] e(f=0) at a.c:7:4
   4int d[1][9][8] ;
   5void
   6e (f) {
-> 7 b = 
   8 b  & 5 ^ 
   9 a[b ^ f ];
   10   }
(lldb) frame var
(int) f = 0
(lldb) s
Process 60 stopped
* thread #1, name = 'opt', stop reason = step in
frame #0: 0x0040061e opt`main at a.c:7:4
   4int d[1][9][8] ;
   5void
   6e (f) {
-> 7 b = 
   8 b  & 5 ^ 
   9 a[b ^ f ];
   10   }
(lldb) frame var
(int) j = 0
(int) k = 0
(int) i = 

(int) dm = 

(lldb) 

$ gdb opt 
Breakpoint 1, e (f=0) at a.c:7
7b = 
(gdb) frame var
#0  e (f=0) at a.c:7
7b = 
(gdb) bt
#0  e (f=0) at a.c:7
#1  h (f=0) at a.c:22
#2  main () at a.c:32
(gdb) s
main () at a.c:38
38  h(d[0][j][k]);
(gdb) frame var
#0  main () at a.c:38
38  h(d[0][j][k]);
(gdb) c
Continuing.
ciao[Inferior 1 (process 153) exited normally]
(gdb)

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

[lldb-dev] [Bug 45905] New: [lldb][unittest] Assertion failed : (m_replayers.find(RunID) == m_replayers.end())

[via lldb-dev]

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

Bug ID: 45905
   Summary: [lldb][unittest] Assertion failed :
(m_replayers.find(RunID) == m_replayers.end())
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: sylvain.a...@ubisoft.com
CC: alexandre.ga...@ubisoft.com, jdevliegh...@apple.com,
llvm-b...@lists.llvm.org

This happens in the LLDB unit tests, when building under windows.

In lldb\unittests\Utility\ReproducerInstrumentationTest.cpp:
  LLDB_REGISTER_METHOD(void, InstrumentedFoo, Validate, ());
  (...)
  LLDB_REGISTER_METHOD(void, InstrumentedBar, Validate, ());

The clashing IDs are evaluated as follows:
   &invoke::method<(&InstrumentedFoo::Validate)>::record
  and
   &invoke::method<(&InstrumentedBar::Validate)>::record


Both "record" implementations are only calling Validate() through the vtable,
so the implementations are identical for both.

The linker does COMDAT folding (option /OPT:ICF), which merges the 2 functions,
so their address, which is used as an ID, end up being identical.

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

[lldb-dev] [Bug 45905] [lldb][unittest] Assertion failed : (m_replayers.find(RunID) == m_replayers.end())

[via lldb-dev]

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

Jonas Devlieghere  changed:

   What|Removed |Added

   Assignee|lldb-dev@lists.llvm.org |jdevliegh...@apple.com

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

Re: [lldb-dev] Is there a just-my-code like debugging mode for LLDB?

[Greg Clayton via lldb-dev]

So one idea is to improve the PlatformAndroid to use "adb" to copy all system 
libraries over and pre-cache all system libraries instead of letting it happen 
one by one.

Android is also very inefficient in loading shared libraries. It will load them 
one by one and each one involves 2 stops since the breakpoint we set gets hit 
once before the library is loaded and once again when it has been loaded. Each 
stop for shared libraries takes a few hundred milliseconds.

So it might be nice to have the PlatformAndroid grab all system libraries and 
populate the cache for a device in one large command and see if that improves 
things. To test this you can just download all system libraries to a single 
directory manually and then do set some settings:

(lldb) settings set target.exec-search-paths /path/to/cache
(lldb) settings set target.debug-file-search-paths /path/to/cache

So time the "adb" command that wildcard copies all libraries over, then set the 
settings, then run your debug sessions and see how much this helps. That will 
give you a good idea of sequentially grabbing each library is the cost.

If the cost is in parsing these libraries, we can look at parallelizing the 
loading of all the device shared libraries first (prior to debugging) and then 
launching when everything is pre-loaded.

Greg


> On May 8, 2020, at 9:07 AM, Emre Kultursay via lldb-dev 
>  wrote:
> 
> Hi lldb-dev,
> 
> TL;DR: Has there been any efforts to introduce something like "Just My Code" 
> debugging on LLDB? Debugging on Android would really benefit from this.
> 
> Details:
> 
> Native Android apps typically have a single .so file from the user, but load 
> ~150 system libraries.
> 
> When attaching LLDB remotely to an Android app, a significant amount of time 
> is spent on loading modules for those system libraries, even with a warm LLDB 
> cache that contains a copy of all these libraries. 
> 
> With a cold LLDB cache, things are much worse, because LLDB copies all those 
> libraries from the device back to the host to populate its cache. While one 
> might think this happens only once for a user, things are a bit worse for 
> Android. There are just too many libraries to copy, making it very slow, 
> there are new Android releases every year, and users typically use multiple 
> devices (e.g., x86, x86_64 emulators, arm32, arm64 devices), and multiple 
> hosts (work, home, laptop/desktop); thereby suffering from this issue more 
> than necessary.
> 
> If we can eliminate the latency of loading these modules, we can deliver a 
> much faster debugging startup time. In essence, this can be considered as a 
> form of Just My Code debugging. 
> 
> Prototype and Experiments
> 
> I built a simple prototype that only loads a single user module, and totally 
> avoids loading ~150 system modules. I ran it on my Windows host against an 
> Android emulator to measure the end to end latency of "Connect + Attach + 
> Resume + Hit 1st breakpoint immediately" .
> For warm LLDB cache:
> Without just-my-code: 23 seconds
> With just-my-code: 14 seconds
> For cold LLDB cache:
> Without just-my-code: 120 seconds
> With just-my-code: 16 seconds
> 
> I want to solicit some feedback and gather thoughts around this idea. It 
> would be great if there are any existing alternatives in LLDB to achieve my 
> goal, but otherwise, I can implement this on LLDB and I'd appreciate it if 
> anyone has any advice on how to implement such a feature.
> 
> Thanks.
> -Emre
> 
> 
>  
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

Re: [lldb-dev] Is there a just-my-code like debugging mode for LLDB?

[Greg Clayton via lldb-dev]

Adding Antonio Afonso since he did some work on speeding things up at Facebook 
for Android.

Emre: what version of LLDB are you using? Top of tree? One from a package 
distro?



> On May 13, 2020, at 3:00 PM, Greg Clayton  wrote:
> 
> So one idea is to improve the PlatformAndroid to use "adb" to copy all system 
> libraries over and pre-cache all system libraries instead of letting it 
> happen one by one.
> 
> Android is also very inefficient in loading shared libraries. It will load 
> them one by one and each one involves 2 stops since the breakpoint we set 
> gets hit once before the library is loaded and once again when it has been 
> loaded. Each stop for shared libraries takes a few hundred milliseconds.
> 
> So it might be nice to have the PlatformAndroid grab all system libraries and 
> populate the cache for a device in one large command and see if that improves 
> things. To test this you can just download all system libraries to a single 
> directory manually and then do set some settings:
> 
> (lldb) settings set target.exec-search-paths /path/to/cache
> (lldb) settings set target.debug-file-search-paths /path/to/cache
> 
> So time the "adb" command that wildcard copies all libraries over, then set 
> the settings, then run your debug sessions and see how much this helps. That 
> will give you a good idea of sequentially grabbing each library is the cost.
> 
> If the cost is in parsing these libraries, we can look at parallelizing the 
> loading of all the device shared libraries first (prior to debugging) and 
> then launching when everything is pre-loaded.
> 
> Greg
> 
> 
>> On May 8, 2020, at 9:07 AM, Emre Kultursay via lldb-dev 
>> mailto:lldb-dev@lists.llvm.org>> wrote:
>> 
>> Hi lldb-dev,
>> 
>> TL;DR: Has there been any efforts to introduce something like "Just My Code" 
>> debugging on LLDB? Debugging on Android would really benefit from this.
>> 
>> Details:
>> 
>> Native Android apps typically have a single .so file from the user, but load 
>> ~150 system libraries.
>> 
>> When attaching LLDB remotely to an Android app, a significant amount of time 
>> is spent on loading modules for those system libraries, even with a warm 
>> LLDB cache that contains a copy of all these libraries. 
>> 
>> With a cold LLDB cache, things are much worse, because LLDB copies all those 
>> libraries from the device back to the host to populate its cache. While one 
>> might think this happens only once for a user, things are a bit worse for 
>> Android. There are just too many libraries to copy, making it very slow, 
>> there are new Android releases every year, and users typically use multiple 
>> devices (e.g., x86, x86_64 emulators, arm32, arm64 devices), and multiple 
>> hosts (work, home, laptop/desktop); thereby suffering from this issue more 
>> than necessary.
>> 
>> If we can eliminate the latency of loading these modules, we can deliver a 
>> much faster debugging startup time. In essence, this can be considered as a 
>> form of Just My Code debugging. 
>> 
>> Prototype and Experiments
>> 
>> I built a simple prototype that only loads a single user module, and totally 
>> avoids loading ~150 system modules. I ran it on my Windows host against an 
>> Android emulator to measure the end to end latency of "Connect + Attach + 
>> Resume + Hit 1st breakpoint immediately" .
>> For warm LLDB cache:
>> Without just-my-code: 23 seconds
>> With just-my-code: 14 seconds
>> For cold LLDB cache:
>> Without just-my-code: 120 seconds
>> With just-my-code: 16 seconds
>> 
>> I want to solicit some feedback and gather thoughts around this idea. It 
>> would be great if there are any existing alternatives in LLDB to achieve my 
>> goal, but otherwise, I can implement this on LLDB and I'd appreciate it if 
>> anyone has any advice on how to implement such a feature.
>> 
>> Thanks.
>> -Emre
>> 
>> 
>>  
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org 
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 

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

Re: [lldb-dev] Is there a just-my-code like debugging mode for LLDB?

[Greg Clayton via lldb-dev]

One reason to not only load your libraries is backtraces will be truncated for 
any stack frames that go through the system libraries. These tend to be in the 
stack traces a lot as we deal with Android all the time at Facebook...

Greg

> On May 8, 2020, at 9:07 AM, Emre Kultursay via lldb-dev 
>  wrote:
> 
> Hi lldb-dev,
> 
> TL;DR: Has there been any efforts to introduce something like "Just My Code" 
> debugging on LLDB? Debugging on Android would really benefit from this.
> 
> Details:
> 
> Native Android apps typically have a single .so file from the user, but load 
> ~150 system libraries.
> 
> When attaching LLDB remotely to an Android app, a significant amount of time 
> is spent on loading modules for those system libraries, even with a warm LLDB 
> cache that contains a copy of all these libraries. 
> 
> With a cold LLDB cache, things are much worse, because LLDB copies all those 
> libraries from the device back to the host to populate its cache. While one 
> might think this happens only once for a user, things are a bit worse for 
> Android. There are just too many libraries to copy, making it very slow, 
> there are new Android releases every year, and users typically use multiple 
> devices (e.g., x86, x86_64 emulators, arm32, arm64 devices), and multiple 
> hosts (work, home, laptop/desktop); thereby suffering from this issue more 
> than necessary.
> 
> If we can eliminate the latency of loading these modules, we can deliver a 
> much faster debugging startup time. In essence, this can be considered as a 
> form of Just My Code debugging. 
> 
> Prototype and Experiments
> 
> I built a simple prototype that only loads a single user module, and totally 
> avoids loading ~150 system modules. I ran it on my Windows host against an 
> Android emulator to measure the end to end latency of "Connect + Attach + 
> Resume + Hit 1st breakpoint immediately" .
> For warm LLDB cache:
> Without just-my-code: 23 seconds
> With just-my-code: 14 seconds
> For cold LLDB cache:
> Without just-my-code: 120 seconds
> With just-my-code: 16 seconds
> 
> I want to solicit some feedback and gather thoughts around this idea. It 
> would be great if there are any existing alternatives in LLDB to achieve my 
> goal, but otherwise, I can implement this on LLDB and I'd appreciate it if 
> anyone has any advice on how to implement such a feature.
> 
> Thanks.
> -Emre
> 
> 
>  
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

Re: [lldb-dev] Is there a just-my-code like debugging mode for LLDB?

[Emre Kultursay via lldb-dev]

Thanks for all the feedback and ideas.

After Jim's comment about iOS performance, I decided to dig deeper to
figure out why it's much slower to attach on Android compared to iOS. I
identified an ipv6/ipv4 issue about adb and the simple fix (llvm.org/D79757)
brought warm cache attach time down from 23 seconds to ~9 seconds, and cold
cache attach time from 120 seconds down to 16-20 seconds!! These are much
better numbers, but based on the numbers from Jim, I should probably
continue hunting for more Android-specific issues.

One thing I want to try is "settings set
plugin.process.gdb-remote.use-libraries-svr4 true". I measure it takes
~600ms to read the list of shared libs without this flag, and it's done 3
times from startup until we hit the first-breakpoint (load all system
libraries at attach time; then load base.odex, then load user-lib.so). So,
I expect this to shave up to ~1.8 seconds. I don't have any numbers on this
yet (does anyone know how much improvement I can expect with this?)

About my "don't-load-system-modules" idea (that I mistakenly called
"my-code-only" which is apparently something different): Pavel's concerns
about not loading modules sounds serious, especially about impacting
stability, and I'd like to avoid causing trouble there. So, instead of
that, I will try Greg's idea of pre-caching libraries. I'll start with some
measurements. I'm working from top-of-tree (I'm trying to build LLDB with
libxml2 now).


On Wed, May 13, 2020 at 3:08 PM Greg Clayton  wrote:

> One reason to not only load your libraries is backtraces will be truncated
> for any stack frames that go through the system libraries. These tend to be
> in the stack traces a lot as we deal with Android all the time at
> Facebook...
>
> Greg
>
> On May 8, 2020, at 9:07 AM, Emre Kultursay via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> Hi lldb-dev,
>
> *TL;DR: *Has there been any efforts to introduce something like "Just My
> Code" debugging on LLDB? Debugging on Android would really benefit from
> this.
>
> *Details:*
>
> Native Android apps typically have a single .so file from the user, but
> load ~150 system libraries.
>
> When attaching LLDB remotely to an Android app, a significant amount of
> time is spent on loading modules for those system libraries, even with a
> warm LLDB cache that contains a copy of all these libraries.
>
> With a cold LLDB cache, things are much worse, because LLDB copies all
> those libraries from the device back to the host to populate its cache.
> While one might think this happens only once for a user, things are a bit
> worse for Android. There are just too many libraries to copy, making it
> very slow, there are new Android releases every year, and users typically
> use multiple devices (e.g., x86, x86_64 emulators, arm32, arm64 devices),
> and multiple hosts (work, home, laptop/desktop); thereby suffering from
> this issue more than necessary.
>
> If we can eliminate the latency of loading these modules, we can deliver a
> much faster debugging startup time. In essence, this can be considered as a
> form of Just My Code debugging.
>
> *Prototype and Experiments*
>
> I built a simple prototype that only loads a single user module, and
> totally avoids loading ~150 system modules. I ran it on my Windows host
> against an Android emulator to measure the end to end latency of "Connect +
> Attach + Resume + Hit 1st breakpoint immediately" .
>
>- For warm LLDB cache:
>   - Without just-my-code: 23 seconds
>   - With just-my-code: 14 seconds
>- For cold LLDB cache:
>   - Without just-my-code: 120 seconds
>   - With just-my-code: 16 seconds
>
>
> I want to solicit some feedback and gather thoughts around this idea. It
> would be great if there are any existing alternatives in LLDB to achieve my
> goal, but otherwise, I can implement this on LLDB and I'd appreciate it if
> anyone has any advice on how to implement such a feature.
>
> Thanks.
> -Emre
>
>
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 45920] New: lldb wrongly stopped at a statement for nesting loop using step instruction

[via lldb-dev]

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

Bug ID: 45920
   Summary: lldb wrongly stopped at a statement for nesting loop
using step instruction
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: yangyib...@hust.edu.cn
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org

$ lldb --version
lldb version 11.0.0
  clang revision 871beba234a83a2a02da9dedbd59b91a1bfbd7af
  llvm revision 871beba234a83a2a02da9dedbd59b91a1bfbd7af

$ clang --version
clang version 11.0.0 (/home/yibiao/.cache/yay/llvm-git/llvm-project
871beba234a83a2a02da9dedbd59b91a1bfbd7af)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin


$ lldb a.out
(lldb) target create "a.out"
Current executable set to '/home/yibiao/Debugger/a.out' (x86_64).
(lldb) b main
Breakpoint 1: where = a.out`main + 11 at small.c:4:10, address =
0x0040111b
(lldb) r
Process 13529 launched: '/home/yibiao/Debugger/a.out' (x86_64)
Process 13529 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x0040111b a.out`main at small.c:4:10
   1int main ()
   2{
   3  int x, y;
-> 4  for (x = __INT_MAX__ - 1; x < __INT_MAX__; x++)
   5for (y = -1; y <= 0; y++)
   6  if ((x + 1 - y) != (int) (x + 1U - y))
   7return 1;
(lldb) si -c 35
Process 13529 stopped
* thread #1, name = 'a.out', stop reason = instruction step into
frame #0: 0x0040113a a.out`main at small.c:5:5
   2{
   3  int x, y;
   4  for (x = __INT_MAX__ - 1; x < __INT_MAX__; x++)
-> 5for (y = -1; y <= 0; y++)
   6  if ((x + 1 - y) != (int) (x + 1U - y))
   7return 1;
   8  return 0;
(lldb) var
(int) x = 2147483646
(int) y = 1
(lldb) si
Process 13529 stopped
* thread #1, name = 'a.out', stop reason = instruction step into
frame #0: 0x00401179 a.out`main at small.c:7:16
   4  for (x = __INT_MAX__ - 1; x < __INT_MAX__; x++)
   5for (y = -1; y <= 0; y++)
   6  if ((x + 1 - y) != (int) (x + 1U - y))
-> 7return 1;
   8  return 0;
   9}
(lldb) 



/**
lldb is wrongly stopped at Line 7.
However, when setting breakpoint at Line 7. The program is directly exit. 
***/


$ lldb a.out
(lldb) target create "a.out"
Current executable set to '/home/yibiao/Debugger/a.out' (x86_64).
(lldb) b 7
Breakpoint 1: where = a.out`main + 74 at small.c:7:9, address =
0x0040115a
(lldb) r
Process 13589 launched: '/home/yibiao/Debugger/a.out' (x86_64)
Process 13589 exited with status = 0 (0x)



$ cat small.c
int main ()
{
  int x, y;
  for (x = __INT_MAX__ - 1; x < __INT_MAX__; x++)
for (y = -1; y <= 0; y++)
  if ((x + 1 - y) != (int) (x + 1U - y))
return 1;
  return 0;
}

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

[lldb-dev] [Bug 45921] New: lldb not directly stopped at a specified statement

[via lldb-dev]

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

Bug ID: 45921
   Summary: lldb not directly stopped at a specified statement
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: yangyib...@hust.edu.cn
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org

$ lldb --version
lldb version 11.0.0
  clang revision 871beba234a83a2a02da9dedbd59b91a1bfbd7af
  llvm revision 871beba234a83a2a02da9dedbd59b91a1bfbd7af

$ clang --version
clang version 11.0.0 (/home/yibiao/.cache/yay/llvm-git/llvm-project
871beba234a83a2a02da9dedbd59b91a1bfbd7af)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

$ clang -g small.c
$ lldb a.out
(lldb) target create "a.out"
Current executable set to '/home/yibiao/Debugger/a.out' (x86_64).
(lldb) b 5
Breakpoint 1: where = a.out`sig + 13 at small.c:5:3, address =
0x0040114d
(lldb) r
Process 15731 launched: '/home/yibiao/Debugger/a.out' (x86_64)
Process 15731 stopped
* thread #1, name = 'a.out', stop reason = signal SIGFPE: integer divide by
zero
frame #0: 0x00401193 a.out`main at small.c:10:9
   7
   8int main () {
   9  signal(8, sig);
-> 10 k = i / j;
   11 return 0;
   12   }
(lldb) s
Process 15731 stopped
* thread #1, name = 'a.out', stop reason = step in
frame #0: 0x00401141 a.out`sig(s=0) at small.c:4
   1#include 
   2
   3static int i, j, k;
-> 4void sig (int s) {
   5  exit(0);
   6}
   7
(lldb) s
Process 15731 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x0040114d a.out`sig(s=8) at small.c:5:3
   2
   3static int i, j, k;
   4void sig (int s) {
-> 5  exit(0);
   6}
   7
   8int main () {
(lldb) 


/
As shows, LLDB not directly stopped at the specified statement Line 5. When
continue stepping, it will stopped at Line 5 again. 
*/


$ cat small.c
#include 

static int i, j, k;
void sig (int s) {
  exit(0);
}

int main () {
  signal(8, sig);
  k = i / j;
  return 0;
}

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