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

[Philippe Waroquiers]

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