Re: [RFA/RFT PATCH 0/3] Add TDB regset support

Pedro Alves
2013-06-11T10:43:44Z

On 06/10/2013 04:39 PM, Andreas Arnez wrote:
> Pedro Alves <palves@redhat.com> writes:
>
>> On 06/07/2013 07:15 PM, Andreas Arnez wrote:
>>> Pedro Alves <palves@redhat.com> writes:
>>>> You might not need to look at the auxv. Return the right tdesc
>>>> depending on presence of bfd sections. See
>>>> ppc_linux_core_read_description.
>>>
>>> This doesn't work for the TDB, because the absence of the TDB
>>> register section doesn't mean that the core file target didn't
>>> support it. At least we'd break the gcore.exp test case.
>>
>> Okay. How are the TDB registers presented to the user (info
>> all-registers, etc) in the current patchset when the target supports
>> them, but the inferior is presently interrupted outside a transaction,
>> with live debugging? (screenshot, please! :-))
>
> (gdb) info all-reg
> pswm 0x705200180000000 505845723963588608
> pswa 0x8000060a 2147485194
> --- /snip/ ---
> tdb0 *value not available*
> tac *value not available*
> tct *value not available*
> atia *value not available*
> tr0 *value not available*
> tr1 *value not available*
> tr2 *value not available*
> tr3 *value not available*
> tr4 *value not available*
> tr5 *value not available*
> tr6 *value not available*
> tr7 *value not available*
> tr8 *value not available*
> tr9 *value not available*
> tr10 *value not available*
> tr11 *value not available*
> tr12 *value not available*
> tr13 *value not available*
> tr14 *value not available*
> tr15 *value not available*
> pc 0x8000060a 0x8000060a <terminal_func+10>
> cc 0x2 2
>
> When there's no TDB for the current inferior's state, "value not
> available" is the closest representation I could find in the current
> regcache design. Or maybe there is a better way?
>
> My assumption was that this representation is even acceptable when the
> inferior runs on a target without transactional-execution support,
> because there's really no difference between a program that *never uses*
> transactions and a program that *can not* use transactions.

It's close but not the same. If the machine doesn't have those
registers, then they should not presented at all.

>
> But I can certainly take a shot at an alternate version of the patch
> which introduces new target descriptions "s390x-linux64v2-tx" and
> "s390-linux64v2-tx" and selects one of those if the hardware supports
> transactions. That's what's being proposed, right?

Right. We usually name the descriptions "CPU/PART-ABI/OS.xml",
with cpu/part number being e.g., powerpc-750 for "PowerPC 750".
but I have no idea about S/390 cpu names. E.g., when
dsp registers get added to mips64-linux.xml, we get
mips64-dsp-linux.xml. Maybe you should drop the v2 going forward
(I think v1/v2 made sense since the additions were Linux specific, not
a new machine), and make the new one "s390x-tx-linux64" or some other
cpu name that'd make most sense. Or make that v3, dunno, up to you.

>> The new org.gnu.gdb.s390.tdb target feature needs to be documented,
>> btw.
>
> OK, will do that in my updated patch.
>
>> TDB support should be mentioned in NEWS too.
>
> Will do.
>
>> With xi:include, that's really pretty manageable. Please do take a
>> look at ppc_linux_read_description and at features/rs6000/, for
>> example, though there are several others in the tree. The x86 port
>> has a complex selection of proper description/register set too, given
>> xsave.
>
> Did you want to hint at anything specific?

With

> Actually representing n optional register sets with different tdescs
> would require 2**n tdescs, right?

you seemed to be worried by the explosion of the number of target
descriptions. I was pointing out at an example in the tree where
for the same general architecture family we have many target descriptions,
one per each different machine with a different set of register sets,
as an example of that not really being a problem.

> Or just how to add a new tdesc in general (and select it)?

That too.

Thanks,
--
Pedro Alves