Message ID | 20190318225822.4820-1-philippe.waroquiers@skynet.be |
---|---|
State | New |
Headers | show |
>>>>> "Philippe" == Philippe Waroquiers <philippe.waroquiers@skynet.be> writes:
Philippe> A recurrent problem with GDB is that GDB uses the wrong exec-file
Philippe> when using the attach/detach commands sucessfully.
Philippe> Also, in case the user specifies a file on the command line but attaches
Philippe> to the wrong PID, this error is not made visible and gives a not user
Philippe> understandable behaviour.
I've been bitten any number of times by this. So, it would be great to
have this fixed.
Philippe> There was a previous trial to fix this PR.
Philippe> See https://sourceware.org/ml/gdb-patches/2015-07/msg00118.html
Philippe> This trial was however only fixing the problem for the automatically
Philippe> determined executable files when doing attach.
There was also this series:
https://sourceware.org/ml/gdb-patches/2014-03/msg00476.html
... which seemingly went through at least 4 rounds of review and then
did not land for some reason.
Before approving anything I would like to understand why neither of
these earlier attempts went in.
The build-id approach is appealing because (especially since the demise
of prelink) it seems that gdb could simply trust it and abandon
non-matching symbol files, without needing a "user supplied" bit.
Tom
On Tue, 2019-03-19 at 10:43 -0600, Tom Tromey wrote: > > > > > > "Philippe" == Philippe Waroquiers <philippe.waroquiers@skynet.be> writes: > > Philippe> A recurrent problem with GDB is that GDB uses the wrong exec-file > Philippe> when using the attach/detach commands sucessfully. > Philippe> Also, in case the user specifies a file on the command line but attaches > Philippe> to the wrong PID, this error is not made visible and gives a not user > Philippe> understandable behaviour. > > I've been bitten any number of times by this. So, it would be great to > have this fixed. > > Philippe> There was a previous trial to fix this PR. > Philippe> See https://sourceware.org/ml/gdb-patches/2015-07/msg00118.html > Philippe> This trial was however only fixing the problem for the automatically > Philippe> determined executable files when doing attach. I have re-read all the exchanges for the above fix trial. It ended up with the above msg00118 with Pedro asking 'WDYT?', and it looks like everybody was thinking nothing. So, after more than 4 years, here is some feedback :). IMO, the distinction between auto-discovered and user-specified is artificial: if the user will debug a PID with what looks like a wrong executable specified by the user, GDB should not silently use the user provided file, as keeping it is very probably wrong (at least in the cases I have seen, it was always me doing an error, and the patch below will make the error visible and easy to fix) : The patch proposed below will indicate that there is very probably something weird, and then the user can change the setting and/or decide to not load the exec file discovered from the PID. Also, the patch above makes GDB unconditionally switch of exec file for auto-discovered files. If ever the user really want to do something 'unusual', no way. Again, the patch below allows the user to control the behaviour if really something unusual is desired/needed. > > There was also this series: > > https://sourceware.org/ml/gdb-patches/2014-03/msg00476.html > > ... which seemingly went through at least 4 rounds of review and then > did not land for some reason. After digging in the mail archive, it looks like the last state of this mail thread was the v5 done by Jan Kratochvil. I found no reaction to this v5. No idea why it stalled. That being said, I think that this last series does something different. IIUC, this patch series ensures that when GDB receives the pathname of a file to use (typically from a gdbserver), that GDB will use the build-id to decide to *not* load the debug info, but this does not lead to 'switch' to another correct exec-file. In other words, this v5 ensures that GDB does not load wrong debug info for a file GDB has decided to use as exec-file (or library). It does not detect or report that a wrong file is selected for a PID. In that sense, the patch proposed below is not contradictory with this last patch v5: once GDB has decided to use a certain exec-file, GDB today checks e.g. that the file has not changed of time stamp (otherwise it re-reads the file). As I understand, the build-id is just a more sophisticated way to detect if the file loaded by the PID is consistent with either the reported file to use by GDB and/or with the separate debug info GDB finds on the host side. > > Before approving anything I would like to understand why neither of > these earlier attempts went in. > > The build-id approach is appealing because (especially since the demise > of prelink) it seems that gdb could simply trust it and abandon > non-matching symbol files, without needing a "user supplied" bit. In summary, I think that the patch below is another approach than the 'sticky user executable' concept, but does not aim at solving the problem of an exec-file or a remote exec-file inconsistent with some GDB host debug info. Philippe
Pedro/Jan, Some feedback ? Thanks Philippe On Wed, 2019-03-20 at 19:34 +0100, Philippe Waroquiers wrote: > On Tue, 2019-03-19 at 10:43 -0600, Tom Tromey wrote: > > > > > > > "Philippe" == Philippe Waroquiers <philippe.waroquiers@skynet.be> writes: > > > > Philippe> A recurrent problem with GDB is that GDB uses the wrong exec-file > > Philippe> when using the attach/detach commands sucessfully. > > Philippe> Also, in case the user specifies a file on the command line but attaches > > Philippe> to the wrong PID, this error is not made visible and gives a not user > > Philippe> understandable behaviour. > > > > I've been bitten any number of times by this. So, it would be great to > > have this fixed. > > > > Philippe> There was a previous trial to fix this PR. > > Philippe> See https://sourceware.org/ml/gdb-patches/2015-07/msg00118.html > > Philippe> This trial was however only fixing the problem for the automatically > > Philippe> determined executable files when doing attach. > > I have re-read all the exchanges for the above fix trial. > It ended up with the above msg00118 with Pedro asking 'WDYT?', > and it looks like everybody was thinking nothing. > So, after more than 4 years, here is some feedback :). > > IMO, the distinction between auto-discovered and user-specified > is artificial: if the user will debug a PID with what looks like a > wrong executable specified by the user, GDB should not silently > use the user provided file, as keeping it is very probably > wrong (at least in the cases I have seen, it was always me > doing an error, and the patch below will make the error visible > and easy to fix) : > The patch proposed below will indicate that there is very probably > something weird, and then the user can change the setting and/or > decide to not load the exec file discovered from the PID. > > Also, the patch above makes GDB unconditionally switch of exec file > for auto-discovered > files. > If ever the user really want to do something 'unusual', no way. > Again, the patch > below allows the user to control the behaviour > if really something unusual is > desired/needed. > > > > > There was also this series: > > > > https://sourceware.org/ml/gdb-patches/2014-03/msg00476.html > > > > ... which seemingly went through at least 4 rounds of review and then > > did not land for some reason. > > After digging in the mail archive, it looks like the last state > of this mail thread was the v5 done by Jan Kratochvil. > I found no reaction to this v5. No idea why it stalled. > > That being said, I think that this last series does something different. > IIUC, this patch series ensures that when GDB receives the pathname > of a file to use (typically from a gdbserver), that GDB will use the > build-id to decide to *not* load the debug info, but this does not > lead to 'switch' to another correct exec-file. > > In other words, this v5 ensures that GDB does not load wrong > debug info for a file GDB has decided to use as exec-file (or library). > It does not detect or report that a wrong file is selected for a PID. > > In that sense, the patch proposed below is not contradictory with this > last patch v5: once GDB has decided to use a certain exec-file, > GDB today checks e.g. that the file has not changed of time stamp > (otherwise it re-reads the file). As I understand, the build-id is just > a more sophisticated way to detect if the file loaded by the PID > is consistent with either the reported file to use by GDB and/or with > the separate debug info GDB finds on the host side. > > > > > Before approving anything I would like to understand why neither of > > these earlier attempts went in. > > > > The build-id approach is appealing because (especially since the demise > > of prelink) it seems that gdb could simply trust it and abandon > > non-matching symbol files, without needing a "user supplied" bit. > > In summary, I think that the patch below is another approach > than the 'sticky user executable' concept, but does not aim at > solving the problem of an exec-file or a remote exec-file > inconsistent with some GDB host debug info. > > > Philippe > > >
Some feedback ? (or should I just go on, finish the work to submit an RFA?) Thanks Philippe NB: Jan told me this was a long time ago, and could not give much comments, as he is not working on GDB anymore. On Wed, 2019-04-03 at 22:24 +0200, Philippe Waroquiers wrote: > Pedro/Jan, > Some feedback ? > > Thanks > > Philippe > > > On Wed, 2019-03-20 at 19:34 +0100, Philippe Waroquiers wrote: > > On Tue, 2019-03-19 at 10:43 -0600, Tom Tromey wrote: > > > > > > > > "Philippe" == Philippe Waroquiers <philippe.waroquiers@skynet.be> writes: > > > > > > Philippe> A recurrent problem with GDB is that GDB uses the wrong exec-file > > > Philippe> when using the attach/detach commands sucessfully. > > > Philippe> Also, in case the user specifies a file on the command line but attaches > > > Philippe> to the wrong PID, this error is not made visible and gives a not user > > > Philippe> understandable behaviour. > > > > > > I've been bitten any number of times by this. So, it would be great to > > > have this fixed. > > > > > > Philippe> There was a previous trial to fix this PR. > > > Philippe> See https://sourceware.org/ml/gdb-patches/2015-07/msg00118.html > > > Philippe> This trial was however only fixing the problem for the automatically > > > Philippe> determined executable files when doing attach. > > > > I have re-read all the exchanges for the above fix trial. > > It ended up with the above msg00118 with Pedro asking 'WDYT?', > > and it looks like everybody was thinking nothing. > > So, after more than 4 years, here is some feedback :). > > > > IMO, the distinction between auto-discovered and user-specified > > is artificial: if the user will debug a PID with what looks like a > > wrong executable specified by the user, GDB should not silently > > use the user provided file, as keeping it is very probably > > wrong (at least in the cases I have seen, it was always me > > doing an error, and the patch below will make the error visible > > and easy to fix) : > > The patch proposed below will indicate that there is very probably > > something weird, and then the user can change the setting and/or > > decide to not load the exec file discovered from the PID. > > > > Also, the patch above makes GDB unconditionally switch of exec file > > for auto-discovered > > files. > > If ever the user really want to do something 'unusual', no way. > > Again, the patch > > below allows the user to control the behaviour > > if really something unusual is > > desired/needed. > > > > > > > > There was also this series: > > > > > > https://sourceware.org/ml/gdb-patches/2014-03/msg00476.html > > > > > > ... which seemingly went through at least 4 rounds of review and then > > > did not land for some reason. > > > > After digging in the mail archive, it looks like the last state > > of this mail thread was the v5 done by Jan Kratochvil. > > I found no reaction to this v5. No idea why it stalled. > > > > That being said, I think that this last series does something different. > > IIUC, this patch series ensures that when GDB receives the pathname > > of a file to use (typically from a gdbserver), that GDB will use the > > build-id to decide to *not* load the debug info, but this does not > > lead to 'switch' to another correct exec-file. > > > > In other words, this v5 ensures that GDB does not load wrong > > debug info for a file GDB has decided to use as exec-file (or library). > > It does not detect or report that a wrong file is selected for a PID. > > > > In that sense, the patch proposed below is not contradictory with this > > last patch v5: once GDB has decided to use a certain exec-file, > > GDB today checks e.g. that the file has not changed of time stamp > > (otherwise it re-reads the file). As I understand, the build-id is just > > a more sophisticated way to detect if the file loaded by the PID > > is consistent with either the reported file to use by GDB and/or with > > the separate debug info GDB finds on the host side. > > > > > > > > Before approving anything I would like to understand why neither of > > > these earlier attempts went in. > > > > > > The build-id approach is appealing because (especially since the demise > > > of prelink) it seems that gdb could simply trust it and abandon > > > non-matching symbol files, without needing a "user supplied" bit. > > > > In summary, I think that the patch below is another approach > > than the 'sticky user executable' concept, but does not aim at > > solving the problem of an exec-file or a remote exec-file > > inconsistent with some GDB host debug info. > > > > > > Philippe > > > > > >
On 4/10/19 1:09 PM, Philippe Waroquiers wrote: > Some feedback ? > (or should I just go on, finish the work to submit an RFA?) > Thanks > Philippe > > NB: Jan told me this was a long time ago, and could not give > much comments, as he is not working on GDB anymore. > > On Wed, 2019-04-03 at 22:24 +0200, Philippe Waroquiers wrote: >> Pedro/Jan, >> Some feedback ? >> Sorry, it was on my list to reply back, but I wanted to dig in to the archives first, because I don't really recall what happened to the previous work. Looks like there's a lot to digest, so I'll need some time. Thanks, Pedro Alves
Ping ? Thanks Philippe On Wed, 2019-04-10 at 13:18 +0100, Pedro Alves wrote: > On 4/10/19 1:09 PM, Philippe Waroquiers wrote: > > Some feedback ? > > (or should I just go on, finish the work to submit an RFA?) > > Thanks > > Philippe > > > > NB: Jan told me this was a long time ago, and could not give > > much comments, as he is not working on GDB anymore. > > > > On Wed, 2019-04-03 at 22:24 +0200, Philippe Waroquiers wrote: > > > Pedro/Jan, > > > Some feedback ? > > > > > Sorry, it was on my list to reply back, but I wanted to dig in > to the archives first, because I don't really recall what happened > to the previous work. Looks like there's a lot to digest, so > I'll need some time. > > Thanks, > Pedro Alves
Thanks Philippe On Wed, 2019-04-10 at 13:18 +0100, Pedro Alves wrote: > On 4/10/19 1:09 PM, Philippe Waroquiers wrote: > > Some feedback ? > > (or should I just go on, finish the work to submit an RFA?) > > Thanks > > Philippe > > > > NB: Jan told me this was a long time ago, and could not give > > much comments, as he is not working on GDB anymore. > > > > On Wed, 2019-04-03 at 22:24 +0200, Philippe Waroquiers wrote: > > > Pedro/Jan, > > > Some feedback ? > > > > > Sorry, it was on my list to reply back, but I wanted to dig in > to the archives first, because I don't really recall what happened > to the previous work. Looks like there's a lot to digest, so > I'll need some time. > > Thanks, > Pedro Alves
Ping. Thanks Philippe On Wed, 2019-08-07 at 21:43 +0200, Philippe Waroquiers wrote: > Thanks > Philippe > > On Wed, 2019-04-10 at 13:18 +0100, Pedro Alves wrote: > > On 4/10/19 1:09 PM, Philippe Waroquiers wrote: > > > Some feedback ? > > > (or should I just go on, finish the work to submit an RFA?) > > > Thanks > > > Philippe > > > > > > NB: Jan told me this was a long time ago, and could not give > > > much comments, as he is not working on GDB anymore. > > > > > > On Wed, 2019-04-03 at 22:24 +0200, Philippe Waroquiers wrote: > > > > Pedro/Jan, > > > > Some feedback ? > > > > > > > > Sorry, it was on my list to reply back, but I wanted to dig in > > to the archives first, because I don't really recall what happened > > to the previous work. Looks like there's a lot to digest, so > > I'll need some time. > > > > Thanks, > > Pedro Alves
Ping. Thanks Philippe On Wed, 2019-04-10 at 13:18 +0100, Pedro Alves wrote: > On 4/10/19 1:09 PM, Philippe Waroquiers wrote: > > Some feedback ? > > (or should I just go on, finish the work to submit an RFA?) > > Thanks > > Philippe > > > > NB: Jan told me this was a long time ago, and could not give > > much comments, as he is not working on GDB anymore. > > > > On Wed, 2019-04-03 at 22:24 +0200, Philippe Waroquiers wrote: > > > Pedro/Jan, > > > Some feedback ? > > > > > Sorry, it was on my list to reply back, but I wanted to dig in > to the archives first, because I don't really recall what happened > to the previous work. Looks like there's a lot to digest, so > I'll need some time. > > Thanks, > Pedro Alves
Some feedback ? Thanks Philippe On Wed, 2019-04-10 at 13:18 +0100, Pedro Alves wrote: > On 4/10/19 1:09 PM, Philippe Waroquiers wrote: > > Some feedback ? > > (or should I just go on, finish the work to submit an RFA?) > > Thanks > > Philippe > > > > NB: Jan told me this was a long time ago, and could not give > > much comments, as he is not working on GDB anymore. > > > > On Wed, 2019-04-03 at 22:24 +0200, Philippe Waroquiers wrote: > > > Pedro/Jan, > > > Some feedback ? > > > > > Sorry, it was on my list to reply back, but I wanted to dig in > to the archives first, because I don't really recall what happened > to the previous work. Looks like there's a lot to digest, so > I'll need some time. > > Thanks, > Pedro Alves
diff --git a/gdb/exec.c b/gdb/exec.c index 77bd140a8e..054753d793 100644 --- a/gdb/exec.c +++ b/gdb/exec.c @@ -82,6 +82,49 @@ struct exec_target final : public target_ops static exec_target exec_ops; +/* How to handle a mismatch between the current exec file and the exec + file determined from target. */ + +static const char *const exec_file_mismatch_names[] + = {"reload", "warn", "off", NULL }; +enum exec_file_mismatch_mode + { + exec_file_mismatch_reload, exec_file_mismatch_warn, exec_file_mismatch_off + }; +static const char *exec_file_mismatch = exec_file_mismatch_names[0]; +enum exec_file_mismatch_mode exec_file_mismatch_mode = exec_file_mismatch_reload; + +/* Show command. */ +static void +show_exec_file_mismatch_command (struct ui_file *file, int from_tty, + struct cmd_list_element *c, const char *value) +{ + fprintf_filtered (gdb_stdout, + _("exec-file-mismatch handling is currently \"%s\".\n"), + exec_file_mismatch_names[exec_file_mismatch_mode]); +} + +/* Set command. Change the setting for range checking. */ +static void +set_exec_file_mismatch_command (const char *ignore, + int from_tty, struct cmd_list_element *c) +{ + for (enum exec_file_mismatch_mode mode = exec_file_mismatch_reload; + ; + mode = static_cast<enum exec_file_mismatch_mode>(1 + (int) mode)) + { + if (strcmp (exec_file_mismatch, exec_file_mismatch_names[mode]) == 0) + { + exec_file_mismatch_mode = mode; + return; + } + if (mode == exec_file_mismatch_off) + internal_error (__FILE__, __LINE__, + _("Unrecognized exec-file-mismatch setting: \"%s\""), + exec_file_mismatch); + } +} + /* Whether to open exec and core files read-only or read-write. */ int write_files = 0; @@ -201,6 +244,56 @@ try_open_exec_file (const char *exec_file_host, struct inferior *inf, /* See gdbcore.h. */ +void +validate_exec_file (int from_tty) +{ + if (exec_file_mismatch_mode == exec_file_mismatch_off) + return; /* User asked to do nothing. */ + + char *current_exec_file = get_exec_file (0); + struct inferior *inf = current_inferior (); + /* Try to determine a filename from the process itself. */ + char *pid_exec_file = target_pid_to_exec_file (inf->pid); + + if (current_exec_file == NULL || pid_exec_file == NULL) + return; /* We cannot validate the exec file. */ + + std::string exec_file_target (pid_exec_file); + + /* In case the exec file is not local, exec_file_target has to point at + the target file system. */ + if (is_target_filename (current_exec_file) && !target_filesystem_is_local ()) + exec_file_target = TARGET_SYSROOT_PREFIX + exec_file_target; + + if (strcmp (exec_file_target.c_str (), current_exec_file) != 0) + { + warning (_("Mismatch between current exec-file %s\n" + "and automatically determined exec-file %s\n" + "exec-file-mismatch handling is currently \"%s\""), + current_exec_file, exec_file_target.c_str (), + exec_file_mismatch_names[exec_file_mismatch_mode]); + if (exec_file_mismatch_mode == exec_file_mismatch_reload) + { + symfile_add_flags add_flags = SYMFILE_MAINLINE; + if (from_tty) + add_flags |= SYMFILE_VERBOSE; + TRY + { + symbol_file_add_main (exec_file_target.c_str (), add_flags); + exec_file_attach (exec_file_target.c_str (), from_tty); + } + CATCH (err, RETURN_MASK_ERROR) + { + warning (_("reloading %s %s"), exec_file_target.c_str (), + err.message != NULL ? err.message : "error"); + } + END_CATCH + } + } +} + +/* See gdbcore.h. */ + void exec_file_locate_attach (int pid, int defer_bp_reset, int from_tty) { @@ -1084,5 +1177,16 @@ Show writing into executable and core files."), NULL, show_write_files, &setlist, &showlist); + add_setshow_enum_cmd ("exec-file-mismatch", class_support, + exec_file_mismatch_names, + &exec_file_mismatch, + _("\ +Set exec-file-mismatch handling. (reload/warn/off)"), + _("\ +Show exec-file-mismatch handling. (reload/warn/off"), + NULL, set_exec_file_mismatch_command, + show_exec_file_mismatch_command, + &setlist, &showlist); + add_target (exec_target_info, exec_target_open, filename_completer); } diff --git a/gdb/gdbcore.h b/gdb/gdbcore.h index 6f9b4d88ec..611a389e22 100644 --- a/gdb/gdbcore.h +++ b/gdb/gdbcore.h @@ -157,6 +157,11 @@ extern void exec_file_locate_attach (int pid, int defer_bp_reset, int from_tty); extern void validate_files (void); +/* Produce a warning if the current exec file does not match the exec + file determined from the target. In case of mismatch, ask the user + if the exec file determined from target must be loaded. */ +extern void validate_exec_file (int from_tty); + /* The current default bfd target. */ extern char *gnutarget; diff --git a/gdb/infcmd.c b/gdb/infcmd.c index c5977c48a9..5812827ae5 100644 --- a/gdb/infcmd.c +++ b/gdb/infcmd.c @@ -2560,6 +2560,9 @@ setup_inferior (int from_tty) reread_symbols (); } + /* Check for exec file mismatch, and let the user solve it. */ + validate_exec_file (from_tty); + /* Take any necessary post-attaching actions for this platform. */ target_post_attach (inferior_ptid.pid ()); diff --git a/gdb/remote.c b/gdb/remote.c index 657a4a25ca..c0c80ee140 100644 --- a/gdb/remote.c +++ b/gdb/remote.c @@ -2392,6 +2392,9 @@ remote_target::remote_add_inferior (int fake_pid_p, int pid, int attached, if (try_open_exec && get_exec_file (0) == NULL) exec_file_locate_attach (pid, 0, 1); + /* Check for exec file mismatch, and let the user solve it. */ + validate_exec_file (1); + return inf; }