Re: [PATCH 7/7] Reset Windows hardware breakpoints on executable's entry point

[Pedro Alves <pedro@palves.net>]

On 10/9/20 7:51 PM, Hannes Domani wrote:
>  Am Freitag, 9. Oktober 2020, 20:22:21 MESZ hat Pedro Alves <pedro@palves.net> Folgendes geschrieben:
> 
>> However, does the breakpoint go away when the inferior exits, though?
>> I'm wondering what happens when, say:
>>
>> #1 - you load a Windows binary in inferior 1.
>> #2 - you run the inferior, and it exits
>> #3 - you now load a non-Windows binary in inferior 1 (say, a GNU/Linux program)
>> #4 - you run inferior 1
>>
>> Don't we end up in startup_breakpoint_re_set in step #3 or #4?
>> If so, that calls get_windows_inferior_data() which a new
>> windows_info object, and then creates a location at address 0,
>> I presume.  All while the inferior isn't a Windows inferior.
>>
>> Or what if you load a Windows program in inferior 1, and a GNU/Linux
>> program in inferior 2?  Doesn't a similar problem happen?
> 
> You're probably right.
> I've never build a gdb which understands both Windows and Linux
> executables (I think), so I can't test it.

You just need to build gdb with --enable-targets=all

> 
> It looks like it keeps the breakpoint on the same location as the last
> Windows executable.
> 
> What would you suggest how to fix this?

I think you need to add some checks for "is this a Windows inferior".

Maybe with something like:

static bool
is_windows_inferior (inferior *inf)
{
  switch (gdbarch_osabi (inf->gdbarch))
    {
    case GDB_OSABI_CYGWIN:
    case GDB_OSABI_WINDOW:
      return true;
    }
  return false;
}

In startup_breakpoint_re_set, don't create locations if the
inferior isn't a Windows inferior.

Then in your gdb::observers::inferior_exit observer, delete the
breakpoint locations for the exiting inferior.

I still suspect that having a breakpoint per inferior/pspace,
and a keeping a pointer to it in the per-inf/pspace structure (you
can get at the current entry point address from the breakpoint's
first location's address instead of a separate field for the
entry point address), instead of a single breakpoint with multiple
locations would simplify things.  But if you want to keep your
current approach, that's fine with me.