[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gdb-patches
Subject:    [PATCH 2/8] gdb/s390: Fill write_guessed_tracepoint_pc hook.
From:       arnez () linux ! vnet ! ibm ! com (Andreas Arnez)
Date:       2016-01-29 18:57:00
Message-ID: m360ycdxip.fsf () oc1027705133 ! ibm ! com
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]