Re: gud.el gdb --cd and libtool

[Simon Josefsson]

"Stefan Monnier" <monnier+gnu/address@hidden> writes:

>> The recent patch below breaks M-x gdb when using it with libtool
>> (e.g., M-x gdb RET libtool gdb file RET).  Given the earlier related
>> problem with --fullname (solved to my satisfaction now though), it
>> seems gud.el should be made a little bit more aware of libtool.  I'm
>> not sure exactly what the best solution would be though, but hopefully
>> the gud.el maintainers can come up with something.
>> 
>> (The error is that libtool rightly complains that the -cd option isn't
>> known.)
>
> Yes, the problem with adding libtool-specific code is that it's not
> sufficient.  The same problem shows up in other cases (for example
> with PVM) where you can't run gdb directly.
>
> I think any post-processing of the command should be avoided as
> much as possible since we don't actually know what the command looks
> like and does other than the fact that at some point it should
> end up running the specified debugger.
> Adding this `cd' command seems not be worth it.  After all, why should
> it be the default when GDB is run within Emacs but not when it's
> run outside Emacs ?  GUD should concentrate on just interfacing with
> GDB and should not try to change GDB's behavior.

I think we agree.  The only options that will be passed to gdb should
be the one in the prompt the user enters.  Wouldn't it also be better
to add a interactive command in gdb for --fullname, and having
gud-mode send it to gdb when invoked?  Then even running dbx (if that
is supported at all) will work; dbx wouldn't reject the unknown
-fullname option and the user will get an error on the fullname
command (which could be disabled alltogether with an option if the
user is annoyed by it).

It would also be nice if gud-mode could find out if libtool is used,
and then suggest start the program as "libtool gdb foo" instead of
"gdb foo".  Detecting if pvm is used reliably is somewhat trickier
though, I think.