commit 3d5a60de52
Author: H.J. Lu <hjl.tools@gmail.com>
Date: Thu Jun 8 10:01:03 2023 -0700
x86-64: Add R_X86_64_CODE_4_GOTPCRELX
added a new field, fx_tcbit3, to fix. But it didn't initialize it.
Fix it by clearing it in fix_new_internal.
* wrtite.c (fix_new_internal): Clear fx_tcbit3.
Fortran provides additional entry points for subroutines and functions.
These entry points may use only a subset (or a different set) of the
parameters of the original subroutine. The entry points may be described
via the DWARF tag DW_TAG_entry_point.
This commit adds support for parsing the DW_TAG_entry_point DWARF tag.
Currently, between ifx/ifort/gfortran, only ifort is actually emitting
this tag. Both, ifx and gfortran use the DW_TAG_subprogram tag as
workaround/alternative. Thus, this patch really only adds more ifort
support. Even so, some of the attached tests still fail for ifort, due
to some wrong line info generated for the entry points in ifort.
After this patch it is possible to set a breakpoint in gdb with the
ifort compiled example at the entry points 'foo' and 'foobar', which was not
possible before.
As gcc and ifx do not emit the tag I also added a test to gdb.dwarf2
which uses some underlying c compiled code and adds some Fortran style DWARF
to it emitting the DW_TAG_entry_point. Before this patch it was not
possible to actually define breakpoint at the entry point tags.
For gfortran there actually exists a bug on bugzilla, asking for the use
of DW_TAG_entry_point over DW_TAG_subprogram:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37134
This patch was originally posted here
https://sourceware.org/legacy-ml/gdb-patches/2017-07/msg00317.html
but its review/pinging got lost after a while. I reworked it to fit the
current GDB.
Co-authored-by: Bernhard Heckel <bernhard.heckel@intel.com>
Co-authored-by: Tim Wiederhake <tim.wiederhake@intel.com>
Approved-by: Tom Tromey <tom@tromey.com>
In dwarf2_get_pc_bounds we were writing unchecked to *lowpc. This
commit adds a gdb_assert to first check that lowpc != nullptr.
Approved-by: Tom Tromey <tom@tromey.com>
This commit is in preparation of the next commit. There, we will add
a second variation to retrieve the pc bounds for DIEs tagged with
DW_TAG_entry_point. Instead of dwarf_get_pc_bounds_ranges_or_highlow_pc
we will call a separate method for entry points. As the validity checks
at the endo f dwarf2_get_pc_bounds are the same for both variants,
we introduced the new dwarf_get_pc_bounds_ranges_or_highlow_pc method,
outsourcing part of dwarf2_get_pc_bounds.
This commit should have no functional impact on GDB.
Approved-by: Tom Tromey <tom@tromey.com>
Add tls le relax related testsuites in ld.
The new test cases are mainly tested in three aspects:
1. tls le relax function correctness test.
2. tls le relax boundary check test.
3. tls le relax function compatibility test.
ld/testsuite/ChangeLog:
* ld/testsuite/ld-loongarch-elf/relax.exp: Modify test.
* ld/testsuite/ld-loongarch-elf/old-tls-le.s: New test.
* ld/testsuite/ld-loongarch-elf/relax-bound-check-tls-le.s: Likewise.
* ld/testsuite/ld-loongarch-elf/tls-relax-compatible-check-new.s: Likewise.
* ld/testsuite/ld-loongarch-elf/relax-tls-le.s: Likewise.
* ld/testsuite/ld-loongarch-elf/tls-relax-compatible-check-old.s: Likewise.
Add tls le relax related relocs support and testsuites in gas.
The main test is three new relocation items,
R_LARCH_TLS_LE_ADD_R, R_LARCH_TLS_LE_HI20_R,
R_LARCH_TLS_LE_LO12_R can be generated properly
and tls le insn format check.
gas/ChangeLog:
* config/tc-loongarch.c:
(loongarch_args_parser_can_match_arg_helper): Add support for relax.
* gas/testsuite/gas/loongarch/reloc.d: Likewise.
* gas/testsuite/gas/loongarch/reloc.s: Likewise.
* gas/testsuite/gas/loongarch/loongarch.exp: Likewise.
* gas/testsuite/gas/loongarch/tls_le_insn_format_check.s: New test.
Add new relocs number for tls le relax.
include/ChangeLog:
* elf/loongarch.h:
(RELOC_NUMBER (R_LARCH_TLS_LE_HI20_R, 121)): New relocs number.
(RELOC_NUMBER (R_LARCH_TLS_LE_ADD_R, 122)): Likewise.
(RELOC_NUMBER (R_LARCH_TLS_LE_LO12_R, 123)): Likewise.
Add tls le relax support and related relocs in bfd.
New relocation related explanation can refer to the following url:
https://github.com/loongson/la-abi-specs/blob/release/laelf.adoc
This support does two main things:
1. Implement support for three new relocation items in bfd.
The three new relocation items are shown below:
R_LARCH_TLS_LE_ADD_R
R_LARCH_TLS_LE_HI20_R
R_LARCH_TLS_LE_LO12_R
2. ADD a new macro RELOCATE_TLS_TP32_HI20
Handle problems caused by symbol extensions in TLS LE, The processing
is similar to the macro RELOCATE_CALC_PC32_HI20 method.
3. Implement the tls le relax function.
bfd/ChangeLog:
* bfd-in2.h: Add relocs related to tls le relax.
* elfnn-loongarch.c:
(loongarch_relax_tls_le): New function.
(RELOCATE_TLS_TP32_HI20): New macro.
(loongarch_elf_check_relocs): Add new reloc support.
(perform_relocation): Likewise.
(loongarch_elf_relocate_section): Handle new relocs related to relax.
(loongarch_elf_relax_section): Likewise.
* elfxx-loongarch.c:
(LOONGARCH_HOWTO (R_LARCH_TLS_LE_ADD_R)): New reloc how to type.
(LOONGARCH_HOWTO (R_LARCH_TLS_LE_HI20_R)): Likewise.
(LOONGARCH_HOWTO (R_LARCH_TLS_LE_LO12_R)): Likewise.
* libbfd.h: Add relocs related to tls le relax.
* reloc.c: Likewise.
In order to make it easier to complete the compiler's support for
the XTheadVector extension and to be as compatible as possible
with the programming model of the 'V' extension ([1]), we consider
adding a few pseudo instructions ([2]).
th.vmmv.m vd,vs => th.vmand.mm vd,vs,vs
th.vneg.v vd,vs => th.vrsub.vx vd,vs,x0
th.vncvt.x.x.v vd,vs,vm => th.vnsrl.vx vd,vs,x0,vm
th.vfneg.v vd,vs => th.vfsgnjn.vv vd,vs,vs
th.vfabs.v vd,vs => th.vfsgnjx.vv vd,vs,vs
Ref:
[1] https://gcc.gnu.org/pipermail/gcc-patches/2023-December/641302.html
[2] https://github.com/T-head-Semi/thead-extension-spec/pull/40
Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
Co-developed-by: Christoph Müllner <christoph.muellner@vrull.eu>
gas/ChangeLog:
* testsuite/gas/riscv/x-thead-vector.d: Add tests for new
pseudoinstructions.
* testsuite/gas/riscv/x-thead-vector.s: Likewise.
opcodes/ChangeLog:
* riscv-opc.c: Add new pseudoinstructions.
For
add name@gottpoff(%rip), %reg
mov name@gottpoff(%rip), %reg
add
# define R_X86_64_CODE_4_GOTTPOFF 44
and for
lea name@tlsdesc(%rip), %reg
add
# define R_X86_64_CODE_4_GOTPC32_TLSDESC 45
if the instruction starts at 4 bytes before the relocation offset.
They are similar to R_X86_64_GOTTPOFF and R_X86_64_GOTPC32_TLSDESC,
respectively. Linker can covert GOTTPOFF to
add $name@tpoff, %reg
mov $name@tpoff, %reg
and GOTPC32_TLSDESC to
mov $name@tpoff, %reg
mov name@gottpoff(%rip), %reg
if the instruction is encoded with the REX2 prefix when possible.
bfd/
* elf64-x86-64.c (x86_64_elf_howto_table): Add
R_X86_64_CODE_4_GOTTPOFF and R_X86_64_CODE_4_GOTPC32_TLSDESC.
(R_X86_64_standard): Updated.
(x86_64_reloc_map): Add BFD_RELOC_X86_64_CODE_4_GOTTPOFF
and BFD_RELOC_X86_64_CODE_4_GOTPC32_TLSDESC.
(elf_x86_64_check_tls_transition): Handle R_X86_64_CODE_4_GOTTPOFF
and R_X86_64_CODE_4_GOTPC32_TLSDESC.
(elf_x86_64_tls_transition): Likewise.
(elf_x86_64_scan_relocs): Likewise.
(elf_x86_64_relocate_section): Likewise.
* reloc.c (bfd_reloc_code_real): Add
BFD_RELOC_X86_64_CODE_4_GOTTPOFF and
BFD_RELOC_X86_64_CODE_4_GOTPC32_TLSDESC.
* bfd-in2.h: Regenerated.
* libbfd.h: Likewise.
gas/
* config/tc-i386.c (tc_i386_fix_adjustable): Handle
BFD_RELOC_X86_64_CODE_4_GOTTPOFF and
BFD_RELOC_X86_64_CODE_4_GOTPC32_TLSDESC.
(md_assemble): Handle BFD_RELOC_X86_64_CODE_4_GOTTPOFF.
(output_insn): Don't add empty REX prefix with REX2 prefix.
(output_disp): Handle BFD_RELOC_X86_64_CODE_4_GOTTPOFF and
BFD_RELOC_X86_64_CODE_4_GOTPC32_TLSDESC.
(md_apply_fix): Likewise.
(i386_validate_fix): Generate BFD_RELOC_X86_64_CODE_4_GOTTPOFF or
BFD_RELOC_X86_64_CODE_4_GOTPC32_TLSDESC if ixp->fx_tcbit3 is set.
(tc_gen_reloc): Handle BFD_RELOC_X86_64_CODE_4_GOTTPOFF and
BFD_RELOC_X86_64_CODE_4_GOTPC32_TLSDESC.
* testsuite/gas/i386/x86-64-gottpoff.d: New file.
* testsuite/gas/i386/x86-64-gottpoff.s: Likewise.
* testsuite/gas/i386/x86-64-tlsdesc.d: Likewise.
* testsuite/gas/i386/x86-64-tlsdesc.s: Likewise.
include/
* elf/x86-64.h (elf_x86_64_reloc_type): Add
R_X86_64_CODE_4_GOTTPOFF and R_X86_64_CODE_4_GOTPC32_TLSDESC
ld/
* testsuite/ld-x86-64/tlsbindesc.d: Updated.
* testsuite/ld-x86-64/tlsbindesc.rd: Likewise.
* testsuite/ld-x86-64/tlsbindesc.s: Add R_X86_64_CODE_4_GOTTPOFF
and R_X86_64_CODE_4_GOTPC32_TLSDESC tests.
Define NT_X86_SHSTK which is the note for x86 Shadow Stack (SHSTK) to
support Intel SHSTK in Linux kernel.
For now only userspace shadow stack and kernel IBT are supported by the
linux kernel. This note should be used instead of NT_X86_CET introduced
in the commit "x86: Add NT_X86_CET note", as it is outdated and only
used by old binutils versions.
gas/ChangeLog:
2023-12-28 Lingling Kong <lingling.kong@intel.com>
H.J. Lu <hongjiu.lu@intel.com>
Lili Cui <lili.cui@intel.com>
Lin Hu <lin1.hu@intel.com>
* testsuite/gas/i386/x86-64-apx-egpr-inval.l: Add some insn don't
support gpr32.
* testsuite/gas/i386/x86-64-apx-egpr-inval.s: Ditto.
* testsuite/gas/i386/x86-64.exp: Add new test.
* testsuite/gas/i386/x86-64-apx-egpr-promote-inval.l: New test.
* testsuite/gas/i386/x86-64-apx-egpr-promote-inval.s: New test.
* testsuite/gas/i386/x86-64-apx-evex-egpr.d: New test.
* testsuite/gas/i386/x86-64-apx-evex-egpr.s: New test.
* testsuite/gas/i386/x86-64-apx-evex-promoted-bad.d: New test.
* testsuite/gas/i386/x86-64-apx-evex-promoted-bad.s: New test.
* testsuite/gas/i386/x86-64-apx-evex-promoted-intel.d: New test.
* testsuite/gas/i386/x86-64-apx-evex-promoted.d: New test.
* testsuite/gas/i386/x86-64-apx-evex-promoted.s: New test.
This patch adds non-ND, non-NF forms of EVEX promotion insn.
EVEX extension of legacy instructions:
All promoted legacy instructions are placed in EVEX map 4, which is
currently reserved.
EVEX extension of EVEX instructions:
All existing EVEX instructions are extended by APX using the extended
EVEX prefix, so that they can access all 32 GPRs.
EVEX extension of VEX instructions:
Promoting a VEX instruction into the EVEX space does not change the map
id, the opcode, or the operand encoding of the VEX instruction.
Note: The promoted versions of MOVBE will be extended to include the “MOVBE
reg1, reg2”.
gas/ChangeLog:
2023-12-28 Lingling Kong <lingling.kong@intel.com>
H.J. Lu <hongjiu.lu@intel.com>
Lili Cui <lili.cui@intel.com>
Lin Hu <lin1.hu@intel.com>
* config/tc-i386.c (struct _i386_insn): Add has_egpr.
(need_evex_encoding): Adjusted for apx.
(cpu_flags_match): Ditto.
(install_template): Handled APX combines.
(is_apx_evex_encoding): Test apx evex encoding.
(build_apx_evex_prefix): Enabe APX evex prefix.
(md_assemble): Handle apx with evex encoding.
(process_suffix): Handle apx map4 prefix.
(check_register): Assign i.vec_encoding for APX evex instructions.
* testsuite/gas/i386/x86-64-evex.d: Adjust test cases.
* testsuite/gas/i386/x86-64.exp: Adjust x86-64-inval-movbe.
opcodes/ChangeLog:
* i386-dis-evex-len.h: Handle EVEX_LEN_0F38F2, EVEX_LEN_0F38F3.
* i386-dis-evex-prefix.h: Handle PREFIX_EVEX_0F38F2_L_0,
PREFIX_EVEX_0F38F3_L_0, PREFIX_EVEX_MAP4_D8,
PREFIX_EVEX_MAP4_DA, PREFIX_EVEX_MAP4_DB,
PREFIX_EVEX_MAP4_DC, PREFIX_EVEX_MAP4_DD,
PREFIX_EVEX_MAP4_DE, PREFIX_EVEX_MAP4_DF,
PREFIX_EVEX_MAP4_F0, PREFIX_EVEX_MAP4_F1,
PREFIX_EVEX_MAP4_F2, PREFIX_EVEX_MAP4_F8.
* i386-dis-evex-reg.h: Handle REG_EVEX_0F38F3_L_0_P_0.
* i386-dis-evex.h: Add EVEX_MAP4_ for legacy insn
promote to apx to use gpr32
* opcodes/i386-dis-evex-x86-64.h: Handle Add X86_64_EVEX_0F90,
X86_64_EVEX_0F92, X86_64_EVEX_0F93, X86_64_EVEX_0F38F2,
X86_64_EVEX_0F38F3, X86_64_EVEX_0F38F5, X86_64_EVEX_0F38F6,
X86_64_EVEX_0F38F7, X86_64_EVEX_0F3AF0, X86_64_EVEX_0F91.
* i386-dis.c
(struct instr_info): Deleted bool r.
(PREFIX_NP_OR_DATA): New.
(NO_PREFIX): New.
(putop): Ditto.
(X86_64_EVEX_FROM_VEX_TABLE): Diito.
(get_valid_dis386): Decode insn erex in extend evex prefix.
Handle EVEX_MAP4
(print_insn): Handle PREFIX_DATA_AND_NP_ONLY.
(print_register): Handle apx instructions decode.
(OP_E_memory): Diito.
(OP_G): Diito.
(OP_XMM): Diito.
(DistinctDest_Fixup): Diito.
* i386-gen.c (process_i386_opcode_modifier): Add EVEXMAP4.
* i386-opc.h (SPACE_EVEXMAP4): Add legacy insn
promote to evex.
* i386-opc.tbl: Handle some legacy and vex insns don't
support gpr32. And add some legacy insn (map2 / 3) promote
to evex.
The PRU architecture documentation [1] was used for the initial GNU
simulator implementation. But recently [2] TI confirmed the carry
behaviour was wrongly documented. In reality, the PRU carry behaves
like the carry in ARM processors.
This patch fixes simulator to align with latest recommendations from TI.
The new carry.s test was also validated to pass on real hardware -
a BeaglePlay board [3]. That test is a bit long because TI still
has not released official updates for the PRU documents. And I wanted
to ensure simulator handles all edge cases exactly as the real hardware
does.
[1] https://www.ti.com/lit/pdf/spruij2
[2] https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1244359/sk-am64b-am64x-pru-assembler-how-works-this-bloody-carry
[3] https://www.beagleboard.org/boards/beagleplay
Signed-off-by: Dimitar Dimitrov <dimitar@dinux.eu>
* Problematic fix commit,
2029e13917
RISC-V: Clarify the behaviors of SET/ADD/SUB relocations
* Bugzilla,
https://sourceware.org/bugzilla/show_bug.cgi?id=31179#c5
The addend of SUB_ULEB128 should be zero if using .uleb128, but we make it
non-zero by accident in assembler before. This causes troubles by applying
the above commit, since the calculation is changed to support .reloc *SUB*
relocations with non-zero addend.
We encourage people to rebuild their stuff to get the non-zero addend of
SUB_ULEB128, but that might need some times, so report warnings to inform
people need to rebuild their stuff if --check-uleb128 is enabled.
Since the failed .reloc cases for ADD/SET/SUB/ULEB128 are rarely to use,
it may acceptable that stop supproting them until people rebuld their stuff,
maybe half-year or a year later. Or maybe we should teach people that don't
write the .reloc R_RISCV_SUB* with non-zero constant, and then report
warnings/errors in assembler.
bfd/
* elfnn-riscv.c (perform_relocation): Ignore the non-zero addend of
R_RISCV_SUB_ULEB128.
(riscv_elf_relocate_section): Report warnings to inform people need
to rebuild their stuff if --check-uleb128 is enabled. So that can
get the right non-zero addend of R_RISCV_SUB_ULEB128.
* elfxx-riscv.h (struct riscv_elf_params): Added bool check_uleb128.
ld/
* NEWS: Updated.
* emultempl/riscvelf.em: Added linker risc-v target options,
--[no-]check-uleb128, to enable/disable checking if the addend of
uleb128 is non-zero or not. So that people will know they need to
rebuild the objects with binutils 2.42 and up, to get the right zero
addend of SUB_ULEB128 relocation, or they may get troubles if using
.reloc.
* ld/testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated.
* ld/testsuite/ld-riscv-elf/pr31179*: New test cases.
Seen when running ld-loongarch-elf/tlsdesc-dso test.
elfxx-loongarch.c:1844:32: runtime error: index 125 out of bounds for
type 'loongarch_reloc_howto_type [124]'
So either the loongarch_howto_table needs three more
LOONGARCH_EMPTY_HOWTO entries, or loongarch_elf_rtype_to_howto should
be testing for r_type < ARRAY_SIZE (loongarch_howto_table). I figure
it's worth wasting a little more space to get faster lookup.
* elfxx-loongarch.c (loongarch_howto_table): Add
LOONGARCH_EMPTY_HOWTO entries for 121..123.
(loongarch_elf_rtype_to_howto): Don't support slow lookup.
Assert exact table size and r_type indexing. Omit return cast.
(loongarch_reloc_name_lookup): Omit assertion and return cast.
(loongarch_reloc_type_lookup): Likewise.
Fix the ENOTDIR rmdir too.
PR 31191
* objcopy.c (copy_archive): Localise uses of "l". Remove
const from name_list.name. Unlink output element on bfd_close
error, and NULL list->name to indicate file is removed. Adjust
cleanup to prevent rmdir on non-existent file.
Since newlib allows people to opt-in to extra errno names, pull them
into our table too. The values don't conflict with each other -- the
newlib names & values are distinct from newlib's Linux compatibility.
1.The linker for each DESC generates a R_LARCH_TLS_DESC64 dynamic
relocation, which relocation is placed at .rela.dyn.
TLSDESC always allocates two GOT slots and one dynamic relocation
space to TLSDESC.
2. When using multiple ways to access the same TLS variable, a
maximum of 5 GOT slots are used. For example, using GD, TLSDESC,
and IE to access the same TLS variable, GD always uses the first
two of the five GOT, TLSDESC uses the third and fourth, and IE
uses the last.
This fixes the buffer overflow added in commit 22b78fad28, and a few
other problems.
* loongarch-coder.c (loongarch_split_args_by_comma): Don't
overflow buffer when args == "". Don't remove unbalanced
quotes. Don't trim last arg if max number of args exceeded.
Some spots loop on the frame chain to find the first next non-inline
frame, and pass that as the "next frame" to
value::allocate_register_lazy / value::allocate_register. This is
necessary if the value is used in the process of computing the id of
"this frame". If the frame next to "this frame" is inlined into "this
frame", then you that next frame won't have a computed id yet. You have
to go past that to find the next non-inline frame, which will have a
computed id.
In other cases, it's fine to store the id of an inline frame as the
"next frame id" in a register struct value. When trying to unwind a
register from it, it will just call inline_frame_prev_register, which
will forward the request to the next next frame, until we hit the next
physical frame.
I think it would make things simpler to just never store the id of an
inline frame as the next frame id of register struct values, and go with
the first next non-inline frame directly. This way, we don't have to
wonder which code paths have to skip inline frames when creating
register values and which don't.
So, change value::allocate_register_lazy to do that work, and remove the
loops for the callers that did it.
Change-Id: Ic88115dac49dc14e3053c95f92050062b24b7310
Remove VALUE_REGNUM, replace it with a method on struct value. Set
`m_location.reg.regnum` directly from value::allocate_register_lazy,
which is fine because allocate_register_lazy is a static creation
function for struct value.
Change-Id: Id632502357da971617d9dce1e2eab9b56dbcf52d
Remove VALUE_NEXT_FRAME_ID, replace it with a method on struct value. Set
`m_location.reg.next_frame_id` directly from value::allocate_register_lazy,
which is fine because allocate_register_lazy is a static creation
function for struct value.
Change-Id: Ic9f0f239c166a88dccfee836f9f51871e67548e6
As explained in the comment removed by the previous commit "gdb: pass
non-nullptr frame to gdbarch_value_from_register in
address_from_register", address_from_register copies some implementation
bits from value_from_register:
/* This routine may be called during early unwinding, at a time
where the ID of FRAME is not yet known. Calling value_from_register
would therefore abort in get_frame_id. However, since we only need
a temporary value that is never used as lvalue, we actually do not
really need to set its VALUE_NEXT_FRAME_ID. Therefore, we re-implement
the core of value_from_register, but use the null_frame_id. */
This is no longer relevant, since we now create a value with a valid next
frame id, so change address_from_register to use value_from_register.
Change-Id: I189bd96f28735ed9f47750ffd73764c459ec6f43
By now, all register struct values should have a valid next frame id
(assuming they are created using value::allocate_register or
value::allocate_register_lazy), so there should be no need to pass a
frame alongside the value to read_frame_register_value. Remove the
frame parameter and adjust read_frame_register_value accordingly.
While at it, make read_frame_register_value static, it's only used in
findvar.c.
Change-Id: I118959ef8c628499297c67810916e8ba9934bfac
Some places that create register struct values don't use register_type
to obtain the value type. This prevents them from using the current
version of value::allocate_register. One spot (value_of_register_lazy)
also creates a lazy register value.
Add a value::allocate_register_lazy method. Add some type parameters
to value::allocate_register and value::allocate_register_lazy, to let
the caller specify the type to use for the value. The parameters
default to nullptr, in which case we use register_type to obtain the
type.
Change-Id: I640ec0a5a0f4a55eba12d515dbfd25933229f8ec
address_from_register used to pass null_frame_id to
gdbarch_value_from_register as "this frame"'s id, because it's possible
for it to be called during unwind, when "this frame"'s id is not yet
known. This create an oddity where those register struct values are
created without a valid next frame id. I would much prefer for things
to be consistent and have all register struct values to have a valid
next frame id.
Since gdbarch_value_from_register takes a frame_info_ptr now, rather
than a frame_id, we can pass down "this frame", even if it doesn't have
a valid id. gdbarch_value_from_register implementations can obtain the
next frame from it.
However, it's possible for the "this frame"'s next frame to be an
inline frame, inlined in "this frame", in which case that next frame's
id is also not known. So, loop until we get to the next non-inline
frame (which is actually the frame where registers for "this frame" are
unwound from). This is the same thing that we do in
value_of_register_lazy, for the same reason. A later patch will factor
out this "while next frame is inline" loop to apply it to all register
struct values, so this is somewhat temporary.
Change-Id: If487c82620cc5a4a4ea5807f0a0bad80ab984078
