Bugzilla – Full Text Bug Listing
| Summary: | Enable disconnect button for attached remote gdbserver sessions | ||
|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Peter Feiner <peterfeiner> |
| Component: | cdt-debug | Assignee: | cdt-debug-inbox <cdt-debug-inbox> |
| Status: | CLOSED INVALID | QA Contact: | Ken Ryall <ken.ryall> |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | cdtdoug, marc.khouzam, pawel.1.piech, peterfeiner |
| Version: | 8.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
|
Description
Peter Feiner
If you use DSF-GDB (the default CDT debugger), the disconnect button should be enabled in this case. I just tried it. Any news on this? If not I'll mark as INVALID. Thanks (In reply to comment #2) > Any news on this? If not I'll mark as INVALID. Thanks Hi Marc, Sorry about the late reply. I didn't get an email for your update on the 8th. If I understand you correctly, the default debugger, which shows up as "gdb Debugger" in the Debug Configurations GUI, should have the disconnect button enabled. However, I want to use the "gdbserver Debugger", which allows me to specify a host:port to connect to. In terms of GDB commands, I'd like to accomplish the following: # On initialization file /home/peter/linux-2.6.32/vmlinux target remote host:1234 continue # Pressing the disconnect button in Eclipse should do this: ctrl-c # this isn't a GDB command, but me pressing control and c detach Can I accomplish this with DSF-GDB? Thanks, Peter (In reply to comment #3) > (In reply to comment #2) > > Any news on this? If not I'll mark as INVALID. Thanks > > Hi Marc, > > Sorry about the late reply. I didn't get an email for your update on the 8th. No problem. > If I understand you correctly, the default debugger, which shows up as "gdb > Debugger" in the Debug Configurations GUI, should have the disconnect button > enabled. However, I want to use the "gdbserver Debugger", which allows me to > specify a host:port to connect to. From your description you are using the C/C++ Attach to application type of launch, right? If you want to use 'target remote', you should use the C/C++ Application type and change the launch delegate. To change the launch delegate, look in the main tab at the bottom, there will be a hyperlink saying "Using GDB (DSF) Create Process Launcher - Select other...". Click on that and choose instead the other GDB (DSF) launch (I forget the name, something saying 'remote'). Note that this remote launch delegate has been moved to its own launch config type in HEAD, called C/C++ Remote Application. > In terms of GDB commands, I'd like to accomplish the following: > > # On initialization > file /home/peter/linux-2.6.32/vmlinux > target remote host:1234 > continue > > # Pressing the disconnect button in Eclipse should do this: > ctrl-c # this isn't a GDB command, but me pressing control and c > detach Pressing the Suspend button in the debug view should issue a ctrl-c for you. The detach button should also be enabled for you to use. > Can I accomplish this with DSF-GDB? I believe the steps above will allow you to do this. Let me know. (In reply to comment #4) > Pressing the Suspend button in the debug view should issue a ctrl-c for you. > The detach button should also be enabled for you to use. I was wrong about this last part. The 'detach/disconnect' button is disabled for the remote session. We currently only enable it for an attach session. First let me clarify, do you want to use the Remote launch (which starts the process for you), or do you want to use an Attach-Remote launch, which attaches to an already running process on a remote target. The 'detach' would not be too hard to support for a Remote session, but as you point out, we would have to also suspend a running process before doing the detach. The real question is why would this be useful? You would be left with a gdb that is not debugging anything... (In reply to comment #5) > (In reply to comment #4) > > > Pressing the Suspend button in the debug view should issue a ctrl-c for you. > > The detach button should also be enabled for you to use. > > I was wrong about this last part. The 'detach/disconnect' button is disabled > for the remote session. We currently only enable it for an attach session. > > First let me clarify, do you want to use the Remote launch (which starts the > process for you), or do you want to use an Attach-Remote launch, which attaches > to an already running process on a remote target. I want to use the Attach-Remote launch. Specifically, this is what I am doing: 1. I boot Linux in a virtual machine using QEMU/KVM with the -S flag specified. 2. In the VM, I load the kernel module that I am developing. 3. I use gdb to attach to QEMU (localhost:1234) 4. I do some debugging, decide what I want to change in the kernel module, etc. 5. I suspend the VM then detach and quit gdb. (as described in my earlier reply) 6. I make my changes to the kenrel module and compile it. 7. I go to step 2. (There are also some steps for telling GDB about the kernel module's sections' loaded addresses, which I've figured out how to do with eclipse+gdb.) > > The 'detach' would not be too hard to support for a Remote session, but as you > point out, we would have to also suspend a running process before doing the > detach. The real question is why would this be useful? You would be left with > a gdb that is not debugging anything... This process is faster than pressing stop (i.e., ctrl-c then quit in GDB) after step 4 because I do not have to restart the VM. (In reply to comment #6) > I want to use the Attach-Remote launch. Specifically, this is what I am doing: > > 1. I boot Linux in a virtual machine using QEMU/KVM with the -S flag specified. > 2. In the VM, I load the kernel module that I am developing. > 3. I use gdb to attach to QEMU (localhost:1234) > 4. I do some debugging, decide what I want to change in the kernel module, etc. > 5. I suspend the VM then detach and quit gdb. (as described in my earlier > reply) When using the attach-remote launch of DSF-GDB, I'm pretty sure the 'disconnect' button will do what you need. It will kill GDB without killing the remote process. You should not need to explicitly do a 'detach'. One issue may be in how your gdbserver is running. Is it using the --multi flag. That is what I use. > > The 'detach' would not be too hard to support for a Remote session, but as you > > point out, we would have to also suspend a running process before doing the > > detach. The real question is why would this be useful? You would be left with > > a gdb that is not debugging anything... > > This process is faster than pressing stop (i.e., ctrl-c then quit in GDB) after > step 4 because I do not have to restart the VM. You shouldn't have to, 'disconnect' should not kill the VM. Can you confirm that it works as I expect? Thanks (In reply to comment #7) > (In reply to comment #6) > > > I want to use the Attach-Remote launch. Specifically, this is what I am doing: > > > > 1. I boot Linux in a virtual machine using QEMU/KVM with the -S flag specified. > > 2. In the VM, I load the kernel module that I am developing. > > 3. I use gdb to attach to QEMU (localhost:1234) > > 4. I do some debugging, decide what I want to change in the kernel module, etc. > > 5. I suspend the VM then detach and quit gdb. (as described in my earlier > > reply) > > When using the attach-remote launch of DSF-GDB, I'm pretty sure the > 'disconnect' button will do what you need. It will kill GDB without killing > the remote process. You should not need to explicitly do a 'detach'. > This is what I need. However, as described in Björn's original message, this button is disabled when using the gdbserver debugger. > One issue may be in how your gdbserver is running. Is it using the --multi > flag. That is what I use. > > > > The 'detach' would not be too hard to support for a Remote session, but as you > > > point out, we would have to also suspend a running process before doing the > > > detach. The real question is why would this be useful? You would be left with > > > a gdb that is not debugging anything... > > > > This process is faster than pressing stop (i.e., ctrl-c then quit in GDB) after > > step 4 because I do not have to restart the VM. > > You shouldn't have to, 'disconnect' should not kill the VM. > > Can you confirm that it works as I expect? Thanks (In reply to comment #8) > > When using the attach-remote launch of DSF-GDB, I'm pretty sure the > > 'disconnect' button will do what you need. It will kill GDB without killing > > the remote process. You should not need to explicitly do a 'detach'. > > > > This is what I need. However, as described in Björn's original message, this > button is disabled when using the gdbserver debugger. From the date of 2007, I'm pretty sure that message was for the CDI debugger. With DSF-GDB, it should work for you. You can mark the bug as INVALID once you confirm you have what you need. (In reply to comment #9) > (In reply to comment #8) > > > > When using the attach-remote launch of DSF-GDB, I'm pretty sure the > > > 'disconnect' button will do what you need. It will kill GDB without killing > > > the remote process. You should not need to explicitly do a 'detach'. > > > > > > > This is what I need. However, as described in Björn's original message, this > > button is disabled when using the gdbserver debugger. > > From the date of 2007, I'm pretty sure that message was for the CDI debugger. > With DSF-GDB, it should work for you. > > You can mark the bug as INVALID once you confirm you have what you need. Hi Marc, Yes, you are right. I was not using DSF-GDB. Furthermore, I was using CDT-6 (not 8, as I originally reported in the bug report). I'm sorry for wasting your time. I appreciate your patience. Peter (In reply to comment #10) > Yes, you are right. I was not using DSF-GDB. Furthermore, I was using CDT-6 > (not 8, as I originally reported in the bug report). I'm sorry for wasting your > time. I appreciate your patience. No problem. I glad it is working properly. |