Open ycwan9 opened 2 years ago
@llvm/issue-subscribers-debuginfo
is this still open to work on ?
Hi!
This issue may be a good introductory issue for people new to working on LLVM. If you would like to work on this issue, your first steps are:
1) Assign the issue to you.
2) Fix the issue locally.
3) Run the test suite locally.
3.1) Remember that the subdirectories under test/
create fine-grained testing targets, so you can
e.g. use make check-clang-ast
to only run Clang's AST tests.
4) Create a git
commit
5) Run git clang-format HEAD~1
to format your changes.
6) Submit the patch to Phabricator.
6.1) Detailed instructions can be found here
For more instructions on how to submit a patch to LLVM, see our documentation.
If you have any further questions about this issue, don't hesitate to ask via a comment on this Github issue.
@llvm/issue-subscribers-good-first-issue
Is this issue already fixed? Under clang and lldm version 17.0.6, I was not able to reproduce this issue. Instead of displaying the function main
as the top frame at line 9, lldb in the meantime displays the inlined function e
explicitly.
LLDB trace:
➜ lldb-error git:(master) ✗ clang -Og -g -o a.elf a.c
➜ lldb-error git:(master) ✗ lldb a.elf
(lldb) target create "a.elf"
Current executable set to '/Users/robincaloudis/lldb-error/a.elf' (arm64).
(lldb) b main
Breakpoint 1: where = a.elf`main + 4 [inlined] e at a.c:7:15, address = 0x0000000100003f78
(lldb) r
Process 55952 launched: '/Users/robincaloudis/lldb-error/a.elf' (arm64)
Process 55952 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
frame #0: 0x0000000100003f78 a.elf`main [inlined] e at a.c:7:15 [opt]
4 int8_t d[1][5][9]
5 ;
6 uint8_t e(void) {
-> 7 uint8_t f = b[5][0];
8 int g = c;
9 d[0][4][7] =
10 g >= 8 ? f : f >> g;
warning: a.elf was compiled with optimization - stepping may behave oddly; variables may not be available.
(lldb) s
Process 55952 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = step in
frame #0: 0x0000000100003f7c a.elf`main [inlined] e at a.c:10:7 [opt]
7 uint8_t f = b[5][0];
8 int g = c;
9 d[0][4][7] =
-> 10 g >= 8 ? f : f >> g;
11 return 0
12 ; }
13 int main(void) {
(lldb) s
Process 55952 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = step in
frame #0: 0x0000000100003f80 a.elf`main [inlined] e at a.c:8:12 [opt]
5 ;
6 uint8_t e(void) {
7 uint8_t f = b[5][0];
-> 8 int g = c;
9 d[0][4][7] =
10 g >= 8 ? f : f >> g;
11 return 0
(lldb) s
Process 55952 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = step in
frame #0: 0x0000000100003f88 a.elf`main [inlined] e at a.c:10:7 [opt]
7 uint8_t f = b[5][0];
8 int g = c;
9 d[0][4][7] =
-> 10 g >= 8 ? f : f >> g;
11 return 0
12 ; }
13 int main(void) {
(lldb) s
Process 55952 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = step in
frame #0: 0x0000000100003f94 a.elf`main [inlined] e at a.c:9:14 [opt]
6 uint8_t e(void) {
7 uint8_t f = b[5][0];
8 int g = c;
-> 9 d[0][4][7] =
10 g >= 8 ? f : f >> g;
11 return 0
12 ; }
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = step in
* frame #0: 0x0000000100003f94 a.elf`main [inlined] e at a.c:9:14 [opt]
frame #1: 0x0000000100003f78 a.elf`main at a.c:15:3 [opt]
frame #2: 0x0000000181403f28 dyld`start + 2236
(lldb) r
There is a running process, kill it and restart?: [Y/n] n
(lldb) s
Process 55952 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = step in
frame #0: 0x0000000100003fa0 a.elf`main at a.c:17:7 [opt]
14 int i;
15 e();
16 for (i = 0; i < 8; i++)
-> 17 a = i;
18 }
(lldb)
Versions:
➜ lldb-error git:(master) ✗ clang --version
Homebrew clang version 17.0.6
Target: arm64-apple-darwin22.5.0
Thread model: posix
InstalledDir: /opt/homebrew/opt/llvm/bin
➜ lldb-error git:(master) ✗ lldb --version
lldb version 17.0.6
When compiled with
-Og
, after functione
finishes, LLDB remains at line 9 in the next step, while displayes functionmain
as the current top frame. This behavior is not present in GDB.Source program:
Compile flags:
LLDB trace:
GDB trace: