This is the mail archive of the gdb-patches@sourceware.org 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: [RFC] Have an option to tell GDB to detect and possibly handle mismatched exec-files.


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




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