PING Re: [RFC] Have an option to tell GDB to detect and possibly handle mismatched exec-files.

[Philippe Waroquiers <philippe.waroquiers@skynet.be>]

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
> 
> 
>