This is the mail archive of the
mailing list for the GCC project.
Re: [RFC] DW_OP_piece vs. DW_OP_bit_piece on a Register
- From: Andreas Arnez <arnez at linux dot vnet dot ibm dot com>
- To: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- Cc: "gcc\ at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, "gdb\ at sourceware dot org" <gdb at sourceware dot org>, Ulrich Weigand <uweigand at de dot ibm dot com>, Maciej Rozycki <Maciej dot Rozycki at imgtec dot com>
- Date: Tue, 26 Jan 2016 12:57:23 +0100
- Subject: Re: [RFC] DW_OP_piece vs. DW_OP_bit_piece on a Register
- Authentication-results: sourceware.org; auth=none
- References: <m3vb6wm86q dot fsf at oc1027705133 dot ibm dot com> <6D39441BF12EF246A7ABCE6654B023536A70637C at LEMAIL01 dot le dot imgtec dot org>
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
Also, how do you think that the following should be represented in
* 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
Thanks for your input!