This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v3 3/3] Dynamic core regset sections support
- From: Andreas Arnez <arnez at linux dot vnet dot ibm dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: Mark Kettenis <mark dot kettenis at xs4all dot nl>, gdb-patches at sourceware dot org, Ulrich dot Weigand at de dot ibm dot com
- Date: Thu, 13 Jun 2013 19:15:58 +0200
- Subject: Re: [PATCH v3 3/3] Dynamic core regset sections support
- References: <877ghzmkmj dot fsf at br87z6lw dot de dot ibm dot com> <8738sngy5e dot fsf at br87z6lw dot de dot ibm dot com> <201306121521 dot r5CFLvl9024858 at glazunov dot sibelius dot xs4all dot nl> <871u86e5gi dot fsf at br87z6lw dot de dot ibm dot com> <51B99143 dot 3080808 at redhat dot com> <878v2e8ead dot fsf at br87z6lw dot de dot ibm dot com> <51B9D67E dot 1080207 at redhat dot com>
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.