Community
Participate
Working Groups
I can easily get gdb to connect to a remote Android target running gdbserver on VirtualBox. Essentially, I follow the instructions here: http://source.android.com/porting/debugging_gdb.html to recap here, I launch gdbserver on the target. I then launch gdb passing it the unstripped version of the executable. I then run the following three commands: set solib-absolute-prefix <path to local copy of root file system with symbols> set solib-search-path <path to lib directory in that local copy> target remote <ip address>:<port> It then connects and gives me the place where gdbserver stopped the program, i.e. right at the start in the dynamic loader. I can then set a breakpoint in main, let it continue and hit it. I don't know how to set up the launch configuration to do the same. I tried putting the two set commands into a gdbinit but that didn't seem to help with source paths when I break the execution. I'll attach the gdb trace log.
Created attachment 170729 [details] gdb trace log gdb log of the closest I got to getting it working. BTW, this is gdb 7.1-ubuntu.
I guess the frustrating thing is that the stack frames don't seem to have any symbol information at all. Would there be a difference between MI and CI on that? I get full stack with source info and everything from the CI.
The gdb hardware debugger gives me the control I want so I'm going to focus on that.
Created attachment 170732 [details] log from gdb h/w debugging This is the log from using the gdb h/w debugger. The stack is much better. And further on, I get the proper stack traces and source lookups.
A couple of things that might be of interest which I read in the GDB documentation: - The set solib-absolute-prefix command is an alias for set sysroot. - If you want to use `solib-search-path' instead of `sysroot', be sure to set `sysroot' to a nonexistent directory to prevent gdb from finding your host's libraries. `sysroot' is preferred; setting it to a nonexistent directory may interfere with automatic loading of shared library symbols. This seems to say that the two commands recommended by Android should not be used together ('set solib-absolute-prefix' and 'set solib-search-path') Now, when comparing the two logs, I notice two main differences: 1- the working session uses 'set solib-absolute-prefix', but I assume you have the same command in your gdbinit file of the failed session, so that is probably not the problem 2- the working session does not load a binary to debug. Was this intentional? The android instructions seem to say you should load one. Will the debug session continue to work once passed the initial loading phase if there is no binary? To find out if it is the loading of the binary that is causing the problem you can turn off loading the binary with a tiny change to the code (I just disabled this ability for Helios because it was causing problems). Just change the line of org.eclipse.cdt.dsf.gdb.internal.ui.launching.GDBSolibBlock that sets fUseSolibForApp to false, to make it true instead. After that, in your launch, you can check the box Debugger -> Share libraries -> "Use shared library symbols for debugged application". This should prevent the loading of the binary and you can see if things work better. If they do, we can try to figure out why the binary is causing the stack frames to be bad.
(In reply to comment #6) > This seems to say that the two commands recommended by Android should not be > used together ('set solib-absolute-prefix' and 'set solib-search-path') Except that they work great from the command line. So I don't think that's really an issue. > Now, when comparing the two logs, I notice two main differences: > 1- the working session uses 'set solib-absolute-prefix', but I assume you have > the same command in your gdbinit file of the failed session, so that is > probably not the problem Yes, they are in the gdbinit. > 2- the working session does not load a binary to debug. Was this intentional? > The android instructions seem to say you should load one. Will the debug > session continue to work once passed the initial loading phase if there is no > binary? The binary is passed as an argument to gdb. It loads it automatically on start up. I wondered why we load it manually again later. > To find out if it is the loading of the binary that is causing the problem you > can turn off loading the binary with a tiny change to the code (I just disabled > this ability for Helios because it was causing problems). Just change the line > of org.eclipse.cdt.dsf.gdb.internal.ui.launching.GDBSolibBlock that sets > fUseSolibForApp to false, to make it true instead. > > After that, in your launch, you can check the box Debugger -> Share libraries > -> "Use shared library symbols for debugged application". This should prevent > the loading of the binary and you can see if things work better. If they do, > we can try to figure out why the binary is causing the stack frames to be bad. I was able to use the gdb h/w debugger to find my problem so I don't need this right away. We should look at it again in the future. In particular, making the startup of gdb more configurable. Another example of that is to prevent gdb from automatically continuing. I just want it to hook up to gdbserver and let me look around first. In that way, the remote launch is much more like an attach.
(In reply to comment #7) > (In reply to comment #6) > > This seems to say that the two commands recommended by Android should not be > > used together ('set solib-absolute-prefix' and 'set solib-search-path') > > Except that they work great from the command line. So I don't think that's > really an issue. I guess I was more asking if you really needed both. You should be able to have only one of the two and have things still work. > > Now, when comparing the two logs, I notice two main differences: > > 1- the working session uses 'set solib-absolute-prefix', but I assume you have > > the same command in your gdbinit file of the failed session, so that is > > probably not the problem > > Yes, they are in the gdbinit. You put both commands in gdbinit and you also configured the solib path in the launch configuration? I guess it won't hurt. > > 2- the working session does not load a binary to debug. Was this intentional? > > The android instructions seem to say you should load one. Will the debug > > session continue to work once passed the initial loading phase if there is no > > binary? > > The binary is passed as an argument to gdb. It loads it automatically on start > up. I wondered why we load it manually again later. Not for DSF-GDB. You'll notice, in your working session, the warning: 557,267 &"warning: Could not load vsyscall page because no executable was specified\ntry using the \\ "file\" command first." The idea was to keep the gdb command-line the exact same: gdb -i mi2. In my mind, this allows for easier troubleshooting. > I was able to use the gdb h/w debugger to find my problem so I don't need this > right away. We should look at it again in the future. You are using the DSF-GDB Jtag launch right? > In particular, making the > startup of gdb more configurable. Another example of that is to prevent gdb > from automatically continuing. I just want it to hook up to gdbserver and let > me look around first. In that way, the remote launch is much more like an > attach. That is a good usecase.
(In reply to comment #8) > I guess I was more asking if you really needed both. You should be able to > have only one of the two and have things still work. Nope, need them both. The first one picks up things like the dynamic linker which is where the gdbserver holds the process until you continue. > You put both commands in gdbinit and you also configured the solib path in the > launch configuration? I guess it won't hurt. Well, no. I have a custom gdbinit for the dsf/gdb launch where I put the two set commands. They didn't seem to do anything from there. The gdb h/w launch has no gdbinit. > Not for DSF-GDB. You'll notice, in your working session, the warning: > > 557,267 &"warning: Could not load vsyscall page because no executable was > specified\ntry using the \\ > "file\" command first." > > The idea was to keep the gdb command-line the exact same: gdb -i mi2. In my > mind, this allows for easier troubleshooting. True, but if someone gets instructions on how to use gdb to debug a special platform, like Android, it would be nice if we could use those instructions in our launch. > > > I was able to use the gdb h/w debugger to find my problem so I don't need this > > right away. We should look at it again in the future. > > You are using the DSF-GDB Jtag launch right? I guess it was. I just took the default. > > > In particular, making the > > startup of gdb more configurable. Another example of that is to prevent gdb > > from automatically continuing. I just want it to hook up to gdbserver and let > > me look around first. In that way, the remote launch is much more like an > > attach. > > That is a good usecase.
(In reply to comment #9) > (In reply to comment #8) > > I guess I was more asking if you really needed both. You should be able to > > have only one of the two and have things still work. > > Nope, need them both. The first one picks up things like the dynamic linker > which is where the gdbserver holds the process until you continue. Sigh. I shouldn't trust the gdb doc ;-) I think using gdbinit is the best way for this then. > Well, no. I have a custom gdbinit for the dsf/gdb launch where I put the two > set commands. They didn't seem to do anything from there. My guess is that the commands worked. You can confirm by going to the gdb eclipse console and typing show solib-absolute-prefix show solib-search-path > > Not for DSF-GDB. You'll notice, in your working session, the warning: > > > > 557,267 &"warning: Could not load vsyscall page because no executable was > > specified\ntry using the \\ > > "file\" command first." So, if you didn't actually specify the executable to the hardware launch, how is this working? > > The idea was to keep the gdb command-line the exact same: gdb -i mi2. In my > > mind, this allows for easier troubleshooting. > > True, but if someone gets instructions on how to use gdb to debug a special > platform, like Android, it would be nice if we could use those instructions in > our launch. That would be nice, but that also complicates the way we launch, because right now we abstract things away from the user.
(In reply to comment #8) > > The binary is passed as an argument to gdb. It loads it automatically on start > > up. I wondered why we load it manually again later. > > Not for DSF-GDB. Also not for CDI...not any more, anyway. I made CDI behave like DSF as part of bug 310304. The change was in GDBJtagLaunchConfigurationDelegate.launch()
