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

[Pedro Alves <palves@redhat.com>]

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