Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andreas Arnez <arnez@linux.vnet.ibm.com>
To: Pedro Alves <palves@redhat.com>
Cc: Ulrich Weigand <uweigand@de.ibm.com>, gdb-patches@sourceware.org
Subject: Re: [PING][PATCH 2/2] Involve gdbarch in taking DWARF register pieces
Date: Thu, 28 Apr 2016 18:16:00 -0000	[thread overview]
Message-ID: <m38tzxvbtr.fsf@oc1027705133.ibm.com> (raw)
In-Reply-To: <m3d1p9vfqo.fsf@oc1027705133.ibm.com> (Andreas Arnez's message of	"Thu, 28 Apr 2016 18:51:27 +0200")

On Thu, Apr 28 2016, Andreas Arnez wrote:

> On Thu, Apr 28 2016, Pedro Alves wrote:
>
>> I'd naively think that the fix for something like that would be
>> to make dwarf_reg_to_regnum return the gdb FP register number instead 
>> of the vector number, when the type fits in a FP register, instead of
>> the need for an extra diversion step.  Ignoring the fact that we don't
>> currently pass the type/size to gdbarch_dwarf_reg_to_regnum.
>
> Right, ignoring that fact ;-)
>
> Also, IMHO the "actual" placement of an object within a register does
> not conceptually depend on where the register number came from.  It
> could come from DWARF, from some other debug format, from the user, or
> from wherever.  Adjusting the placement only for objects with a DWARF
> location seems wrong to me.

There's another aspect I should probably mention here.  The adjustment
of the register number in this gdbarch method is really just a
circumvention around the register cache's inability of representing
*partially* valid registers.  Otherwise unwinding would result in the
first 64 bits of such a vector register being "valid" and the others
"invalid", and then we could slice any value types from the valid bits.

In the long run maybe we want to extend the regcache in such a
direction, but I didn't see that in the scope of this fix.

--
Andreas


  reply	other threads:[~2016-04-28 18:16 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-15 10:42 [PATCH 0/2] Fixes for some s390 fails with store.exp Andreas Arnez
2016-04-15 10:43 ` [PATCH 2/2] Involve gdbarch in taking DWARF register pieces Andreas Arnez
2016-04-15 18:10   ` Ulrich Weigand
2016-04-15 18:37     ` Pedro Alves
2016-04-18 11:53       ` Andreas Arnez
2016-04-18 13:53         ` Pedro Alves
2016-04-18 15:02           ` Andreas Arnez
2016-04-18 15:55             ` Pedro Alves
2016-04-18 15:57               ` Doug Evans
2016-04-19 12:08               ` Andreas Arnez
2016-04-28 13:24                 ` [PING][PATCH " Andreas Arnez
2016-04-28 14:47                   ` Pedro Alves
2016-04-28 16:51                     ` Andreas Arnez
2016-04-28 18:16                       ` Andreas Arnez [this message]
2016-04-28 22:15                         ` Pedro Alves
2016-04-28 22:15                       ` Pedro Alves
2016-06-14 17:03                   ` Jan Kratochvil
2016-04-15 10:43 ` [PATCH 1/2] S390: Take value from sub-register if applicable Andreas Arnez
2016-04-15 18:08   ` Ulrich Weigand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m38tzxvbtr.fsf@oc1027705133.ibm.com \
    --to=arnez@linux.vnet.ibm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@redhat.com \
    --cc=uweigand@de.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox