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: [PATCH 2/8] gdb/s390: Fill write_guessed_tracepoint_pc hook.


On Tue, Jan 26 2016, Marcin KoÅcielnicki wrote:

> If write_guessed_tracepoint_pc is called, we explicitely have no
> registers data other than PC itself - there's no original PSWA to
> speak of.  The state of PSWA high bit probably doesn't matter all that
> much, but since we want to mark PSWA as known, we'd better write the
> reasonable value to it.

That's true if the new gdbarch method implements a very specific
semantic, tailored to the singular use in tracefile_fetch_registers and
not necessarily usable for any other purposes.  But I interpreted the
semantic more generically: "Supply VAL as the new PC to the given
REGCACHE".

Maybe the generic approach could be implemented like this (completely
untested):

  /* Adjust PSWA high bit if in 31-bit mode.  */
  if (sz == 4)
    {
      if (regcache_register_status (regcache, S390_PSWA_REGNUM)
	  == REG_VALID)
	{
	  gdb_byte pswa[4];

	  regcache_raw_collect (regcache, S390_PSWA_REGNUM, pswa);
	  pc |= 0x80000000 & extract_unsigned_integer (pswa, 4, byte_order);
	}
      else
	pc |= 0x80000000;
    }

BTW, even this may be considered a special case of a hypothetical
gdbarch method pseudo_register_supply().  *Or* we might think of it as
writing to a "cache-only" (rather than read-only) regcache via a usual
regcache_cooked_write().  In this case no new gdbarch method would be
needed.  Such a feature might also come handy when trying to support the
modification of cooked registers during core file debugging, such as
discussed in this thread:

  https://www.sourceware.org/ml/gdb/2011-02/msg00042.html

--
Andreas


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