Bug 30825 - GDB doesn't send Hg packet when switching the inferiors
Summary: GDB doesn't send Hg packet when switching the inferiors
Status: UNCONFIRMED
Alias: None
Product: gdb
Classification: Unclassified
Component: gdb (show other bugs)
Version: 12.1
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-09-05 10:54 UTC by Palla, Rajesh
Modified: 2023-09-06 16:38 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
log file (481 bytes, text/plain)
2023-09-06 04:31 UTC, Palla, Rajesh
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Palla, Rajesh 2023-09-05 10:54:34 UTC
When we switch the inferiors using infe command, I am expecting GDB to send Hg Packet to the remote stub so that the remote stub can work on the selected inferior.

But GDB isn't sending the Hg packet every time. 
In a scenario where I have two inferiors, if I switch the inferiors without doing any operation, I don't see Hg Packet after first time

infe 1
infe 2 
infe 1
infe 2

Output log:
GDB -> $Hgp1.1#af
GDB <- $OK#9a
GDB -> $g#67
GDB <- $0000000000e0030000.....#49


Is it expected to invalidate the pc register from regcache in <arch>_unwind_pc(). Because if I do so, it works but that will add more latency when we give step command etc..(it sends more g packets)

Any solution?
Comment 1 Tom Tromey 2023-09-05 15:41:31 UTC
remote.c lazily sends Hg.  Simply switching inferiors isn't enough
to trigger this; instead the user has to do some operation that
requires the remote to know about the switch.

I am not completely sure but I think in general the unwind methods
should not be invalidating the regcache.  IIUC this is the job
of higher levels.

Maybe you could say what target this is and/or show your pc-unwind
function.

The other ones in the tree don't seem to do this.
Comment 2 Palla, Rajesh 2023-09-06 04:29:59 UTC
This is the new target we added for AMD cores.
pc_unwind function is similar to default pc_unwind() except that it invalidates the cache when there is a change in the inferior.

static CORE_ADDR aiengine_unwind_pc (struct gdbarch *gdbarch, struct frame_info *next_frame)
{
  gdb_byte buf[4];
  struct inferior *inf = current_inferior ();
  if (inf->pid != prev_pid){
    prev_pid = inf->pid;
    get_current_regcache()->invalidate(gdbarch_pc_regnum (gdbarch));
  }
  frame_unwind_register (next_frame, gdbarch_pc_regnum (gdbarch), buf);
  return extract_typed_address (buf, builtin_type (gdbarch)->builtin_func_ptr);
}


Couple of questions:
1. When I tried to debug "arm arch", I see the Hg packets are sent every time we switch the inferior without doing any operation. (see log.txt attached)
2. In our case, I don't see Hg packet being sent lazily when we give 'c&' command. See the below log. But for other commands like mem read, I see Hg packet being sent.

----(gdb) infe 1
GDB -> $Hgp1.1#af
GDB <- $OK#9a
GDB -> $g#67
GDB <- $0000....#df
----(gdb) infe 2
----(gdb) c &
GDB -> $vCont;c:p2.-1#10
GDB <- $OK#9a
----(gdb) infe 1
----(gdb) b producer
GDB -> $m280,4#67
GDB <- $00000000#80
GDB -> $Z0,280,4#b0
GDB <- $OK#9a
Comment 3 Palla, Rajesh 2023-09-06 04:31:01 UTC
Created attachment 15098 [details]
log file
Comment 4 Tom Tromey 2023-09-06 16:38:25 UTC
From that log, the Hg is sent because immediately after,
gdb tries to read memory.
I'm not sure why switching does nothing in your case.
There is no high road to this, you just have to debug gdb.

Invalidating the regcache in the low levels seems wrong to me.
Why don't the higher level invalidations work for you?