News:

As usual while waiting for the next release - don't forget to check the nightly builds in the forum.

Main Menu

[GDB] How to pass a dynamically defined parameter to the debugger?

Started by J., December 04, 2016, 01:15:20 AM

Previous topic - Next topic

J.

How to pass the dynamically determined PID to the debugger to attach to this PID? This is to avoid manual edits of the PID each time when gdb is asked to attach to the host process.

Living on Win10 with CB16.01.

Thanks,
J. 

oBFusCATed

Debug -> Attach is the only possible way to attach to a process and you need to know the pid of the process to succeed.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

J.

Thanks - are you saying that it is not possible to pass the PID dynamically determined by some script to GDB? Even not by using

  • some .gdb script called, e.g., from inside GDB (i.e. the gdb shell)
  • an env variable together with the GDB switch '--pid=...' from outside gdb?

oBFusCATed

I don't think, so it is possible at the moment.
But if you describe your use case and it is something generally useful and easy to implement I can do something about it.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

ollydbg

@J.
Please tell use what is the steps you want to get the automatic pid value?
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

J.

@Ollydbg:

On the GDB shell the pid can be determined by (gdb) shell ps -W | gawk "/APP\.EXE/{ print $1 }" where the -W flag retrieves the windows processes as well.  Outside GDB, i.e. using cmd, the same works with 'tasklist' instead of 'ps -W'.

What could be an easy and quick solution is a canned sequence of commands loaded at gdb start (.gdbinit?). But up to now I could not manage to define the local gdb variable $PID using 'set $PID=...' and then passing that to 'attach'. Any ideas?


Ultimately I want to debug a .dll compiled by MinGW which is called by the host excel.exe.

Sorry for the pure formatting, I am travelling right now.

oBFusCATed

Quote from: J. on December 04, 2016, 01:18:48 PM
What could be an easy and quick solution is a canned sequence of commands loaded at gdb start (.gdbinit?). But up to now I could not manage to define the local gdb variable $PID using 'set $PID=...' and then passing that to 'attach'. Any ideas?

Adding stuff to .gdbinit won't help, because C::B is the one that starts gdb and it won't ever start it if you don't use the debug->start or debug->attach menu items.
Without gdb starting .gdbinit does nothing.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

ollydbg

Quote from: J. on December 04, 2016, 01:18:48 PM
Ultimately I want to debug a .dll compiled by MinGW which is called by the host excel.exe.
What is the method to get the pid of excel.exe? You want to get this pid in C::B, and then let C::B to call the gdb to attach the excel.exe?
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.