This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFA: attach to a PID using a different exec

>>>>> "Andreas" == Andreas Schwab <> writes:

Daniel> I don't want GDB to prompt my to switch to the stripped
Daniel> program...

Andreas> I think a warning would still be helpful, similar to what you
Andreas> get when you load a core that does not match.

I did consider a warning.

My patch was tailored to my use case, where basically I made an early
mistake in selecting the exec file.  Suppose in this situation that
gdb warns about the non-matching exec.  After that, gdb is left in an
un-useful state, and furthermore the user has to resort to
cut-and-paste (or a lot of typing) to get back to the exec file that
gdb already knows.  That seems unfriendly.

I did not think of either Daniel's or Joel's use cases.

I would classify Daniel's as advanced usage -- but again, perhaps
tinged by my experience.  That is, I have never once done what he
describes, but then I almost always have separate debug info available
for those few stripped programs I must debug.

Joel's is an interesting case of making the "opposite" mistake
(starting the wrong program), but I think it doesn't really have an
effect on the outcome of this discussion (either thing gdb does will
yield the right answer when he restarts the inferior and reattaches).

Another oddity in this area, btw, is that at least the linux native
target gives a funny report if the attached process' exec file has
been deleted.

I don't like to add new options, in general, but I would add one for
this case if that would help.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]