[PATCH v3 3/3] Dynamic core regset sections support

[Andreas Arnez]

Pedro Alves <palves@redhat.com> writes:

> On 06/13/2013 12:02 PM, Andreas Arnez wrote:
>> Pedro Alves <palves@redhat.com> writes:
>> 
>>>> Do you mean to always write the TDB regset into the core dump, like
>>>> without the patch?  And then add some logic such that GDB recognizes
>>>> zero values in the register note section as invalid and clears the
>>>> regset?  Or do I misinterpret your suggestion?
>>>
>>> Not zero, but present them as unavailable/invalid.
>> 
>> Not sure I understand your point here.  *Presenting them* as unavailable
>> is exactly what the patch does.
>
> Well, you were the one who brought zeros up.  ;-)

Zeros are written by gcore without the patch, because this is what a
register note section happens to be filled with when the registers are
actually unavailable.  The patch avoids that and doesn't write the
section at all.

> Mark didn't seem to imply any connection between zeros and the
> registers' validity, and I was reinforcing the idea.  I'm not sure
> what you meant by clearing, but that seemed to imply zeroing too.

No, I meant marking unavailable.

>>> Isn't there a control register GDB can read to check whether a
>>> transaction is in progress (useful for both core and live debugging) ?
>> 
>> No, the kernel indicates an interrupted transaction with the presence of
>> the TDB regset.  This applies to ptrace as well as to a core dump.  My
>> goal for gcore was to behave the same.
>
> I see...
>
> I tried to do a little investigation on s390 transactions.  It's now
> my understanding that these "registers" are really a memory block
> whose address passed in by the user to the hardware when a transaction
> is started with TBEGIN.  There's a tbegin variant ("simple tbegin" ?)
> that doesn't take such a tcb address, and I guess there's some way the
> kernel coordinates with the hardware to know/specify where the tcb is
> written to.

Almost.  There are two ways the TDB can get written.  The way you
describe is for a "normal" transaction abort.  The other way is for an
abort due to a program interruption, like an illegal instruction, or a
breakpoint or watchpoint hit.  In that case the hardware writes the
"program-interruption TDB" to a fixed address, independently from any
user-specified address.

> I couldn't find the definite manual/document that explains what
> exactly the TDB contains though (tdb0, atia, etc?), only references
> like "If the transaction fails, the TDB is populated with lots of
> information.".  Cool, what is lots, though? :-) Do you have a pointer,
> for my own education, and for the archives?

See the z/Architecture Principles of Operation:
http://publibfp.boulder.ibm.com/epubs/pdf/dz9zr009.pdf
Specifically, refer to the section "Transactional-Execution Facility" in
chapter 5, "Program Execution".

> I was mildly wondering whether it wouldn't be a little better to
> expose this through a new target object (and target_read/qXfer:read)
> instead, and add a $_tdb convenience variable (similar to $_siginfo --
> p $_tdb; p $_tdb.atia, etc.).  That'd mean no read of the TDB block
> unless the user requested it, possibility to error out when outside a
> transaction, and a way for the user to put the whole TDB in GDB's
> value history.

Interesting thought.  There are probably pros and cons either way.  The
regset approach seemed most straightforward, because the kernel presents
the program interruption TDB as a regset.  Retrieving the TDB only on
user request won't work in the long run, because it contains vital
information for transaction debugging.  I'm currently working on a GDB
patch to exploit that.