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: Pedro Alves <palves at redhat dot com>
- To: Andreas Arnez <arnez at linux dot vnet dot ibm 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 15:26:06 +0100
- 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>
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