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

[Pedro Alves <palves@redhat.com>]

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.  ;-)
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.  If you had a control
register to check, there would be no need to zero out registers.

>> 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.
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?

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.

-- 
Pedro Alves