public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Philippe Waroquiers <philippe.waroquiers@skynet.be>
To: "Metzger, Markus T" <markus.t.metzger@intel.com>,
	GDB <gdb@sourceware.org>
Subject: Re: exec-file-mismatch and native-gdbserver testing
Date: Wed, 08 Apr 2020 22:54:18 +0200	[thread overview]
Message-ID: <b34454e9eb9cb89534fd103a74525dd5465c0e6e.camel@skynet.be> (raw)
In-Reply-To: <SN6PR11MB33449A275062A414644B7E4DDEC00@SN6PR11MB3344.namprd11.prod.outlook.com>

On Wed, 2020-04-08 at 14:02 +0000, Metzger, Markus T via Gdb wrote:
> Hello,
> 
> I noticed an issue when running tests that use standard_temp_file with the native-gdbserver board.
> 
> In gdb_remote_download, when called without tofile argument, as it is, for example, when starting gdbserver via gdb_reload, we set the filename to standard_output_file [file tail $fromfile] and copy the file.
> 
> GDB and gdbserver now use a copy of the same file at different locations.
> 
> This triggers an exec-file-mismatch warning and, with the default “ask” setting, a user prompt that isn’t handled by the tests and eventually leads to a timeout.  This can be seen with all tests that use gdb_simple_compile, e.g. via skip_*_test calls.  An example would be gdb.btrace/*.exp.
> 
> In exec.c:validate_exec_file (), we check the filenames and, if they differ, print a warning and re-load the symbol file.
> 
> Should validate_exec_file () check more than just the filenames?
You mean: if the filenames differs, gdb could compare the contents of files and if equal,
not ask the question, considering there is no mismatch ?

> Should gdb_simple_compile use standard_output_file instead of standard_temp_file?

Alternatively, set the value of exec-file-mismatch to warn ?
The reason of this setting is to allow to disable this exec-file-mismatch
logic in case of "unusual" setup, and the above seems to qualify as an unusual setup.
During review, some argued that we might hardcode 'ask' (or even not ask, just
automatically reload). It looks like the setting might have its usefulness :).

Note that on this exec-file-mismatch functionality, we still have PR
https://sourceware.org/bugzilla/show_bug.cgi?id=25475
waiting for (some) feedback about the way to fix/improve

(this PR should better be fixed before the next release, as afterwards,
CLI behaviour is much more difficult to change).

Thanks

Philippe




  reply	other threads:[~2020-04-08 20:54 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-08 14:02 Metzger, Markus T
2020-04-08 20:54 ` Philippe Waroquiers [this message]
2020-04-09  6:30   ` Metzger, Markus T
2020-05-08 10:30     ` Metzger, Markus T
2020-05-08 21:25       ` Philippe Waroquiers
2020-05-16 20:10 ` Pedro Alves
2020-05-17  5:24   ` Philippe Waroquiers
2020-05-17 17:47     ` Pedro Alves
2020-05-17 18:15       ` Philippe Waroquiers
2020-05-17 19:50         ` Pedro Alves
2020-05-17 20:11           ` Philippe Waroquiers
2020-05-17 21:19             ` Pedro Alves
2020-05-17 21:43               ` Philippe Waroquiers
2020-05-17 21:58                 ` Pedro Alves
2020-05-18 10:35                   ` Philippe Waroquiers
2020-05-18 14:05                     ` Pedro Alves

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b34454e9eb9cb89534fd103a74525dd5465c0e6e.camel@skynet.be \
    --to=philippe.waroquiers@skynet.be \
    --cc=gdb@sourceware.org \
    --cc=markus.t.metzger@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).