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

[Pedro Alves <palves@redhat.com>]

On 06/13/2013 10:16 AM, Andreas Arnez wrote:
> Mark Kettenis <mark.kettenis@xs4all.nl> writes:
> 
>> Sorry, but I really don't like the obfuscation that this diff brings
>> to the amd64 & i186 Linux targets.
> 
> If you can point me specifically to the spot where the obfuscation
> occurs, I'll do my best to clean it up.  A side-intention with the patch
> actually was to *improve* readability, mainly by avoiding copy- & pasted
> array initializers and distributed code logic.  And indeed, while
> offering improved flexibility, the patch overall saves 60 lines of code:
> 
>  11 files changed, 266 insertions(+), 326 deletions(-)
> 
> amd64 is the only architecture that suffers from a slight code increase
> (8 lines).
> 
>> Is there really no other way to this?
> 
> There are always other ways ;-) I already implemented some of them, and
> the proposed patch seemed like the best approach to me.
> 
>> Is it really that bad to write out the invalid TDB registers?  If GDB
>> recognizes them as invalid, this shouldn't be a big issue should it?
> 
> 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.  I tend to agree with
Mark.  Isn't there a control register GDB can read to check whether
a transaction is in progress (useful for both core and live debugging) ?

> BTW, I wonder how transaction diagnostics works on x86.  E.g., when an
> illegal instruction occurs within a hardware transaction, will the core
> dump contain the address of the violating instruction?

I haven't personally tried debugging anything with transaction support yet.

-- 
Pedro Alves