* attach u/i oddity @ 2011-10-09 21:36 Doug Evans 2011-10-11 6:17 ` Joel Brobecker 0 siblings, 1 reply; 10+ messages in thread From: Doug Evans @ 2011-10-09 21:36 UTC (permalink / raw) To: gdb I know why this happens, but as a user it's not intuitive: if gdb could figure out the program (and arch) the first time, why can't it the second time? bash$ gdb (gdb) attach 1234 # a 32 bit program: forever.x32 (gdb) detach (gdb) attach 1235 # a 64 bit program: forever.x64 --> Attaching to program: /home/dje/src/play/forever.x32, process 31621 warning: Selected architecture i386 is not compatible with reported target architecture i386:x86-64 warning: Architecture rejected target-supplied description Reading symbols from /usr/grte/v2/lib/ld-linux.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/grte/v2/lib/ld-linux.so.2 0x46403fe0 in ?? () (gdb) The user never specified forever.x32 as the program to debug, gdb was being clever. However, if it's going to be clever the first time, it's a bug (from the user's perspective) to not be clever the second time too (IMO). Comments? ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: attach u/i oddity 2011-10-09 21:36 attach u/i oddity Doug Evans @ 2011-10-11 6:17 ` Joel Brobecker 2011-10-11 11:17 ` Pedro Alves 0 siblings, 1 reply; 10+ messages in thread From: Joel Brobecker @ 2011-10-11 6:17 UTC (permalink / raw) To: Doug Evans; +Cc: gdb > The user never specified forever.x32 as the program to debug, gdb was > being clever. However, if it's going to be clever the first time, > it's a bug (from the user's perspective) to not be clever the second > time too (IMO). I agree. I was surprised by the reported behavior. -- Joel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: attach u/i oddity 2011-10-11 6:17 ` Joel Brobecker @ 2011-10-11 11:17 ` Pedro Alves 2011-10-11 16:46 ` Doug Evans 2011-10-19 20:03 ` Tom Tromey 0 siblings, 2 replies; 10+ messages in thread From: Pedro Alves @ 2011-10-11 11:17 UTC (permalink / raw) To: gdb; +Cc: Joel Brobecker, Doug Evans On Tuesday 11 October 2011 07:16:36, Joel Brobecker wrote: > > The user never specified forever.x32 as the program to debug, gdb was > > being clever. However, if it's going to be clever the first time, > > it's a bug (from the user's perspective) to not be clever the second > > time too (IMO). > > I agree. I was surprised by the reported behavior. I can't see how to change that while both keeping it simple, and avoiding breaking valid use cases. Users need to be able to specify a different executable/file than what the OS reports the process is running, and "file FOO; attach PID" is the idiom GDB uses since forever for that. Maybe what we need a `warning' so that the surprise is gone: "warning: assuming process is running the loaded executable `FOO' which is different from the executable the target reports the process " is running. Unload it with the `file' command to make gdb find and load the target reported executable automatically." ( certainly needs copy/editing :-) ) Note this would be tricky to get right for remote targets. Also, not all targets can fetch the running executable on attach. -- Pedro Alves ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: attach u/i oddity 2011-10-11 11:17 ` Pedro Alves @ 2011-10-11 16:46 ` Doug Evans 2011-10-11 17:20 ` Pedro Alves 2011-10-19 20:03 ` Tom Tromey 1 sibling, 1 reply; 10+ messages in thread From: Doug Evans @ 2011-10-11 16:46 UTC (permalink / raw) To: Pedro Alves; +Cc: gdb, Joel Brobecker On Tue, Oct 11, 2011 at 4:17 AM, Pedro Alves <pedro@codesourcery.com> wrote: > On Tuesday 11 October 2011 07:16:36, Joel Brobecker wrote: >> > The user never specified forever.x32 as the program to debug, gdb was >> > being clever. However, if it's going to be clever the first time, >> > it's a bug (from the user's perspective) to not be clever the second >> > time too (IMO). >> >> I agree. I was surprised by the reported behavior. > > I can't see how to change that while both keeping it simple, and > avoiding breaking valid use cases. Users need to be able to specify a > different executable/file than what the OS reports the process is running, We don't need to make this case simple though. I'd be surprised if it was the more frequent case (or even close). Even if that case required several commands, as long as it was robustly scriptable that would be fine. We should be optimizing for the common case. > and "file FOO; attach PID" is the idiom GDB uses since forever for that. In this case the user explicitly specified the file. One way to go (though I'm not entirely happy with it) would be to continue to be clever as long as we didn't override what the user explicitly specified. > Maybe what we need a `warning' so that the surprise is gone: > > "warning: assuming process is running the loaded executable `FOO' > which is different from the executable the target reports the process " > is running. Unload it with the `file' command to make gdb find and load > the target reported executable automatically." A warning is needed, but it doesn't correct the broken default behaviour (IMO, YMMV). It's too bad we don't have a formal mechanism for deprecating and ultimately deleting broken command behaviour, API elements, etc. [I wonder how much pushback there would be to introducing one. I don't know if I'd ultimately want to incompatibly change GDB in this particular case, but I do know there are changes I've wanted to make that break compatibility.] The "file" command needs to do more to make this completely work btw. E.g., it needs to effect a reloading of thread_db (which would fix "gdb -c core, file foo" for the dynamic case). We could add an option to attach (attach -f PID, or whatever) that explicitly set the file, overriding what's currently in effect. > ( certainly needs copy/editing :-) ) > > Note this would be tricky to get right for remote targets. Also, > not all targets can fetch the running executable on attach. Sure, but that didn't stop making attach be clever in the first place. :-) ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: attach u/i oddity 2011-10-11 16:46 ` Doug Evans @ 2011-10-11 17:20 ` Pedro Alves 2011-10-11 18:11 ` Doug Evans 0 siblings, 1 reply; 10+ messages in thread From: Pedro Alves @ 2011-10-11 17:20 UTC (permalink / raw) To: Doug Evans; +Cc: gdb, Joel Brobecker On Tuesday 11 October 2011 17:46:36, Doug Evans wrote: > On Tue, Oct 11, 2011 at 4:17 AM, Pedro Alves <pedro@codesourcery.com> wrote: > > On Tuesday 11 October 2011 07:16:36, Joel Brobecker wrote: > >> > The user never specified forever.x32 as the program to debug, gdb was > >> > being clever. However, if it's going to be clever the first time, > >> > it's a bug (from the user's perspective) to not be clever the second > >> > time too (IMO). > >> > >> I agree. I was surprised by the reported behavior. > > > > I can't see how to change that while both keeping it simple, and > > avoiding breaking valid use cases. Users need to be able to specify a > > different executable/file than what the OS reports the process is running, > > We don't need to make this case simple though. > I'd be surprised if it was the more frequent case (or even close). Err. It's close. The "different executable" is usually the one with debug info, while the one deployed in the target/system is the one without debug info. > Even if that case required several commands, as long as it was > robustly scriptable that would be fine. I don't take it so lightly. This is quite old behavior. We should not break things unless there's very good reason. > We should be optimizing for the common case. Yadayada... :-) > > and "file FOO; attach PID" is the idiom GDB uses since forever for that. > > In this case the user explicitly specified the file. > One way to go (though I'm not entirely happy with it) would be to > continue to be clever as long as we didn't override what the user > explicitly specified. What I don't like about that, is that is adds state, that is likely to confuse users one way or another anyway. Sometimes we can't avoid it, but stateless things are easier to grok. Maybe GDB could print a note when it loaded the executable automatically? "Note: Hello, hello! This is GDB speaking. How are you? I've detected the file the process you're attaching to is running is /path/to/FOO, and that you hadn't told me which executable goes with that process. So I've hopefully helpfully asked the target backend which it was, and loaded it automatically for you. How cool is that, huh?!? Beware that I won't do this again until you unload the executable. Happy debugging! Yours, -- G.D.B." Might need copy editing too. :-) > The "file" command needs to do more to make this completely work btw. > E.g., it needs to effect a reloading of thread_db (which would fix > "gdb -c core, file foo" for the dynamic case). It's a bit unrelated, wouldn't you say? > We could add an option to attach (attach -f PID, or whatever) that > explicitly set the file, overriding what's currently in effect. That would work for me. But then again, if you know to do this, you can also do "file; attach" (or define myattach...). > > ( certainly needs copy/editing :-) ) > > > > Note this would be tricky to get right for remote targets. Also, > > not all targets can fetch the running executable on attach. > > Sure, but that didn't stop making attach be clever in the first place. :-) I can't imagine _not_ wanting it to be clever when I don't have a file loaded yet. -- Pedro Alves ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: attach u/i oddity 2011-10-11 17:20 ` Pedro Alves @ 2011-10-11 18:11 ` Doug Evans 2011-10-11 18:22 ` Pedro Alves 2011-10-11 18:56 ` Pedro Alves 0 siblings, 2 replies; 10+ messages in thread From: Doug Evans @ 2011-10-11 18:11 UTC (permalink / raw) To: Pedro Alves; +Cc: gdb, Joel Brobecker On Tue, Oct 11, 2011 at 10:20 AM, Pedro Alves <pedro@codesourcery.com> wrote: >> We don't need to make this case simple though. >> I'd be surprised if it was the more frequent case (or even close). > > Err. It's close. The "different executable" is usually the one > with debug info, while the one deployed in the target/system is the > one without debug info. > >> Even if that case required several commands, as long as it was >> robustly scriptable that would be fine. > > I don't take it so lightly. This is quite old behavior. We > should not break things unless there's very good reason. No disagreement here. I'm curious what motivated inferring I was taking it lightly. [I hate needing to be verbose just to avoid such things, it implies a community in need of some, umm, love. :-) But maybe better word choices would help.] >> We should be optimizing for the common case. > > Yadayada... :-) > >> > and "file FOO; attach PID" is the idiom GDB uses since forever for that. >> >> In this case the user explicitly specified the file. >> One way to go (though I'm not entirely happy with it) would be to >> continue to be clever as long as we didn't override what the user >> explicitly specified. > > What I don't like about that, is that is adds state, that is likely > to confuse users one way or another anyway. Yep. OTOH, I claim the current behaviour is already confusing. :-) > Sometimes we can't > avoid it, but stateless things are easier to grok. Yadayada ...? 1/2 :-) > Maybe GDB could > print a note when it loaded the executable automatically? > > "Note: Hello, hello! This is GDB speaking. How are you? > I've detected the file the process you're attaching to is running > is /path/to/FOO, and that you hadn't told me which executable goes > with that process. So I've hopefully helpfully asked the target > backend which it was, and loaded it automatically for you. How > cool is that, huh?!? Beware that I won't do this again until > you unload the executable. Happy debugging! > > Yours, > -- > G.D.B." > > Might need copy editing too. :-) > >> The "file" command needs to do more to make this completely work btw. >> E.g., it needs to effect a reloading of thread_db (which would fix >> "gdb -c core, file foo" for the dynamic case). > > It's a bit unrelated, wouldn't you say? Eh? I don't understand. >> We could add an option to attach (attach -f PID, or whatever) that >> explicitly set the file, overriding what's currently in effect. > > That would work for me. But then again, if you know to do this, > you can also do "file; attach" (or define myattach...). > >> > ( certainly needs copy/editing :-) ) >> > >> > Note this would be tricky to get right for remote targets. Also, >> > not all targets can fetch the running executable on attach. >> >> Sure, but that didn't stop making attach be clever in the first place. :-) > > I can't imagine _not_ wanting it to be clever when I don't > have a file loaded yet. I can't imagine not wanting the simple case of attach,detach,attach to Just Work. "But seriously ..." There was some cleverness that was wanted, was "tricky to get right right for remote targets. Also not all targets can fetch the running executable on attach", and yet was added anyway. Awesome. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: attach u/i oddity 2011-10-11 18:11 ` Doug Evans @ 2011-10-11 18:22 ` Pedro Alves 2011-10-11 18:56 ` Pedro Alves 1 sibling, 0 replies; 10+ messages in thread From: Pedro Alves @ 2011-10-11 18:22 UTC (permalink / raw) To: Doug Evans; +Cc: gdb, Joel Brobecker On Tuesday 11 October 2011 19:11:21, Doug Evans wrote: > There was some cleverness that was wanted, was "tricky to get right > right for remote targets. You misunderstood. I meant the new warning I had suggested in the same email I wrote that, the one where we'd check whether the loaded file is the same that the target is reporting the process is running is tricky on remote targets. -- Pedro Alves ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: attach u/i oddity 2011-10-11 18:11 ` Doug Evans 2011-10-11 18:22 ` Pedro Alves @ 2011-10-11 18:56 ` Pedro Alves 2011-10-11 22:38 ` Doug Evans 1 sibling, 1 reply; 10+ messages in thread From: Pedro Alves @ 2011-10-11 18:56 UTC (permalink / raw) To: Doug Evans; +Cc: gdb, Joel Brobecker On Tuesday 11 October 2011 19:11:21, Doug Evans wrote: > On Tue, Oct 11, 2011 at 10:20 AM, Pedro Alves <pedro@codesourcery.com> wrote: > >> We don't need to make this case simple though. > >> I'd be surprised if it was the more frequent case (or even close). > > > > Err. It's close. The "different executable" is usually the one > > with debug info, while the one deployed in the target/system is the > > one without debug info. > > > >> Even if that case required several commands, as long as it was > >> robustly scriptable that would be fine. > > > > I don't take it so lightly. This is quite old behavior. We > > should not break things unless there's very good reason. > > No disagreement here. > I'm curious what motivated inferring I was taking it lightly. Well, all the extra talk about deprecating and deleting commands. > >> > and "file FOO; attach PID" is the idiom GDB uses since forever for that. > >> > >> In this case the user explicitly specified the file. > >> One way to go (though I'm not entirely happy with it) would be to > >> continue to be clever as long as we didn't override what the user > >> explicitly specified. > > > > What I don't like about that, is that is adds state, that is likely > > to confuse users one way or another anyway. > > Yep. > OTOH, I claim the current behaviour is already confusing. :-) > > > Sometimes we can't > > avoid it, but stateless things are easier to grok. > > Yadayada ...? 1/2 :-) ;-) > >> The "file" command needs to do more to make this completely work btw. > >> E.g., it needs to effect a reloading of thread_db (which would fix > >> "gdb -c core, file foo" for the dynamic case). > > > > It's a bit unrelated, wouldn't you say? > > Eh? I don't understand. I don't understand what is "this" in "make this completely work" was then. I don't understand what file not having an effect on reloading of thread_db has to do with the case we're discussing. > >> We could add an option to attach (attach -f PID, or whatever) that > >> explicitly set the file, overriding what's currently in effect. > > > > That would work for me. But then again, if you know to do this, > > you can also do "file; attach" (or define myattach...). > > > >> > ( certainly needs copy/editing :-) ) > >> > > >> > Note this would be tricky to get right for remote targets. Also, > >> > not all targets can fetch the running executable on attach. > >> > >> Sure, but that didn't stop making attach be clever in the first place. :-) > > > > I can't imagine _not_ wanting it to be clever when I don't > > have a file loaded yet. > > I can't imagine not wanting the simple case of attach,detach,attach to > Just Work. Your definition of "Just Work" conflicts with other use cases where it Just Works... We need to compromise while avoiding breaking things. "attach -f" (or whatever the spelling) was one way. A bit more verbosity was another. Enhancing the documentation is yet another. And none of these is mutually exclusive. > "But seriously ..." > There was some cleverness that was wanted, was "tricky to get right > right for remote targets. Also not all targets can fetch the running > executable on attach", and yet was added anyway. Awesome. In addition to the misunderstanding I pointed out in the other email, there's tons of things that some targets can't do, yet that shouldn't block implementing the features in targets that can. It would also be reasonable to print something like "warning: no exec loaded, and can't infer exec from target" for targets where we can't get it from the target. -- Pedro Alves ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: attach u/i oddity 2011-10-11 18:56 ` Pedro Alves @ 2011-10-11 22:38 ` Doug Evans 0 siblings, 0 replies; 10+ messages in thread From: Doug Evans @ 2011-10-11 22:38 UTC (permalink / raw) To: Pedro Alves; +Cc: gdb, Joel Brobecker On Tue, Oct 11, 2011 at 11:56 AM, Pedro Alves <pedro@codesourcery.com> wrote: > On Tuesday 11 October 2011 19:11:21, Doug Evans wrote: >> On Tue, Oct 11, 2011 at 10:20 AM, Pedro Alves <pedro@codesourcery.com> wrote: >> >> We don't need to make this case simple though. >> >> I'd be surprised if it was the more frequent case (or even close). >> > >> > Err. It's close. The "different executable" is usually the one >> > with debug info, while the one deployed in the target/system is the >> > one without debug info. >> > >> >> Even if that case required several commands, as long as it was >> >> robustly scriptable that would be fine. >> > >> > I don't take it so lightly. This is quite old behavior. We >> > should not break things unless there's very good reason. >> >> No disagreement here. >> I'm curious what motivated inferring I was taking it lightly. > > Well, all the extra talk about deprecating and deleting commands. One should be free to talk about such things without having the listener insert things between the lines. It's a BIG step to go from simply talking about deprecating and deleting commands (*1) to taking them lightly. (*1): I actually said "ultimately deleting broken command behaviour", and by that I meant no longer supporting whatever it is that was deprecated. >> >> > and "file FOO; attach PID" is the idiom GDB uses since forever for that. >> >> >> >> In this case the user explicitly specified the file. >> >> One way to go (though I'm not entirely happy with it) would be to >> >> continue to be clever as long as we didn't override what the user >> >> explicitly specified. >> > >> > What I don't like about that, is that is adds state, that is likely >> > to confuse users one way or another anyway. >> >> Yep. >> OTOH, I claim the current behaviour is already confusing. :-) >> >> > Sometimes we can't >> > avoid it, but stateless things are easier to grok. >> >> Yadayada ...? 1/2 :-) > > ;-) > >> >> The "file" command needs to do more to make this completely work btw. >> >> E.g., it needs to effect a reloading of thread_db (which would fix >> >> "gdb -c core, file foo" for the dynamic case). >> > >> > It's a bit unrelated, wouldn't you say? >> >> Eh? I don't understand. > > I don't understand what is "this" in "make this completely work" > was then. "this" can be ambiguous. :-) > I don't understand what file not having an effect on > reloading of thread_db has to do with the case we're discussing. I was pointing out that file;attach is not (currently) equivalent to attach;file. i.e. it's not enough to do attach,detach,attach, find out that the second attach didn't work as expected, and then try to fix things up by then doing "file". If "file" is a legit thing to do after an attach, then ISTM we've still got work to do. E.g., ref: http://sourceware.org/ml/gdb-patches/2011-10/msg00182.html (gdb) file wrong_executable (gdb) attach PID or core-file core.1234 whooops! (gdb) file right_executable >> >> We could add an option to attach (attach -f PID, or whatever) that >> >> explicitly set the file, overriding what's currently in effect. >> > >> > That would work for me. But then again, if you know to do this, >> > you can also do "file; attach" (or define myattach...). >> > >> >> > ( certainly needs copy/editing :-) ) >> >> > >> >> > Note this would be tricky to get right for remote targets. Also, >> >> > not all targets can fetch the running executable on attach. >> >> >> >> Sure, but that didn't stop making attach be clever in the first place. :-) >> > >> > I can't imagine _not_ wanting it to be clever when I don't >> > have a file loaded yet. >> >> I can't imagine not wanting the simple case of attach,detach,attach to >> Just Work. > > Your definition of "Just Work" conflicts with other use cases where > it Just Works... We need to compromise while avoiding breaking > things. "attach -f" (or whatever the spelling) was one way. A bit > more verbosity was another. Enhancing the documentation is yet another. > And none of these is mutually exclusive. > >> "But seriously ..." >> There was some cleverness that was wanted, was "tricky to get right >> right for remote targets. Also not all targets can fetch the running >> executable on attach", and yet was added anyway. Awesome. > > In addition to the misunderstanding I pointed out in the other email, Like I said, "this" can be ambiguous ... > there's tons of things that some targets can't do, yet that shouldn't > block implementing the features in targets that can. Yep. > It would also be > reasonable to print something like "warning: no exec loaded, and can't > infer exec from target" for targets where we can't get it from the > target. "works for me" ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: attach u/i oddity 2011-10-11 11:17 ` Pedro Alves 2011-10-11 16:46 ` Doug Evans @ 2011-10-19 20:03 ` Tom Tromey 1 sibling, 0 replies; 10+ messages in thread From: Tom Tromey @ 2011-10-19 20:03 UTC (permalink / raw) To: Pedro Alves; +Cc: gdb, Joel Brobecker, Doug Evans Pedro> Maybe what we need a `warning' so that the surprise is gone: Pedro> "warning: assuming process is running the loaded executable `FOO' Pedro> which is different from the executable the target reports the process " Pedro> is running. Unload it with the `file' command to make gdb find and load Pedro> the target reported executable automatically." It seems like a decent idea to me. I wrote a patch to change the behavior here once: http://sourceware.org/ml/gdb-patches/2008-11/msg00279.html The ensuing thread points out the different use cases where people really want to do this. Tom ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2011-10-19 19:55 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-10-09 21:36 attach u/i oddity Doug Evans 2011-10-11 6:17 ` Joel Brobecker 2011-10-11 11:17 ` Pedro Alves 2011-10-11 16:46 ` Doug Evans 2011-10-11 17:20 ` Pedro Alves 2011-10-11 18:11 ` Doug Evans 2011-10-11 18:22 ` Pedro Alves 2011-10-11 18:56 ` Pedro Alves 2011-10-11 22:38 ` Doug Evans 2011-10-19 20:03 ` Tom Tromey
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).