[RFA] Fixes PR 25475: ensure exec-file-mismatch "ask" always asks in case of mismatch.

[Pedro Alves]

On 6/23/20 9:23 PM, Philippe Waroquiers via Gdb-patches wrote:
> On Mon, 2020-06-22 at 11:57 +0100, Pedro Alves wrote:

>>
>> This seems fine to me.
> Is this ok to push (with the ALWAYS_CONFIRM uppercased) ?

OK.

> 
> ...
>> So, I'm not sure it's worth it to have separate settings for
>> exec-file and symbol-file:
>>
>>   set exec-file-mismatch
>>   set symbol-file-mismatch
> If we would implement a symfile build-id check, what would be
> the check ?  Unclear how to
> determine a symfile
> from the process we are attaching to.  So, would this check 
> be a
> comparison between the exec-file build-id and the symfile
> build-id ?  

Same as exec-file detection, we can compare the build IDs of the
executable that the target process is running (or was running, in
case of cores), and the build ID of the symbols file loaded
in GDB.

> And if we detect a
> mismatch for symfile, again unclear
> which file we would be able to find/load automatically.

We could use debuginfod to try loading the symbol file automatically,
for example.

> So, maybe we could/should just give a warning whenever an exec-file
> build-id does not match
> a symfile build-id, in whatever context ?

That sounds desirable, yes.  validate_files() in corefile.c does that
already, but only for core file vs exec file.  Speaking of which, 
validate_exec_files currently doesn't consider cores.  And
validate_files only warns -- if we teach it to load files
from debuginfod, then it could ask too.  Kind of feels like these
functions and their UI could be merged somehow.  Anyway, doesn't have
to be now.

> 
>>
>> But it does look to me that we should do separate build ID
>> validations for the exec-file and the symbol-file.
>>
>> And with that in mind (symbol-file validation + reload symbol-file),
>> perhaps we should consider whether "set exec-file-mismatch" is the right
>> name for this setting, or whether we should rename it to e.g.,
>> "set file-mismatch", to go with the "file" command instead of
>> the "exec-file" command.
> I am wondering.  As far as I understand, we detect a mismatch for
> the exec-file only.  If the exec-file is still ok, but the symbol file
> would not, then the current code does not detect anything.
> So, it looks to me that the current name corresponds to what is detected.

True.

> 
> So, maybe it is good enough to do what you suggest below, i.e.
> clarify in the help the action that GDB does for "ask", i.e.
> that it reload the exec file and its debug info ?
> 

The point is, what happens when add detection of symbol file
mismatches as well.  Imagine we've already implemented that.
If we have that detection too, does the current command name
make sense?  I'm not sure.

Maybe it's not a big deal, and we can always add an alias later
if/when we decide to extend its scope later.

> If that sounds the best, I can prepare a patch for that,
> together with introducing the word "build-id" in the help text
> and in the warn/ask message produced when a mismatch is detected.

Thanks.  If we stick with the current name and behavior, then
I think that the documentation and online help bits are the most
important.  We can add the extra symbol vs exec warning later, for
example.

>> At least, the documentation and online help should clearly state
>> that the symbols are reloaded as well, not just the "exec-file".

Thanks,
Pedro Alves