public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Andreas Arnez <arnez@linux.vnet.ibm.com>
To: Matthew Fortune <Matthew.Fortune@imgtec.com>
Cc: "gcc\@gcc.gnu.org" <gcc@gcc.gnu.org>,
	       "gdb\@sourceware.org" <gdb@sourceware.org>,
	       Ulrich Weigand <uweigand@de.ibm.com>,
	       Maciej Rozycki <Maciej.Rozycki@imgtec.com>
Subject: Re: [RFC] DW_OP_piece vs. DW_OP_bit_piece on a Register
Date: Tue, 26 Jan 2016 11:57:00 -0000	[thread overview]
Message-ID: <m31t94ft98.fsf@oc1027705133.ibm.com> (raw)
In-Reply-To: <6D39441BF12EF246A7ABCE6654B023536A70637C@LEMAIL01.le.imgtec.org>	(Matthew Fortune's message of "Mon, 25 Jan 2016 22:01:47 +0000")

On Mon, Jan 25 2016, Matthew Fortune wrote:

> My dwarf knowledge is not brilliant but I have had to recently consider
> it for MIPS floating point ABI changes aka FPXX and friends. I don't know
> exactly where this fits in to your whole description but in case it has
> a bearing on this we now have the following uses of DW_OP_piece:
>
> 1) double precision data split over two 32-bit FPRs
> Uses a pair of 32-bit DW_OP_piece (ordered depending on endianness).
>
> 2) double precision data in one 64-bit FPR
> No need for DW_OP_piece.
>
> 3) double precision data that may be in two 32-bit FPRs or may be in
>    one 64-bit FPR depending on hardware mode
> Uses a single 64-bit DW_OP_piece on the even numbered register. 

Hm, so in 32-bit hardware mode the DWARF consumer is expected to treat
the DW_OP_piece on the even numbered register as if it were two pieces
from two consecutive registers?  Or should we rather consider the even
numbered register to be 64 bit wide, where the right half shadows the
next odd-numbered register?  If so, I believe you generally want pieces
from FPRs to be taken from the left, correct?

> I'm guilty of not actually finishing this off and doing the GDB side but
> the theory seemed OK when I did it! From your description this behaviour
> best matches DW_OP_piece having ABI dependent behaviour which would make
> it acceptable. These three variations can potentially exist in the same
> program albeit that (1) and (3) can't appear in a single shared library
> or executable. It's all a little strange but the whole floating point
> MIPS o32 ABI is pretty complex now.

I don't quite understand why (1) and (3) can not coexist in the same
shared library or executable.  Can you elaborate a bit?

I'm curious about the interaction with vector registers.  AFAIK, vector
registers on MIPS also embed the FPRs (left or right?).  Are the same
DWARF register numbers used for both?  And when taking a 64-bit
DW_OP_piece from a vector register, would this piece correspond to the
embedded FPR?

Also, how do you think that the following should be represented in
DWARF:

* Odd-sized bit field in one of a vector register's elements;

* odd-sized bit field spilled into an FPR;

* single-precision `complex float' living in two consecutive 64-bit
  FPRs.

Thanks for your input!

--
Andreas

  reply	other threads:[~2016-01-26 11:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-14 16:34 Andreas Arnez
2016-01-16 13:27 ` Joel Brobecker
2016-01-18 16:00   ` Andreas Arnez
2016-01-25 22:01 ` Matthew Fortune
2016-01-26 11:57   ` Andreas Arnez [this message]
2016-02-11 12:18     ` Matthew Fortune
2016-02-11 17:04       ` Andreas Arnez

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=m31t94ft98.fsf@oc1027705133.ibm.com \
    --to=arnez@linux.vnet.ibm.com \
    --cc=Maciej.Rozycki@imgtec.com \
    --cc=Matthew.Fortune@imgtec.com \
    --cc=gcc@gcc.gnu.org \
    --cc=gdb@sourceware.org \
    --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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).