[lldb-dev] [Bug 45608] New: lldb not stopped at a inline function call statement
https://bugs.llvm.org/show_bug.cgi?id=45608
Bug ID: 45608
Summary: lldb not stopped at a inline function call statement
Product: lldb
Version: 9.0
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 9.0.1
$ cat small.c
__attribute__((always_inline))
inline void foo(int *x) {
*x = 1;
}
int main() {
int x;
foo(&x);
return x;
}
$ clang -g small.c; lldb ./a.out
(lldb) target create "./a.out"
Current executable set to './a.out' (x86_64).
(lldb) breakpoint set -f small.c -l 8
Breakpoint 1: where = a.out`main + 46 at small.c:9:10, address =
0x116e
(lldb) run
Process 40617 launched: '/home/yibiao/cv-gcov/a.out' (x86_64)
Process 40617 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x516e a.out`main at small.c:9:10
6int main() {
7 int x;
8 foo(&x);
-> 9 return x;
10 }
/***
when setting breakpoint at line 8 in small.c, it stopped at line 9.
However, when we using "process launch --stop-at-entry" and then setting
breakpoint on address main+0. It will stopped at line 8 as follows:
***/
$ clang -g small.c; lldb ./a.out
(lldb) target create "./a.out"
Current executable set to './a.out' (x86_64).
(lldb) process launch --stop-at-entry
Process 40841 launched: '/home/yibiao/cv-gcov/a.out' (x86_64)
(lldb) breakpoint set -a main+0
Breakpoint 1: where = a.out`main at small.c:6, address = 0x5140
(lldb) c
Process 40841 resuming
Process 40841 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x5140 a.out`main at small.c:6
3 *x = 1;
4}
5
-> 6int main() {
7 int x;
8 foo(&x);
9 return x;
(lldb) step
Process 40841 stopped
* thread #1, name = 'a.out', stop reason = step in
frame #0: 0x5164 a.out`main at small.c:8
5
6int main() {
7 int x;
-> 8 foo(&x);
9 return x;
10 }
/***
It seems that this is an inconsistent behavior in lldb.
***/
--
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 45609] New: lldb wrongly stopped at abort() function within a nested for loop
https://bugs.llvm.org/show_bug.cgi?id=45609
Bug ID: 45609
Summary: lldb wrongly stopped at abort() function within a
nested for loop
Product: lldb
Version: 9.0
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 9.0.1
$ clang -g small.c; lldb ./a.out
(lldb) target create "./a.out"
Current executable set to './a.out' (x86_64).
(lldb) b small.c:5
Breakpoint 1: where = a.out`main + 49 at small.c:5:12, address =
0x1171
(lldb) run
Process 45684 launched: '/home/yibiao/cv-gcov/a.out' (x86_64)
Process 45684 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x5171 a.out`main at small.c:5:12
2{
3 for (int x = 1; x < 2; x++)
4for (int y = -1; y <= 0; y++)
-> 5 if ((x - y) != (x - y))
6__builtin_abort ();
7 return 0;
8}
(lldb) step
Process 45684 stopped
* thread #1, name = 'a.out', stop reason = step in
frame #0: 0x518f a.out`main at small.c:4:31
1int main ()
2{
3 for (int x = 1; x < 2; x++)
-> 4for (int y = -1; y <= 0; y++)
5 if ((x - y) != (x - y))
6__builtin_abort ();
7 return 0;
(lldb) step
Process 45684 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x5171 a.out`main at small.c:5:12
2{
3 for (int x = 1; x < 2; x++)
4for (int y = -1; y <= 0; y++)
-> 5 if ((x - y) != (x - y))
6__builtin_abort ();
7 return 0;
8}
(lldb) step
Process 45684 stopped
* thread #1, name = 'a.out', stop reason = step in
frame #0: 0x518f a.out`main at small.c:4:31
1int main ()
2{
3 for (int x = 1; x < 2; x++)
-> 4for (int y = -1; y <= 0; y++)
5 if ((x - y) != (x - y))
6__builtin_abort ();
7 return 0;
(lldb) step
Process 45684 stopped
* thread #1, name = 'a.out', stop reason = step in
frame #0: 0x519d a.out`main at small.c:6:25
3 for (int x = 1; x < 2; x++)
4for (int y = -1; y <= 0; y++)
5 if ((x - y) != (x - y))
-> 6__builtin_abort ();
7 return 0;
8}
/***
In the last step, lldb stopped at __builtin_abort(); statement.
When we directly setting breakpoint at small.c:6, lld is not stopped as
follows:
***/
$ lldb ./a.out
(lldb) target create "./a.out"
Current executable set to './a.out' (x86_64).
(lldb) b small.c:6
Breakpoint 1: where = a.out`main + 69 at small.c:6:8, address =
0x1185
(lldb) run
Process 45740 launched: '/home/yibiao/cv-gcov/a.out' (x86_64)
Process 45740 exited with status = 0 (0x)
$ cat small.c
int main ()
{
for (int x = 1; x < 2; x++)
for (int y = -1; y <= 0; y++)
if ((x - y) != (x - y))
__builtin_abort ();
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 45609] lldb wrongly stopped at abort() function within a nested for loop
https://bugs.llvm.org/show_bug.cgi?id=45609 David Blaikie changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE CC||dblai...@gmail.com --- Comment #1 from David Blaikie --- *** This bug has been marked as a duplicate of bug 19864 *** -- 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] LLDB problems on remote debugging
> On Apr 16, 2020, at 2:30 AM, Rui Hong via lldb-dev
> wrote:
>
> Hi LLDB devs,
>
> I'm working on porting LLDB to work with an existing simulator(which has GDB
> stub, remote debugging). This simulator used to work with GDB. When using
> with GDB, the target file(ELF) is loaded by GDB command "load" or "remote
> put".
> From a LLVM talk project which is very similar to my project, their target
> file is loaded by the simulator itself( ./sim a.out , something like
> that), and lldb sets breakpoint, use "gdb-remote" command to connect to the
> simulator, the program starts to run immediately and stop at the breakpoint.
> I can't find any lldb command that is equal to "load" in GDB. And right now
> when I use "gdb-remote" to connect lldb to my simulator, lldb has command
> line output "Process 10115 stopped，thread #1, stop reason = signal
> SIGTRAP，frame #0: 0x". Does this mean the program has already
> started to run? I haven't loaded the binary.
>
> To sum my questions:
> 1. Does lldb has similar command like "load/remote put" in GDB?
Yes: "target modules load" with the --load option. Te be fair the Ted Woodward,
this code didn't exist when he was bringing up his simulator way back when, but
it was later added by someone.
The "target modules load --load --file /path/to/file" can be used to load an
ELF file as a dynamic loader would load the ELF file: it will only load the
program headers that are PT_LOAD. You can also use the "--set-pc-to-entry"
option to this command to set the PC to the entry point that is specified in
the ELF file. For this to work, you ELF file has to be statically linked and
all addresses should be correct in the file itself.
If you want to just blast an entire ELF file into memory and not only load
PT_LOAD segments, then you can use "memory write --infile /path/to/binfile
".
Hopefully "target modules load --load" will work for you.
The code for this command is in CommandObjectTarget.cpp in
CommandObjectTargetModulesLoad::DoExecute() if the second "if (load)" statement
(line CommandObjectTarget.cpp :2827 for me). What it does is it will ask the
ObjectFile for the file you are loading in the command (ObjectFileELF) about
what its "loadables" are:
std::vector
loadables(objfile->GetLoadableData(*target));
So as long as this function returns what you are interested in loading, then
you should be good.
> 2. Does "gdb-remote" command in lldb do the "loading binary" job?
It the invocation _can_ do the loading, but it really depends on the GDB
server. Typically there are a few ways to use GDB server:
1 - have _it_ launch the program for you:
$ gdbserver [options] -- /path/to/a.out arg1 arg2 arg2
2 - just launch a GDB server which you will connect to
$ gdbserver [options]
3 - have gdb server attach to a process for you:
$ gdbserver [options] --pid 123
When LLDB attaches to a GDB server, it will ask it if it has a process with
some GDB remote packets, and if it has one, it is good to go and start
debugging (solution 1 and 3 above). If it doesn't, it can send a launch ("A"
packet) or attach packet to attach to a process or wait for one (solution 2
above).
> 3. Will the program start to run immediately after "gdb-remote" command in
> lldb?
If you have a GDB server, it will have the process stopped because the simple
packet send/response doesn't allow it to receive a packet if the process is
running. So usually a GDB server will start off stopped and the debugger can
auto continue or stop at this entry point (process launch --stop-at-entry 1).
> 4. Do I have to let my simulator to load the binary by itself?
This is really up to your workflow and how complex your simulator is. If you
are only ever loading one executable, then it might be easier to just have your
simulator do this launching and stop your simulation right at the entry point
and have the GDB server it vends respond to LLDB with information about the
process. If you don't have a real process ID, make sure your GDB server makes
one up (like process ID of 1). If you want to see the packet traffic, then you
can do this prior to sending the "gdb-remote " command in lldb:
(lldb) log enbable -f /tmp/packets.txt gdb-remote packets
(lldb) gdb-remote 1234
We have extended our GDB remote server with new packets. So be sure to read up
on what your GDB server _can_ provide, not mandatory, but many of these packets
are useful and can provide detailed information to ensure LLDB selects the
right targets and plug-ins. Details are in the LLDB code at:
lldb/docs/lldb-gdb-remote.txt
If you want to see how these are used, try debugging on a mac or linux and look
at the packet log to see how a debug session goes.
Tricky things you might need to do:
- make sure your GDB server details the registers that are available for your
architecture. This can happen with the xmlRegisters response to the qSupported
packet that will follow up with a packet that asks
