This patch fixes test failures power8 and power9 caused by changes on
opcodes:
The dissasembler does not emit whitespace for instructions
anymore (c2b1c27545)
The dissasembler generates extended mnemonics for some instructions
instead (aae9718e4d)
The ldmx instruction was removed. This instruction was never
implemented (6fbc939cfd)
gdb/testsuite/ChangeLog:
2020-02-03 Rogerio A. Cardoso <rcardoso@linux.ibm.com>
* gdb.arch/powerpc-power8.exp: Delete trailing whitespace of
tbegin., tend. instructions. Replace bctar-, bctar+, bctarl-,
bctarl+ extended mnemonics when avaliable by bgttar, bnstarl,
blttar, bnetarl.
* gdb.arch/powerpc-power8.s: Fix comments. Fix instructions
binary for blttar, bnetarl.
* gdb.arch/powerpc-power9.exp: Delete trailing whitespace of
wait instruction. Delete ldmx test.
* gdb.arch/powerpc-power9.s: Delete ldmx instruction.
New in v5:
- Use gdb_test_name for gdb_test_multiple.
- Use gdb_assert.
- Verify count matches the expected sigtraps exactly.
New in v4:
- Fix formatting nit in gdb/testsuite/gdb.arch/aarch64-brk-patterns.c.
New in v3:
- Minor formatting and code cleanups.
- Added count check to validate number of brk SIGTRAP's.
- Moved count to SIGTRAP check conditional block.
This test exercises the previous patch's code and makes sure GDB can
properly get a SIGTRAP from various brk instruction patterns.
GDB needs to be able to see the program exiting normally. If GDB doesn't
support the additional brk instructions, we will see timeouts.
We bail out with the first timeout since we won't be able to step through
the program breakpoint anyway, so it is no use carrying on.
gdb/testsuite/ChangeLog:
2020-01-29 Luis Machado <luis.machado@linaro.org>
* gdb.arch/aarch64-brk-patterns.c: New source file.
* gdb.arch/aarch64-brk-patterns.exp: New test.
The speed optimization from commit 5f6cac4085
made GDB skip reloading all symbols when the same symbol file is reloaded.
As a result, ARM targets only read the mapping symbols the first time we
load a symbol file. When reloaded, the speed optimization above will
cause an early return and gdbarch_record_special_symbol won't be called to
save mapping symbol data, which in turn affects disassembling of thumb
instructions.
First load and correct disassemble output:
Dump of assembler code for function main:
0x0000821c <+0>: bx pc
0x0000821e <+2>: nop
0x00008220 <+4>: mov r0, #0
0x00008224 <+8>: bx lr
Second load and incorrect disassemble output:
Dump of assembler code for function main:
0x0000821c <+0>: bx pc
0x0000821e <+2>: nop
0x00008220 <+4>: movs r0, r0
0x00008222 <+6>: b.n 0x8966
0x00008224 <+8>: vrhadd.u16 d14, d14, d31
This happens because the mapping symbol data is stored in an objfile_key-based
container, and that data isn't preserved across the two symbol loading
operations.
The following patch fixes this by storing the mapping symbol data in a
bfd_key-based container, which doesn't change as long as the bfd is the same.
I've also added a new test to verify the correct disassemble output.
gdb/ChangeLog:
2019-11-01 Luis Machado <luis.machado@linaro.org>
PR gdb/25124
* arm-tdep.c (arm_per_objfile): Rename to ...
(arm_per_bfd): ... this.
(arm_objfile_data_key): Rename to ...
(arm_bfd_data_key): ... this.
(arm_find_mapping_symbol): Adjust access to new bfd_key-based
data.
(arm_record_special_symbol): Likewise.
gdb/testsuite/ChangeLog:
2019-11-01 Luis Machado <luis.machado@linaro.org>
PR gdb/25124
* gdb.arch/pr25124.S: New file.
* gdb.arch/pr25124.exp: New file.
Change-Id: I22c3e6ebe9bfedad66d56fe9656994fa1761c485
On my openSUSE Leap 15.1 x86_64 Skylake system with the default (4.12) kernel,
I run into:
...
FAIL: gdb.base/gcore.exp: corefile restored all registers
...
The problem is that there's a difference in the mxcsr register value before
and after the gcore command:
...
- mxcsr 0x0 [ ]
+ mxcsr 0x400440 [ DAZ OM ]
...
This can be traced back to amd64_linux_nat_target::fetch_registers, where
xstateregs is partially initialized by the ptrace call:
...
char xstateregs[X86_XSTATE_MAX_SIZE];
struct iovec iov;
amd64_collect_xsave (regcache, -1, xstateregs, 0);
iov.iov_base = xstateregs;
iov.iov_len = sizeof (xstateregs);
if (ptrace (PTRACE_GETREGSET, tid,
(unsigned int) NT_X86_XSTATE, (long) &iov) < 0)
perror_with_name (_("Couldn't get extended state status"));
amd64_supply_xsave (regcache, -1, xstateregs);
...
after which amd64_supply_xsave is called.
The amd64_supply_xsave call is supposed to only use initialized parts of
xstateregs, but due to a kernel bug on intel skylake (fixed from 4.14 onwards
by commit 0852b374173b "x86/fpu: Add FPU state copying quirk to handle XRSTOR
failure on Intel Skylake CPUs") it can happen that the mxcsr part of
xstateregs is not initialized, while amd64_supply_xsave expects it to be
initialized, which explains the FAIL mentioned above.
Fix the undetermined behaviour by initializing xstateregs before calling
ptrace, which makes sure we get a 0x0 for mxcsr when this kernel bug occurs,
and which also happens to fix the FAIL.
Furthermore, add an xfail for this FAIL which triggers the same kernel bug:
...
FAIL: gdb.arch/amd64-init-x87-values.exp: check_setting_mxcsr_before_enable: \
check new value of MXCSR is still in place
...
Both FAILs pass when using a 5.3 kernel instead on the system mentioned above.
Tested on x86_64-linux.
gdb/ChangeLog:
2019-09-24 Tom de Vries <tdevries@suse.de>
PR gdb/23815
* amd64-linux-nat.c (amd64_linux_nat_target::fetch_registers):
Initialize xstateregs before ptrace PTRACE_GETREGSET call.
gdb/testsuite/ChangeLog:
2019-09-24 Tom de Vries <tdevries@suse.de>
PR gdb/24598
* gdb.arch/amd64-init-x87-values.exp: Add xfail.
When saving registers to the stack at the start of a function, not all state
needs to be saved. For example, only the first 64bits of float registers need
saving. However, a program may choose to store extra state if it wishes,
there is nothing preventing it doing so.
The aarch64_analyze_prologue will error if it detects extra state being
stored. Relex this restriction.
Tested via aarch64-prologue test.
gdb/ChangeLog:
* aarch64-tdep.c (aarch64_analyze_prologue): Allow any valid
register sizes.
gdb/testsuite/ChangeLog:
* gdb.arch/aarch64-prologue.c: New test.
* gdb.arch/aarch64-prologue.exp: New file.
I ran into this error:
...
ERROR: tcl error sourcing gdb/testsuite/gdb.arch/i386-pkru.exp.
ERROR: missing "
while executing
"untested ""
invoked from within
"if { [prepare_for_testing "failed to prepare" ${testfile} ${srcfile} \
[list debug additional_flags=${comp_flags}]] } {
untested "failed to c..."
(file "gdb/testsuite/gdb.arch/i386-pkru.exp" line 25)
invoked from within
...
caused by:
...
untested "failed to compile x86 PKEYS test.
...
Fix the unterminated string.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-07-26 Tom de Vries <tdevries@suse.de>
* gdb.arch/i386-pkru.exp: Fix unterminated string.
GDB is not able to execute "step" command on function calls of Armv8-M cmse secure entry functions.
Everytime GNU linker come across definition of any cmse secure entry function in object file(s),
it creates two new instructions secure gateway (sg) and original branch destination (b.w),
place those two instructions in ".gnu.sgstubs" section of executable.
Any function calls to these cmse secure entry functions is re-directed through secure gateway (sg)
present in ".gnu.sgstubs" section.
Example:
Following is a function call to cmse secure entry function "foo":
...
bl xxxx <foo> --->(a)
...
<foo>
xxxx: push {r7, lr}
GNU linker on finding out "foo" is a cmse secure entry function, created sg and b.w instructions and
place them in ".gnu.sgstubs" section (marked by c).
The "bl" instruction (marked by a) which is a call to cmse secure entry function is modified by GNU linker
(as marked by b) and call flow is re-directly through secure gateway (sg) in ".gnu.sgstubs" section.
...
bl yyyy <foo> ---> (b)
...
section .gnu.sgstubs: ---> (c)
yyyy <foo>
yyyy: sg // secure gateway
b.w xxxx <__acle_se_foo> // original_branch_dest
...
0000xxxx <__acle_se_foo>
xxxx: push {r7, lr} ---> (d)
On invoking GDB, when the control is at "b" and we pass "step" command, the pc returns "yyyy"
(sg address) which is a trampoline and which does not exist in source code. So GDB jumps
to next line without jumping to "__acle_se_foo" (marked by d).
The above details are published on the Arm website [1], please refer to section 5.4 (Entry functions)
and section 3.4.4 (C level development flow of secure code).
[1] https://developer.arm.com/architectures/cpu-architecture/m-profile/docs/ecm0359818/latest/armv8-m-security-extensions-requirements-on-development-tools-engineering-specification
This patch fixes above problem by returning target pc "xxxx" to GDB on executing "step"
command at "b", so that the control jumps to "__acle_se_foo" (marked by d).
gdb/ChangeLog:
* arm-tdep.c (arm_skip_cmse_entry): New function.
(arm_is_sgstubs_section): New function.
(arm_skip_stub): Add call to arm_skip_cmse_entry function.
gdb/testsuite/ChangeLog:
* gdb.arch/arm-cmse-sgstubs.c: New test.
* gdb.arch/arm-cmse-sgstubs.exp: New file.
When making inferior function calls GDB sets up a dummy code region on
the stack, and places a breakpoint within that region. If the random
stack contents appear to be a compressed instruction then GDB will
place a compressed breakpoint, which can cause problems if the target
doesn't support compressed instructions.
This commit prevents this issue by writing a 4-byte nop instruction to
the dummy region at the time the region is allocated. With this nop
instruction in place, when we come to insert the breakpoint then an
uncompressed breakpoint will be used.
This is similar to other targets, for example mips.
gdb/ChangeLog:
* riscv-tdep.c (riscv_push_dummy_code): Write a 4-byte nop
instruction to the dummy code region.
gdb/testsuite/ChangeLog:
* gdb.arch/riscv-bp-infcall.c: New file.
* gdb.arch/riscv-bp-infcall.exp: New file.
It was observed that in some cases, placing a breakpoint in an
assembler file using filename:line-number syntax would result in the
breakpoint being placed at a different line within the file.
For example, consider this x86-64 assembler:
test:
push %rbp /* Break here. */
mov %rsp, %rbp
nop /* Stops here. */
The user places the breakpoint using file:line notation targeting the
line marked 'Break here', GDB actually stops at the line marked 'Stops
here'.
The reason is that the label 'test' is identified as the likely start
of a function, and the call to symtab.c:skip_prologue_sal causes GDB
to skip forward over the instructions that GDB believes to be part of
the prologue.
I believe however, that when debugging assembler code, where the user
has instruction-by-instruction visibility, if they ask for a specific
line, GDB should (as far as possible) stop on that line, and not
perform any prologue skipping. I don't believe that the behaviour of
higher level languages should change, in these cases skipping the
prologue seems like the correct thing to do.
In order to implement this change I needed to extend our current
tracking of when the user has requested an explicit line number. We
already tracked this in some cases, but not in others (see the changes
in linespec.c). However, once I did this I started to see some
additional failures (in tests gdb.base/break-include.exp
gdb.base/ending-run.exp gdb.mi/mi-break.exp gdb.mi/mi-reverse.exp
gdb.mi/mi-simplerun.exp) where we currently expected a breakpoint
placed at one file and line number to be updated to reference a
different line number, this was fixed by removing some code in
symtab.c:skip_prologue_sal. My concern here is that removing this
check didn't cause anything else to fail.
I have a new test that covers my original case, this is written for
x86-64 as most folk have access to such a target, however, any
architecture that has a prologue scanner can be impacted by this
change.
gdb/ChangeLog:
* linespec.c (decode_digits_list_mode): Set explicit_line to a
bool value.
(decode_digits_ordinary): Set explicit_line field in sal.
* symtab.c (skip_prologue_sal): Don't skip prologue for a
symtab_and_line that was set on an explicit line number in
assembler code. Do always update the recorded symtab and line if
we do skip the prologue.
gdb/testsuite/ChangeLog:
* gdb.arch/amd64-break-on-asm-line.S: New file.
* gdb.arch/amd64-break-on-asm-line.exp: New file.
Remove the use of 'I' within some comments in a recently added test.
gdb/testsuite/ChangeLog:
* gdb.arch/riscv-unwind-long-insn-6.s: Remove use of 'I' in
comment.
* gdb.arch/riscv-unwind-long-insn-8.s: Likewise.
If the RISC-V prologue scanner finds a 6 or 8 byte instruction we
currently throw an internal error, which is not great for the user.
A mechanism already exists in the prologue scanner to leave
instructions marked as unknown so that we can stop the prologue scan
without raising an error, this is used for all 2 and 4 byte
instructions that are not part of the small set the prologue scanner
actually understands.
This commit changes GDB so that all 6 and 8 byte instructions are
marked as unknown, rather than causing an error.
gdb/ChangeLog:
* riscv-tdep.c (riscv_insn::decode): Gracefully ignore
instructions of lengths 6 or 8 bytes.
gdb/testsuite/ChangeLog:
* gdb.arch/riscv-unwind-long-insn-6.s: New file.
* gdb.arch/riscv-unwind-long-insn-8.s: New file.
* gdb.arch/riscv-unwind-long-insn.c: New file.
* gdb.arch/riscv-unwind-long-insn.exp: New file.
Running an address signed binary through GDB on a non pauth system
gives the following error:
Call Frame Instruction op 45 in vendor extension space is not handled on this architecture.
Instead GDB should ignore the op, treating it as a nop.
Add test case for pauth binaries, regardless of whether the target
supports it.
gdb/ChangeLog:
* aarch64-tdep.c (aarch64_execute_dwarf_cfa_vendor_op): Treat
DW_CFA_AARCH64_negate_ra_state as nop on non pauth targets.
gdb/testsuite/ChangeLog:
* gdb.arch/aarch64-pauth.c: New test.
* gdb.arch/aarch64-pauth.exp: New file.
When building gdb on ubuntu 16.04 with gcc 5.4.0, and running the gdb
testsuite we run into failures due test-cases requiring at least c++1.
Fix this by adding -std=c++11 to those test-cases.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-05-21 Tom de Vries <tdevries@suse.de>
* gdb.arch/amd64-eval.exp: Require c++11.
* gdb.base/max-depth.exp: Same.
* gdb.compile/compile-cplus-array-decay.exp: Same.
* gdb.cp/meth-typedefs.exp: Same.
* gdb.cp/subtypes.exp: Same.
* gdb.cp/temargs.exp: Same.
The test-case gdb.arch/amd64-tailcall-self.exp fails here:
...
if ![runto b] {
return -1
}
...
like:
...
(gdb) file build/gdb/testsuite/outputs/gdb.arch/amd64-tailcall-self/\
amd64-tailcall-self
Reading symbols from build/gdb/testsuite/outputs/gdb.arch/\
amd64-tailcall-self/amd64-tailcall-self...
Dwarf Error: Cannot find DIE at 0x1f5 referenced from DIE at 0x107 [in \
module build/gdb/testsuite/outputs/gdb.arch/amd64-tailcall-self/\
amd64-tailcall-self]
...
The problem is that in amd64-tailcall-self.S, CU-relative references are
assigned .debug_info section relative values. [ This is similar to the
problem fixed by "Fix gdb.arch/amd64-entry-value-paramref.S". ]
Fix this by assigning CU-relative references instead.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-05-09 Tom de Vries <tdevries@suse.de>
* gdb.arch/amd64-tailcall-self.S: Make DW_FORM_ref4 references
CU-relative.
The file gdb.arch/amd64-entry-value-paramref.S contains a DIE for function
bar:
...
DIE29: .uleb128 0x2 # (DIE (0x29) DW_TAG_subprogram)
.ascii "bar\0" # DW_AT_name
.byte 0x1 # DW_AT_decl_file (gdb.arch/amd64-entry-value-paramref.cc)
.byte 0x15 # DW_AT_decl_line
.long DIE45 # DW_AT_type
.byte 0x1 # DW_AT_inline
...
which refers to DIE45:
...
DIE45: .uleb128 0x4 # (DIE (0x45) DW_TAG_base_type)
.byte 0x4 # DW_AT_byte_size
.byte 0x5 # DW_AT_encoding
.ascii "int\0" # DW_AT_name
...
using a form DW_FORM_ref4:
...
.uleb128 0x2 # (abbrev code)
.uleb128 0x2e # (TAG: DW_TAG_subprogram)
.byte 0x1 # DW_children_yes
...
.uleb128 0x49 # (DW_AT_type)
.uleb128 0x13 # (DW_FORM_ref4)
...
However, the DW_FORM_ref4 is a CU-relative reference, while using a label for
the value will result in a section-relative value.
So, if linked in object files contain dwarf info and are placed in the
.debug_info section before the compilation units generated from
amd64-entry-value-paramref.S, then the referenced type is at 0x108:
...
<1><108>: Abbrev Number: 4 (DW_TAG_base_type)
<109> DW_AT_byte_size : 4
<10a> DW_AT_encoding : 5 (signed)
<10b> DW_AT_name : int
...
but the reference will point to a non-existing DIE at 0x1cf:
...
<1><f0>: Abbrev Number: 2 (DW_TAG_subprogram)
<f1> DW_AT_name : bar
<f5> DW_AT_decl_file : 1
<f6> DW_AT_decl_line : 21
<f7> DW_AT_type : <0x1cf>
<fb> DW_AT_inline : 1 (inlined)
...
which happens to cause a GDB internal error described in PR23270 - "GDB
internal error: dwarf2read.c:18656: internal-error: could not find partial
DIE 0x1b7 in cache".
Fix the invalid DWARF by making the reference value CU-relative:
...
- .long DIE45 # DW_AT_type
+ .long DIE45 - .Ldebug_info0 # DW_AT_type
...
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-05-09 Tom de Vries <tdevries@suse.de>
* gdb.arch/amd64-entry-value-paramref.S: Make DW_FORM_ref4 references
CU-relative.
Commit 4aa866af ("Fix AMD64 return value ABI in expression
evaluation") introduced a regression when calling a function with a
structure that contains bitfields.
Because the caller of amd64_has_unaligned_fields handles bitfields
already, it seemed to me that the simplest fix was to ignore bitfields
here.
gdb/ChangeLog
2019-04-24 Tom Tromey <tromey@adacore.com>
* amd64-tdep.c (amd64_has_unaligned_fields): Ignore bitfields.
gdb/testsuite/ChangeLog
2019-04-24 Tom Tromey <tromey@adacore.com>
* gdb.arch/amd64-eval.exp: Test bitfield return.
* gdb.arch/amd64-eval.cc (struct Bitfields): New.
(class Foo) <return_bitfields>: New method.
(main): Call it.
The AMD64 System V ABI specifies that when a function has a return type
classified as MEMORY, the caller provides space for the value and passes
the address to this space as the first argument to the function (before
even the "this" pointer). The classification of MEMORY is applied to
struct that are sufficiently large, or ones with unaligned fields.
The expression evaluator uses call_function_by_hand to call functions,
and the hand-built frame has to push arguments in a way that matches the
ABI of the called function. call_function_by_hand supports ABI-based
struct returns, based on the value of gdbarch_return_value, however on
AMD64 the implementation of the classifier incorrectly assumed that all
non-POD types (implemented as "all types with a base class") should be
classified as MEMORY and use the struct return.
This ABI mismatch resulted in issues when calling a function that returns
a class of size <16 bytes which has a base class, including issues such
as the "this" pointer being incorrect (as it was passed as the second
argument rather than the first).
This is now fixed by checking for field alignment rather than POD-ness,
and a testsuite is added to test expression evaluation for AMD64.
gdb/ChangeLog:
* amd64-tdep.c (amd64_classify_aggregate): Use cp_pass_by_reference
rather than a hand-rolled POD check when checking for forced MEMORY
classification.
gdb/testsuite/ChangeLog:
* gdb.arch/amd64-eval.cc: New file.
* gdb.arch/amd64-eval.exp: New file.
gdb/testsuite/ChangeLog
2019-02-12 Weimin Pan <weimin.pan@oracle.com>
PR breakpoints/21870
* gdb.arch/aarch64-dbreg-contents.exp: New file.
* gdb.arch/aarch64-dbreg-contents.c: New file.
This patch defines pseudo-registers "v0" through "v31" as aliases that
map to the corresponding raw "vr0" through "vr31" vector registers for
Power.
The motivation behind this is that although GDB defines these
registers as "vrX", the disassembler prints them as "vX", e.g. as the
operands in instructions such as "vaddubm v2,v1,v1". This can be
confusing to users trying to print out the values of the operands
while inspecting the disassembled code.
The new aliases are made not to belong to any register group, to avoid
duplicated values in "info register vector" and "info register all".
The arch-specific rs6000_pseudo_register_reggroup_p function had
previously been removed since the other pseudo-registers could have
their groups inferred by their type. It restored with this patch to
handle the aliases. Membership for the other pseudo-registers is
still determined using the default function.
A new tests checks that GDB prints the expected values of vector
registers after they are filled by the inferior, by using both the raw
names and the aliases. Two other existing tests are modified to also
test the aliases.
gdb/ChangeLog:
2019-01-14 Pedro Franco de Carvalho <pedromfc@linux.ibm.com>
* ppc-tdep.h (struct gdbarch_tdep) <ppc_v0_alias_regnum>: New
field.
* rs6000-tdep.c: Include reggroups.h.
(IS_V_ALIAS_PSEUDOREG): Define.
(rs6000_register_name): Return names for the "vX" aliases.
(rs6000_pseudo_register_type): Return type for the "vX" aliases.
(rs6000_pseudo_register_reggroup_p): Restore. Handle "vX"
aliases. Call default_register_reggroup_p for all other
pseudo-registers.
(v_alias_pseudo_register_read, v_alias_pseudo_register_write):
New functions.
(rs6000_pseudo_register_read, rs6000_pseudo_register_write):
Handle "vX" aliases.
(v_alias_pseudo_register_collect): New function.
(rs6000_ax_pseudo_register_collect): Handle "vX" aliases.
(rs6000_gdbarch_init): Initialize "vX" aliases as
pseudo-registers. Restore registration of
rs6000_pseudo_register_reggroup_p with
set_tdesc_pseudo_register_reggroup_p.
gdb/testsuite/ChangeLog:
2019-01-14 Pedro Franco de Carvalho <pedromfc@linux.ibm.com>
* gdb.arch/vsx-regs.exp: Add tests that use the vector register
aliases.
* gdb.arch/altivec-regs.exp: Likewise. Fix indentation of two
tests.
* gdb.arch/powerpc-vector-regs.c: New file.
* gdb.arch/powerpc-vector-regs.exp: New file.
gdb/doc/ChangeLog:
2019-01-14 Pedro Franco de Carvalho <pedromfc@linux.ibm.com>
* gdb.texinfo (PowerPC Features): Document the alias
pseudo-registers for the org.gnu.gdb.power.altivec feature.
This patch fixes one of the tests in gdb.arch/altivec-regs.exp that
was passing an incorrect list to gdb_expect_list, which always
matched.
gdb/testsuite/ChangeLog:
2019-01-14 Pedro Franco de Carvalho <pedromfc@linux.ibm.com>
* gdb.arch/altivec-regs.exp: Fix the list passed to
gdb_expect_list when testing "info vector".
This commit applies all changes made after running the gdb/copyright.py
script.
Note that one file was flagged by the script, due to an invalid
copyright header
(gdb/unittests/basic_string_view/element_access/char/empty.cc).
As the file was copied from GCC's libstdc++-v3 testsuite, this commit
leaves this file untouched for the time being; a patch to fix the header
was sent to gcc-patches first.
gdb/ChangeLog:
Update copyright year range in all GDB files.
Various tests use test code written in i386 / x86_64 assembly that cannot
be used to create PIE executables. Therefore compilation of test programs
failed on systems where the compiler default is to create PIE executable.
The solution is to use -no-pie linker flag, however, such flag may not
(is not) supported by all compilers GDB needs to support (e.g. gcc 4.8).
To handle this, introduce a new flag to gdb_compile - nopie - which
inserts -no-pie linker flag where supported and is no-op where it is
not. By default, -no-pie flag is inserted since most modern compiler do
support it.
The three AVX512 state components are entirely independent - one being
in its "init state" has no implication whatsoever on either of the other
two. Fully separate X86_XSTATE_ZMM_H and X86_XSTATE_ZMM handling, to
prevent upper halves of the upper 16 ZMM registers to display as if they
were zero (when they aren't) after e.g. VZEROALL/VZEROUPPER.
Update gdb.arch/riscv-reg-aliases.exp test to support targets without
floating point registers.
gdb/testsuite/ChangeLog:
* gdb.arch/riscv-reg-aliases.exp: Handle targets without floating
point hardware.
In AIX if gdb is debugging an application which has a signal handler
and reaches the signal handler frame, then we need to read the back
chain address from sigcontext saved on the stack, similarly the LR.
As backchain at an offset 0 will be 0, because we will have a
sigconext saved after the minimum stack size. So the correct
backchain will be at an offset after minimum stack and the LR at
an offset 8 will be of the signal millicode address.
If the back chain pointer is NULL and the LR field is in the kernel
segment(ex. 0x00004a14) then we can probably assume we are in a
signal handler.
sample output
(gdb) bt
0 sig_handle_aix (signo=11) at aix-sighandle.c:7
1 0x0000000000004a94 in ?? ()
(gdb)
expected output
(gdb) bt
0 sig_handle_aix (signo=11) at aix-sighandle.c:7
1 <signal handler called>
2 0x0000000100000748 in foo () at aix-sighandle.c:14
3 0x000000010000079c in main () at aix-sighandle.c:19
gdb/ChangeLog:
2018-11-01 Sangamesh Mallayya <sangamesh.swamy@in.ibm.com>
* rs6000-aix-tdep.c: Include "trad-frame.h" and "frame-unwind.h".
(SIG_FRAME_LR_OFFSET64): New define.
(SIG_FRAME_FP_OFFSET64): New define.
(aix_sighandle_frame_cache): New Function.
(aix_sighandle_frame_this_id): New Function.
(aix_sighandle_frame_prev_register): New Function.
(aix_sighandle_frame_sniffer): New Function.
(aix_sighandle_frame_unwind): New global variable.
(rs6000_aix_init_osabi): Install new frame unwinder.
gdb/testsuite/ChangeLog:
2018-11-01 Sangamesh Mallayya <sangamesh.swamy@in.ibm.com>
* gdb.arch/aix-sighandle.c: New file.
* gdb.arch/aix-sighandle.exp: New file.
The gdb.arch/riscv-reg-aliases.exp test didn't take into account that
on RV64 (and RV128) the floating point registers are represented as a
union. This patch updates the test to handle this.
Tested against RV32 and RV64.
gdb/testsuite/ChangeLog:
* gdb.arch/riscv-reg-aliases.exp: Rewrite to take account of float
registers being unions.
In the 'info -q -t' patch series, I started a new test from
gdb.threads/threadapply.exp, that uses an obsolete way to do
runto_main.
This patch changes all occurrences of runto_main using gdb_suppress_tests
to use instead fail+return.
Note that there are still about 220 occurrences of gdb_suppress_tests
but unclear (to me) if these can be similarly trivially be replaced by a
fail+return. Further cleanup can be done in follow-up patches.
Tests run on Debian/x86_64.
gdb/testsuite/ChangeLog
2018-10-27 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.arch/altivec-regs.exp: Do not use gdb_suppress_tests in
runto_main, use fail + return instead.
gdb.arch/amd64-byte.exp: Likewise.
gdb.arch/amd64-dword.exp: Likewise.
gdb.arch/amd64-word.exp: Likewise.
gdb.arch/e500-abi.exp: Likewise.
gdb.arch/e500-regs.exp: Likewise.
gdb.arch/gdb1291.exp: Likewise.
gdb.arch/gdb1431.exp: Likewise.
gdb.arch/i386-avx.exp: Likewise.
gdb.arch/i386-byte.exp: Likewise.
gdb.arch/i386-prologue.exp: Likewise.
gdb.arch/i386-sse.exp: Likewise.
gdb.arch/i386-word.exp: Likewise.
gdb.arch/iwmmxt-regs.exp: Likewise.
gdb.arch/pa-nullify.exp: Likewise.
gdb.arch/powerpc-prologue.exp: Likewise.
gdb.arch/s390-tdbregs.exp: Likewise.
gdb.arch/vsx-regs.exp: Likewise.
gdb.asm/asm-source.exp: Likewise.
gdb.base/auxv.exp: Likewise.
gdb.base/bigcore.exp: Likewise.
gdb.base/overlays.exp: Likewise.
gdb.base/savedregs.exp: Likewise.
gdb.base/setshow.exp: Likewise.
gdb.base/sigaltstack.exp: Likewise.
gdb.base/sigbpt.exp: Likewise.
gdb.base/siginfo-addr.exp: Likewise.
gdb.base/siginfo-obj.exp: Likewise.
gdb.base/siginfo-thread.exp: Likewise.
gdb.base/siginfo.exp: Likewise.
gdb.base/signull.exp: Likewise.
gdb.base/sigrepeat.exp: Likewise.
gdb.base/structs2.exp: Likewise.
gdb.threads/threadapply.exp: Likewise.
gdb.threads/watchthreads.exp: Likewise.
gdb.threads/watchthreads2.exp: Likewise.
This patch adds support for Hardware Transactional Memory registers
for the powerpc linux native and core file targets, and for the
pwoerpc linux server stub.
These registers include both the HTM special-purpose registers (TFHAR,
TEXASR and TFIAR) as well as the set of registers that are
checkpointed (saved) when a transaction is initiated, which the
processor restores in the event of a transaction failure.
The set of checkpointed general-purpose registers is returned by the
linux kernel in the same format as the regular general-purpose
registers, defined in struct pt_regs. However, the architecture
specifies that only some of the registers present in pt_regs are
checkpointed (GPRs 0-31, CR, XER, LR and CTR). The kernel fills the
slots for MSR and NIP with other info. The other fields usually don't
have meaningful values. GDB doesn't define registers that are not
checkpointed in the architecture, but when generating a core file, GDB
fills the slot for the checkpointed MSR with the regular MSR. These
are usually similar, although some bits might be different, and in
some cases the checkpointed MSR will have a value of 0 in a
kernel-generated core-file. The checkpointed NIP is filled with TFHAR
by GDB in the core-file, which is what the kernel does. The other
fields are set to 0 by GDB.
Core files generated by the kernel have a note section for
checkpointed GPRs with the same size for both 32-bit and 64-bit
threads, and the values for the registers of a 32-bit thread are
squeezed in the first half, with no useful data in the second half.
GDB generates a smaller note section for 32-bit threads, but can read
both sizes.
The checkpointed XER is required to be 32-bit in the target
description documentation, even though the more recent ISAs define it
as 64-bit wide, since the high-order 32-bits are reserved, and because
in Linux there is no way to get a 64-bit checkpointed XER for 32-bit
threads. If this changes in the future, the target description
feature requirement can be relaxed to allow for a 64-bit checkpointed
XER.
Access to the checkpointed CR (condition register) can be confusing.
The architecture only specifies that CR fields 1 to 7 (the 24 least
significant bits) are checkpointed, but the kernel provides all 8
fields (32 bits). The value of field 0 is not masked by ptrace, so it
will sometimes show the result of some kernel operation, probably
treclaim., which sets this field.
The checkpointed registers are marked not to be saved and restored.
Inferior function calls during an active transaction don't work well,
and it's unclear what should be done in this case. TEXASR and TFIAR
can be altered asynchronously, during transaction failure recording,
so they are also not saved and restored. For consistency neither is
TFHAR.
Record and replay also doesn't work well when transactions are
involved. This patch doesn't address this, so the values of the HTM
SPRs will sometimes be innacurate when the record/relay target is
enabled. For instance, executing a "tbegin." alters TFHAR and TEXASR,
but these changes are not currently recorded.
Because the checkpointed registers are only available when a
transaction is active (or suspended), ptrace can return ENODATA when
gdb tries to read these registers and the inferior is not in a
transactional state. The registers are set to the unavailable state
when this happens. When gbd tries to write to one of these registers,
and it is unavailable, an error is raised.
The "fill" functions for checkpointed register sets in the server stub
are not implemented for the same reason as for the EBB register set,
since ptrace can also return ENODATA for checkpointed regsets. The
same issues with 'G' packets apply here.
Just like for the EBB registers, tracepoints will not mark the
checkpointed registers as unavailable if the inferior was not in a
transaction, so their content will also show 0 instead of
<unavailable> when inspecting trace data.
The new tests record the values of the regular registers before
stepping the inferior through a "tbegin." instruction to start a
transaction, then the checkpointed registers are checked against the
recorded pre-transactional values. New values are written to the
checkpointed registers and recorded, the inferior continues until the
transaction aborts (which is usually immediately when it is resumed),
and the regular registers are checked against the recorded values,
because the abort should have reverted the registers to these values.
Like for the EBB registers, target_store_registers will ignore the
checkpointed registers when called with -1 as the regno
argument (store all registers in one go).
gdb/ChangeLog:
2018-10-26 Edjunior Barbosa Machado <emachado@linux.vnet.ibm.com>
Pedro Franco de Carvalho <pedromfc@linux.ibm.com>
* arch/ppc-linux-tdesc.h (tdesc_powerpc_isa207_htm_vsx32l)
(tdesc_powerpc_isa207_htm_vsx64l): Declare.
* arch/ppc-linux-common.h (PPC_LINUX_SIZEOF_TM_SPRREGSET)
(PPC32_LINUX_SIZEOF_CGPRREGSET, PPC64_LINUX_SIZEOF_CGPRREGSET)
(PPC_LINUX_SIZEOF_CFPRREGSET, PPC_LINUX_SIZEOF_CVMXREGSET)
(PPC_LINUX_SIZEOF_CVSXREGSET, PPC_LINUX_SIZEOF_CPPRREGSET)
(PPC_LINUX_SIZEOF_CDSCRREGSET, PPC_LINUX_SIZEOF_CTARREGSET):
Define.
(struct ppc_linux_features) <htm>: New field.
(ppc_linux_no_features): Add initializer for htm field.
* arch/ppc-linux-common.c (ppc_linux_match_description): Return
new tdescs.
* nat/ppc-linux.h (PPC_FEATURE2_HTM, NT_PPC_TM_CGPR)
(NT_PPC_TM_CFPR, NT_PPC_TM_CVMX, NT_PPC_TM_CVSX)
(NT_PPC_TM_SPR, NT_PPC_TM_CTAR, NT_PPC_TM_CPPR, NT_PPC_TM_CDSCR):
Define if not already defined.
* features/Makefile (WHICH): Add rs6000/powerpc-isa207-htm-vsx32l
and rs6000/powerpc-isa207-htm-vsx64l.
(XMLTOC): Add rs6000/powerpc-isa207-htm-vsx32l.xml and
rs6000/powerpc-isa207-htm-vsx64l.xml.
* features/rs6000/power-htm-spr.xml: New file.
* features/rs6000/power-htm-core.xml: New file.
* features/rs6000/power64-htm-core.xml: New file.
* features/rs6000/power-htm-fpu.xml: New file.
* features/rs6000/power-htm-altivec.xml: New file.
* features/rs6000/power-htm-vsx.xml: New file.
* features/rs6000/power-htm-ppr.xml: New file.
* features/rs6000/power-htm-dscr.xml: New file.
* features/rs6000/power-htm-tar.xml: New file.
* features/rs6000/powerpc-isa207-htm-vsx32l.xml: New file.
* features/rs6000/powerpc-isa207-htm-vsx64l.xml: New file.
* features/rs6000/powerpc-isa207-htm-vsx32l.c: Generate.
* features/rs6000/powerpc-isa207-htm-vsx64l.c: Generate.
* regformats/rs6000/powerpc-isa207-htm-vsx32l.dat: Generate.
* regformats/rs6000/powerpc-isa207-htm-vsx64l.dat: Generate.
* ppc-linux-nat.c (fetch_register, fetch_ppc_registers): Call
fetch_regset with HTM regsets.
(store_register, store_ppc_registers): Call store_regset with HTM
regsets.
(ppc_linux_nat_target::read_description): Set htm field in the
features struct if needed.
* ppc-linux-tdep.c: Include
features/rs6000/powerpc-isa207-htm-vsx32l.c and
features/rs6000/powerpc-isa207-htm-vsx64l.c.
(ppc32_regmap_tm_spr, ppc32_regmap_cgpr, ppc64_le_regmap_cgpr)
(ppc64_be_regmap_cgpr, ppc32_regmap_cfpr, ppc32_le_regmap_cvmx)
(ppc32_be_regmap_cvmx, ppc32_regmap_cvsx, ppc32_regmap_cppr)
(ppc32_regmap_cdscr, ppc32_regmap_ctar): New globals.
(ppc32_linux_tm_sprregset, ppc32_linux_cgprregset)
(ppc64_be_linux_cgprregset, ppc64_le_linux_cgprregset)
(ppc32_linux_cfprregset, ppc32_le_linux_cvmxregset)
(ppc32_be_linux_cvmxregset, ppc32_linux_cvsxregset)
(ppc32_linux_cpprregset, ppc32_linux_cdscrregset)
(ppc32_linux_ctarregset): New globals.
(ppc_linux_cgprregset, ppc_linux_cvmxregset): New functions.
(ppc_linux_collect_core_cpgrregset): New function.
(ppc_linux_iterate_over_regset_sections): Call back with the htm
regsets.
(ppc_linux_core_read_description): Check if the tm spr section is
present and set htm in the features struct.
(_initialize_ppc_linux_tdep): Call
initialize_tdesc_powerpc_isa207_htm_vsx32l and
initialize_tdesc_powerpc_isa207_htm_vsx64l.
* ppc-linux-tdep.h (ppc_linux_cgprregset, ppc_linux_cvmxregset):
Declare.
(ppc32_linux_tm_sprregset, ppc32_linux_cfprregset)
(ppc32_linux_cvsxregset, ppc32_linux_cpprregset)
(ppc32_linux_cdscrregset, ppc32_linux_ctarregset): Declare.
* ppc-tdep.h (struct gdbarch_tdep) <have_htm_spr, have_htm_core>:
New fields.
<have_htm_fpu, have_htm_altivec, have_htm_vsx>:
Likewise.
<ppc_cppr_regnum, ppc_cdscr_regnum, ppc_ctar_regnum>: Likewise.
<ppc_cdl0_regnum, ppc_cvsr0_regnum, ppc_cefpr0_regnum>: Likewise.
(enum) <PPC_TFHAR_REGNUM, PPC_TEXASR_REGNUM, PPC_TFIAR_REGNUM>:
New enum fields.
<PPC_CR0_REGNUM, PPC_CCR_REGNUM, PPC_CXER_REGNUM>: Likewise.
<PPC_CLR_REGNUM, PPC_CCTR_REGNUM, PPC_CF0_REGNUM>: Likewise.
<PPC_CFPSCR_REGNUM, PPC_CVR0_REGNUM, PPC_CVSCR_REGNUM>: Likewise.
<PPC_CVRSAVE_REGNUM, PPC_CVSR0_UPPER_REGNUM>: Likewise.
<PPC_CPPR_REGNUM, PPC_CDSCR_REGNUM>: Likewise.
<PPC_CTAR_REGNUM>: Likewise.
(PPC_IS_TMSPR_REGNUM, PPC_IS_CKPTGP_REGNUM, PPC_IS_CKPTFP_REGNUM)
(PPC_IS_CKPTVMX_REGNUM, PPC_IS_CKPTVSX_REGNUM): Define.
* rs6000-tdep.c (IS_CDFP_PSEUDOREG, IS_CVSX_PSEUDOREG)
(IS_CEFP_PSEUDOREG): Define.
(rs6000_register_name): Hide the upper halves of checkpointed VSX
registers. Return names for the checkpointed DFP, VSX, and EFP
pseudo registers.
(rs6000_pseudo_register_type): Remove initial assert and raise an
internal error in the else clause instead. Return types for the
checkpointed DFP, VSX, and EFP pseudo registers.
(dfp_pseudo_register_read, dfp_pseudo_register_write): Handle
checkpointed DFP pseudo registers.
(vsx_pseudo_register_read, vsx_pseudo_register_write): Handle
checkpointed VSX pseudo registers.
(efp_pseudo_register_read, efp_pseudo_register_write): Rename
from efpr_pseudo_register_read and
efpr_pseudo_register_write. Handle checkpointed EFP pseudo
registers.
(rs6000_pseudo_register_read, rs6000_pseudo_register_write):
Handle checkpointed DFP, VSX, and EFP registers.
(dfp_ax_pseudo_register_collect, vsx_ax_pseudo_register_collect)
(efp_ax_pseudo_register_collect): New functions.
(rs6000_ax_pseudo_register_collect): Move DFP, VSX and EFP pseudo
register logic to new functions. Handle checkpointed DFP, VSX,
and EFP pseudo registers.
(rs6000_gdbarch_init): Look for and validate the htm features.
Include checkpointed DFP, VSX and EFP pseudo-registers.
* NEWS: Mention access to PPR, DSCR, TAR, EBB/PMU registers and
HTM registers.
gdb/gdbserver/ChangeLog:
2018-10-26 Pedro Franco de Carvalho <pedromfc@linux.ibm.com>
* configure.srv (ipa_ppc_linux_regobj): Add
powerpc-isa207-htm-vsx32l-ipa.o and
powerpc-isa207-htm-vsx64l-ipa.o.
(powerpc*-*-linux*): Add powerpc-isa207-htm-vsx32l.o and
powerpc-isa207-htm-vsx64l.o to srv_regobj. Add
rs6000/power-htm-spr.xml, rs6000/power-htm-core.xml,
rs6000/power64-htm-core.xml, rs6000/power-htm-fpu.xml,
rs6000/power-htm-altivec.xml, rs6000/power-htm-vsx.xml,
rs6000/power-htm-ppr.xml, rs6000/power-htm-dscr.xml,
rs6000/power-htm-tar.xml, rs6000/powerpc-isa207-htm-vsx32l.xml,
and rs6000/powerpc-isa207-htm-vsx64l.xml to srv_xmlfiles.
* linux-ppc-tdesc-init.h (enum ppc_linux_tdesc)
<PPC_TDESC_ISA207_HTM_VSX>: New enum value.
(init_registers_powerpc_isa207_htm_vsx32l)
(init_registers_powerpc_isa207_htm_vsx64l): Declare.
* linux-ppc-low.c (ppc_fill_tm_sprregset, ppc_store_tm_sprregset)
(ppc_store_tm_cgprregset, ppc_store_tm_cfprregset)
(ppc_store_tm_cvrregset, ppc_store_tm_cvsxregset)
(ppc_store_tm_cpprregset, ppc_store_tm_cdscrregset)
(ppc_store_tm_ctarregset): New functions.
(ppc_regsets): Add entries for HTM regsets.
(ppc_arch_setup): Set htm in features struct when needed. Set
sizes for the HTM regsets.
(ppc_get_ipa_tdesc_idx): Return PPC_TDESC_ISA207_HTM_VSX.
(initialize_low_arch): Call
init_registers_powerpc_isa207_htm_vsx32l and
init_registers_powerpc_isa207_htm_vsx64l.
* linux-ppc-ipa.c (get_ipa_tdesc): Handle
PPC_TDESC_ISA207_HTM_VSX.
(initialize_low_tracepoint): Call
init_registers_powerpc_isa207_htm_vsx32l and
init_registers_powerpc_isa207_htm_vsx64l.
gdb/testsuite/ChangeLog:
2018-10-26 Pedro Franco de Carvalho <pedromfc@linux.ibm.com>
* gdb.arch/powerpc-htm-regs.c: New file.
* gdb.arch/powerpc-htm-regs.exp: New file.
gdb/doc/ChangeLog:
2018-10-26 Pedro Franco de Carvalho <pedromfc@linux.ibm.com>
* gdb.texinfo (PowerPC Features): Describe new features
"org.gnu.gdb.power.htm.spr", "org.gnu.gdb.power.htm.core",
"org.gnu.gdb.power.htm.fpu", "org.gnu.gdb.power.htm.altivec",
"org.gnu.gdb.power.htm.vsx", "org.gnu.gdb.power.htm.ppr",
"org.gnu.gdb.power.htm.dscr", "org.gnu.gdb.power.htm.tar".
This patch adds support for the Target Address Register for powerpc
linux native and core file targets, and in the powerpc linux server
stub.
gdb/ChangeLog:
2018-10-26 Edjunior Barbosa Machado <emachado@linux.vnet.ibm.com>
Pedro Franco de Carvalho <pedromfc@linux.ibm.com>
* arch/ppc-linux-tdesc.h (tdesc_powerpc_isa207_vsx32l)
(tdesc_powerpc_isa207_vsx64l): Declare.
* arch/ppc-linux-common.h (PPC_LINUX_SIZEOF_TARREGSET): Define.
(struct ppc_linux_features) <isa207>: New field.
(ppc_linux_no_features): Add initializer for isa207 field.
* arch/ppc-linux-common.c (ppc_linux_match_description): Return
new tdescs.
* nat/ppc-linux.h (PPC_FEATURE2_ARCH_2_07, PPC_FEATURE2_TAR)
(NT_PPC_TAR): Define if not already defined.
* features/Makefile (WHICH): Add rs6000/powerpc-isa207-vsx32l and
rs6000/powerpc-isa207-vsx64l.
(XMLTOC): Add rs6000/powerpc-isa207-vsx32l.xml and
rs6000/powerpc-isa207-vsx64l.xml.
* features/rs6000/power-tar.xml: New file.
* features/rs6000/powerpc-isa207-vsx32l.xml: New file.
* features/rs6000/powerpc-isa207-vsx64l.xml: New file.
* features/rs6000/powerpc-isa207-vsx32l.c: Generate.
* features/rs6000/powerpc-isa207-vsx64l.c: Generate.
* regformats/rs6000/powerpc-isa207-vsx32l.dat: Generate.
* regformats/rs6000/powerpc-isa207-vsx64l.dat: Generate.
* ppc-linux-nat.c (fetch_register, fetch_ppc_registers): Call
fetch_regset with the TAR regset.
(store_register, store_ppc_registers): Call store_regset with the
TAR regset.
(ppc_linux_nat_target::read_description): Set isa207 field in the
features struct if needed.
* ppc-linux-tdep.c: Include
features/rs6000/powerpc-isa207-vsx32l.c and
features/rs6000/powerpc-isa207-vsx64l.c.
(ppc32_regmap_tar, ppc32_linux_tarregset): New globals.
(ppc_linux_iterate_over_regset_sections): Call back with the tar
regset.
(ppc_linux_core_read_description): Check if the tar section is
present and set isa207 in the features struct.
(_initialize_ppc_linux_tdep): Call
initialize_tdesc_powerpc_isa207_vsx32l and
initialize_tdesc_powerpc_isa207_vsx64l.
* ppc-linux-tdep.h (ppc32_linux_tarregset): Declare.
* ppc-tdep.h (gdbarch_tdep) <ppc_tar_regnum>: New field.
(enum) <PPC_TAR_REGNUM>: New enum value.
* rs6000-tdep.c (rs6000_gdbarch_init): Look for and validate tar
feature.
(ppc_process_record_op31): Record changes to TAR.
gdb/gdbserver/ChangeLog:
2018-10-26 Pedro Franco de Carvalho <pedromfc@linux.ibm.com>
* configure.srv (ipa_ppc_linux_regobj): Add
powerpc-isa207-vsx64l-ipa.o and powerpc-isa207-vsx32l-ipa.o.
(powerpc*-*-linux*): Add powerpc-isa207-vsx32l.o and
powerpc-isa207-vsx64l.o to srv_regobj, add rs6000/power-tar.xml,
rs6000/powerpc-isa207-vsx32l.xml, and
rs6000/powerpc-isa207-vsx64l.xml to srv_xmlfiles.
* linux-ppc-tdesc-init.h (enum ppc_linux_tdesc)
<PPC_TDESC_ISA207_VSX>: New enum value.
(init_registers_powerpc_isa207_vsx32l): Declare.
(init_registers_powerpc_isa207_vsx64l): Declare.
* linux-ppc-low.c (ppc_fill_tarregset): New function.
(ppc_store_tarregset): New function.
(ppc_regsets): Add entry for the TAR regset.
(ppc_arch_setup): Set isa207 in features struct when needed. Set
size for the TAR regsets.
(ppc_get_ipa_tdesc_idx): Return PPC_TDESC_ISA207_VSX.
(initialize_low_arch): Call init_registers_powerpc_isa207_vsx32l
and init_registers_powerpc_isa207_vsx64l.
* linux-ppc-ipa.c (get_ipa_tdesc): Handle PPC_TDESC_ISA207_VSX.
(initialize_low_tracepoint): Call
init_registers_powerpc_isa207_vsx32l and
init_registers_powerpc_isa207_vsx64l.
gdb/testsuite/ChangeLog:
2018-10-26 Pedro Franco de Carvalho <pedromfc@linux.ibm.com>
* gdb.arch/powerpc-tar.c: New file.
* gdb.arch/powerpc-tar.exp: New file.
gdb/doc/ChangeLog:
2018-10-26 Pedro Franco de Carvalho <pedromfc@linux.ibm.com>
* gdb.texinfo (PowerPC Features): Describe new feature
"org.gnu.gdb.power.tar".
This patch adds gdb support for the Program Priorty Register and the
Data Stream Control Register, for the powerpc linux native and core
file targets, and for the powerpc linux server stub.
gdb/ChangeLog:
2018-10-26 Edjunior Barbosa Machado <emachado@linux.vnet.ibm.com>
Pedro Franco de Carvalho <pedromfc@linux.ibm.com>
* arch/ppc-linux-tdesc.h (tdesc_powerpc_isa205_ppr_dscr_vsx32l)
(tdesc_powerpc_isa205_ppr_dscr_vsx64l): Declare.
* arch/ppc-linux-common.h (PPC_LINUX_SIZEOF_PPRREGSET)
(PPC_LINUX_SIZEOF_DSCRREGSET): Define.
(struct ppc_linux_features) <ppr_dscr>: New field.
(ppc_linux_no_features): Add initializer for ppr_dscr field.
* arch/ppc-linux-common.c (ppc_linux_match_description): Return
new tdescs.
* nat/ppc-linux.h (PPC_FEATURE2_DSCR, NT_PPC_PPR, NT_PPC_DSCR):
Define if not already defined.
* features/Makefile (WHICH): Add
rs6000/powerpc-isa205-ppr-dscr-vsx32l and
rs6000/powerpc-isa205-ppr-dscr-vsx64l.
(XMLTOC): Add rs6000/powerpc-isa205-ppr-dscr-vsx32l.xml and
rs6000/powerpc-isa205-ppr-dscr-vsx64l.xml.
* features/rs6000/power-dscr.xml: New file.
* features/rs6000/power-ppr.xml: New file.
* features/rs6000/powerpc-isa205-ppr-dscr-vsx32l.xml: New file.
* features/rs6000/powerpc-isa205-ppr-dscr-vsx64l.xml: New file.
* features/rs6000/powerpc-isa205-ppr-dscr-vsx32l.c: Generate.
* features/rs6000/powerpc-isa205-ppr-dscr-vsx64l.c: Generate.
* regformats/rs6000/powerpc-isa205-ppr-dscr-vsx32l.dat: Generate.
* regformats/rs6000/powerpc-isa205-ppr-dscr-vsx64l.dat: Generate.
* ppc-linux-nat.c: Include <sys/uio.h>.
(fetch_regset, store_regset, check_regset): New functions.
(fetch_register, fetch_ppc_registers): Call fetch_regset with
DSCR and PPR regsets.
(store_register, store_ppc_registers): Call store_regset with
DSCR and PPR regsets.
(ppc_linux_get_hwcap2): New function.
(ppc_linux_nat_target::read_description): Call
ppc_linux_get_hwcap2 and check_regset, set ppr_dscr field in the
features struct if needed.
* ppc-linux-tdep.c: Include
features/rs6000/powerpc-isa205-ppr-dscr-vsx32l.c and
features/rs6000/powerpc-isa205-ppr-dscr-vsx64l.c.
(ppc32_regmap_ppr, ppc32_regmap_dscr, ppc32_linux_pprregset)
(ppc32_linux_dscrregset): New globals.
(ppc_linux_iterate_over_regset_sections): Call back with the ppr
and dscr regsets.
(ppc_linux_core_read_description): Check if the ppr and dscr
sections are present and set ppr_dscr in the features struct.
(_initialize_ppc_linux_tdep): Call
initialize_tdesc_powerpc_isa205_ppr_dscr_vsx32l and
initialize_tdesc_powerpc_isa205_ppr_dscr_vsx64l.
* ppc-linux-tdep.h (ppc32_linux_pprregset)
(ppc32_linux_dscrregset): Declare.
* ppc-tdep.h (struct gdbarch_tdep) <ppc_ppr_regnum>: New field.
<ppc_dscr_regnum>: New field.
(enum) <PPC_PPR_REGNUM, PPC_DSCR_REGNUM>: New enum values.
* rs6000-tdep.c (rs6000_gdbarch_init): Look for and validate ppr
and dscr features.
(ppc_process_record_op31): Record changes to PPR and DSCR.
gdb/gdbserver/ChangeLog:
2018-10-26 Edjunior Barbosa Machado <emachado@linux.vnet.ibm.com>
Pedro Franco de Carvalho <pedromfc@linux.ibm.com>
* configure.srv (ipa_ppc_linux_regobj): Add
powerpc-isa205-ppr-dscr-vsx32l-ipa.o and
powerpc-isa205-ppr-dscr-vsx64l-ipa.o.
(powerpc*-*-linux*): Add powerpc-isa205-ppr-dscr-vsx32l.o and
powerpc-isa205-ppr-dscr-vsx64l.o to srv_regobj, add
rs6000/power-dscr.xml, rs6000/power-ppr.xml,
rs6000/powerpc-isa205-ppr-dscr-vsx32l.xml and
rs6000/powerpc-isa205-ppr-dscr-vsx64l.xml to srv_xmlfiles.
* linux-ppc-tdesc-init.h (enum ppc_linux_tdesc)
<PPC_TDESC_ISA205_PPR_DSCR_VSX>: New enum value.
(init_registers_powerpc_isa205_ppr_dscr_vsx32l)
(init_registers_powerpc_isa205_ppr_dscr_vsx64l): Declare.
* linux-ppc-low.c: Include "elf/common.h" and <sys/uio.h>.
(ppc_hwcap): Add comment.
(ppc_hwcap2): New global.
(ppc_check_regset, ppc_fill_pprregset, ppc_store_pprregset)
(ppc_fill_dscrregset, ppc_store_dscrregset): New functions.
(ppc_regsets): Add entries for the DSCR and PPR regsets.
(ppc_arch_setup): Get AT_HWCAP2. Set ppr_dscr in features struct
when needed. Set sizes for the the DSCR and PPR regsets.
(ppc_get_ipa_tdesc_idx): Return PPC_TDESC_ISA205_PPR_DSCR_VSX.
(initialize_low_arch): Call
init_registers_powerpc_isa205_ppr_dscr_vsx32l and
init_registers_powerpc_isa205_ppr_dscr_vsx64l.
* linux-ppc-ipa.c (get_ipa_tdesc): Handle
PPC_TDESC_ISA205_PPR_DSCR_VSX.
(initialize_low_tracepoint): Call
init_registers_powerpc_isa205_ppr_dscr_vsx32l and
init_registers_powerpc_isa205_ppr_dscr_vsx64l.
gdb/testsuite/ChangeLog:
2018-10-26 Pedro Franco de Carvalho <pedromfc@linux.ibm.com>
* gdb.arch/powerpc-ppr-dscr.c: New file.
* gdb.arch/powerpc-ppr-dscr.exp: New file.
gdb/doc/ChangeLog:
2018-10-26 Pedro Franco de Carvalho <pedromfc@linux.ibm.com>
* gdb.texinfo (PowerPC Features): Describe new features
"org.gnu.gdb.power.ppr" and "org.gnu.gdb.power.dscr".
Some confusion over how the register names and aliases are setup in
riscv means that we currently can't access registers through their
architectural name.
This commit fixes this issue, and moves some of the csr register
handling out of the alias handling code and deals with it separately.
This has the benefit that we can now directly access some arrays
rather than having to iterate over them.
A new test is added to ensure that register aliases now work
correctly.
gdb/ChangeLog:
* riscv-tdep.c (riscv_gdb_reg_names): Update comment, and all
register names.
(struct register_alias): Rename to...
(struct riscv_register_alias): ...this, and update comment.
(riscv_register_aliases): Update type, and alias names. Remove
CSR names from this list.
(riscv_register_name): Use riscv_gdb_reg_names for int and float
register names. Add an extra assertion.
(riscv_is_regnum_a_named_csr): New function.
(riscv_register_reggroup_p): Use riscv_is_regnum_a_named_csr.
gdb/testsuite/ChangeLog:
* gdb.arch/riscv-reg-aliases.c: New file.
* gdb.arch/riscv-reg-aliases.exp: New file.
At https://sourceware.org/gdb/wiki/GDBTestcaseCookbook\
#Follow_the_test_name_convention we find:
..
Test names should start with a lower case and don't need to end with a period
(they are not sentences).
...
Fix some capitalized test names.
Tested on x86_64-linux.
2018-10-18 Tom de Vries <tdevries@suse.de>
* gdb.ada/bp_inlined_func.exp: Fix capitalized test name.
* gdb.ada/excep_handle.exp: Same.
* gdb.ada/mi_string_access.exp: Same.
* gdb.ada/mi_var_union.exp: Same.
* gdb.arch/arc-analyze-prologue.exp: Same.
* gdb.arch/arc-decode-insn.exp: Same.
* gdb.base/readnever.exp: Same.
* gdb.fortran/printing-types.exp: Same.
* gdb.guile/scm-lazy-string.exp: Same.
As reported by Jan here:
https://sourceware.org/ml/gdb-patches/2018-09/msg00831.html
the check that sets the number of available registers is backwards.
gdb/testsuite/ChangeLog:
* gdb.arch/i386-avx512.exp: Fix setting of nr_regs based on
is_amd64_regs_target.
Add Aarch64 test to check register values of a previous frame
can be shown correctly across a signal.
gdb/testsuite/ChangeLog:
* gdb.arch/aarch64-sighandler-regs.c: New test.
* gdb.arch/aarch64-sighandler-regs.exp: New file.
* lib/gdb.exp (skip_aarch64_sve_tests): New proc.
Another case of incomplete regexp. The problem is very similar to the
one happening with gdb.arch/amd64-invalid-stack-middle.exp.
The output when GDB is compiled with "--enable-targets" is:
(gdb) interpreter-exec mi "-stack-list-frames"
^done,stack=[frame={level="0",addr="0x00000000004005e7",func="func2",arch="i386:x86-64"}]
While the output when "--enable-targets" is not specified is:
(gdb) interpreter-exec mi "-stack-list-frames"
^done,stack=[frame={level="0",addr="0x00000000004005e7",func="func2"}]
The fix is, again, to extend the current regexp and expect for the
optional "arch=" part. With this patch, the test now passes on both
scenarios.
OK?
gdb/testsuite/ChangeLog:
2018-09-18 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.arch/amd64-invalid-stack-top.exp: Expect optional
"arch=" keyword when executing "-stack-list-frames".
While regression-testing GDB on Fedora Rawhide, I saw the following
output when running gdb.arch/amd64-invalid-stack-middle.exp's
"-stack-list-frames" test:
(gdb) interpreter-exec mi "-stack-list-frames"
^done,stack=[frame={level="0",addr="0x000000000040115a",func="breakpt",file="amd64-invalid-stack-middle.c",fullname="/home/sergio/fedora/gdb/master/gdb-8.2.50.20180917/gdb/testsuite/gdb.arch/amd64-invalid-stack-middle.c",line="27",arch="i386:x86-64"},frame={level="1",addr="0x000000000040116a",func="func5",file="amd64-invalid-stack-middle.c",fullname="/home/sergio/fedora/gdb/master/gdb-8.2.50.20180917/gdb/testsuite/gdb.arch/amd64-invalid-stack-middle.c",line="32",arch="i386:x86-64"},frame={level="2",addr="0x000000000040117a",func="func4",file="amd64-invalid-stack-middle.c",fullname="/home/sergio/fedora/gdb/master/gdb-8.2.50.20180917/gdb/testsuite/gdb.arch/amd64-invalid-stack-middle.c",line="38",arch="i386:x86-64"},frame={level="3",addr="0x000000000040118a",func="func3",file="amd64-invalid-stack-middle.c",fullname="/home/sergio/fedora/gdb/master/gdb-8.2.50.20180917/gdb/testsuite/gdb.arch/amd64-invalid-stack-middle.c",line="44",arch="i386:x86-64"}]
This test is currently failing on Rawhide. However, this output is
almost the same as I get on my local Fedora 28 machine (where the test
is passing):
(gdb) interpreter-exec mi "-stack-list-frames"
^done,stack=[frame={level="0",addr="0x00000000004005da",func="breakpt",file="amd64-invalid-stack-middle.c",fullname="/home/sergio/work/src/git/binutils-gdb/binutils-gdb/gdb/testsuite/gdb.arch/amd64-invalid-stack-middle.c",line="27"},frame={level="1",addr="0x00000000004005ea",func="func5",file="amd64-invalid-stack-middle.c",fullname="/home/sergio/work/src/git/binutils-gdb/binutils-gdb/gdb/testsuite/gdb.arch/amd64-invalid-stack-middle.c",line="32"},frame={level="2",addr="0x00000000004005fa",func="func4",file="amd64-invalid-stack-middle.c",fullname="/home/sergio/work/src/git/binutils-gdb/binutils-gdb/gdb/testsuite/gdb.arch/amd64-invalid-stack-middle.c",line="38"},frame={level="3",addr="0x000000000040060a",func="func3",file="amd64-invalid-stack-middle.c",fullname="/home/sergio/work/src/git/binutils-gdb/binutils-gdb/gdb/testsuite/gdb.arch/amd64-invalid-stack-middle.c",line="44"}]
With the exception that there's an "arch=" keyword on Fedora Rawhide's
version. This is because, on Rawhide, I've compiled GDB with
"--enable-targets=xyz,kqp,etc.", while locally I haven't.
This is easy to fix: we just have to extend the regexp and expect for
the optional "arch=" keyword there. It's what this patch does. With
it applied, the test now passes everywhere.
OK?
gdb/testsuite/ChangeLog:
2018-09-18 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.arch/amd64-invalid-stack-middle.exp: Expect optional
"arch=" keyword when executing "-stack-list-frames".
Cannot assume result of first and third ldr will go into x0.
Rewrite asm to be clearer.
gdb/testsuite/
PR gdb/18931:
* gdb.arch/aarch64-fp.c (main): Fix asm registers.
Implement MIPS target support for passing options to the disassembler,
complementing commit 65b48a8140 ("GDB: Add support for the new
set/show disassembler-options commands.").
This includes options that expect an argument, so adjust the generic
code and data structures used so as to handle such options. So as to
give backends syntax flexibility no specific delimiter has been defined
to separate options from their respective arguments, so it has to be
included as the last character of the option name. Completion code
however has not been adjusted and consequently option arguments cannot
be completed at this time.
Also the MIPS target has non-empty defaults for the options, so that ABI
names for the general-purpose registers respect our `set mips abi ...'
setting rather than always being determined from the ELF headers of the
binary file selected. Handle these defaults as implicit options, never
shown to the user and always prepended to the user-specified options, so
that the latters can override the defaults.
The resulting output for the MIPS target is as follows:
(gdb) show disassembler-options
The current disassembler options are ''
The following disassembler options are supported for use with the
'set disassembler-options <option>[,<option>...]' command:
no-aliases Use canonical instruction forms.
msa Recognize MSA instructions.
virt Recognize the virtualization ASE instructions.
xpa Recognize the eXtended Physical Address (XPA) ASE
instructions.
ginv Recognize the Global INValidate (GINV) ASE instructions.
gpr-names=ABI Print GPR names according to specified ABI.
Default: based on binary being disassembled.
fpr-names=ABI Print FPR names according to specified ABI.
Default: numeric.
cp0-names=ARCH Print CP0 register names according to specified architecture.
Default: based on binary being disassembled.
hwr-names=ARCH Print HWR names according to specified architecture.
Default: based on binary being disassembled.
reg-names=ABI Print GPR and FPR names according to specified ABI.
reg-names=ARCH Print CP0 register and HWR names according to specified
architecture.
For the options above, the following values are supported for "ABI":
numeric 32 n32 64
For the options above, the following values are supported for "ARCH":
numeric r3000 r3900 r4000 r4010 vr4100 vr4111 vr4120 r4300 r4400 r4600
r4650 r5000 vr5400 vr5500 r5900 r6000 rm7000 rm9000 r8000 r10000 r12000
r14000 r16000 mips5 mips32 mips32r2 mips32r3 mips32r5 mips32r6 mips64
mips64r2 mips64r3 mips64r5 mips64r6 interaptiv-mr2 sb1 loongson2e
loongson2f loongson3a octeon octeon+ octeon2 octeon3 xlr xlp
(gdb)
which corresponds to what `objdump --help' used to print for the MIPS
target, with minor formatting changes, most notably option argument
lists being wrapped, but also the amount of white space separating
options from the respective descriptions. The relevant part the new
code is now also used by `objdump --help', which means these formatting
changes apply to both outputs, except for argument list wrapping, which
is GDB-specific.
This also adds a separating new line between the heading and option
lists where descriptions are provided, hence:
(gdb) set architecture s390:31-bit
(gdb) show disassembler-options
The current disassembler options are ''
The following disassembler options are supported for use with the
'set disassembler-options <option>[,<option>...]' command:
esa Disassemble in ESA architecture mode
zarch Disassemble in z/Architecture mode
insnlength Print unknown instructions according to length from first two bits
(gdb)
but:
(gdb) set architecture powerpc:common
(gdb) show disassembler-options
The current disassembler options are ''
The following disassembler options are supported for use with the
'set disassembler-options <option>[,<option>...]' command:
403, 405, 440, 464, 476, 601, 603, 604, 620, 7400, 7410, 7450, 7455, 750cl,
821, 850, 860, a2, altivec, any, booke, booke32, cell, com, e200z4, e300,
e500, e500mc, e500mc64, e5500, e6500, e500x2, efs, efs2, power4, power5,
power6, power7, power8, power9, ppc, ppc32, 32, ppc64, 64, ppc64bridge,
ppcps, pwr, pwr2, pwr4, pwr5, pwr5x, pwr6, pwr7, pwr8, pwr9, pwrx, raw, spe,
spe2, titan, vle, vsx
(gdb)
Existing affected target backends have been adjusted accordingly.
This has been verified manually with:
(gdb) set architecture arm
(gdb) set architecture powerpc:common
(gdb) set architecture s390:31-bit
to cause no issues with the `show disassembler-options' and `set
disassembler-options' commands. A test case for the MIPS target has
also been provided, covering the default settings with ABI overrides as
well as disassembler option overrides.
2018-07-02 Maciej W. Rozycki <macro@mips.com>
Simon Marchi <simon.marchi@polymtl.ca>
include/
PR tdep/8282
* dis-asm.h (disasm_option_arg_t): New typedef.
(disasm_options_and_args_t): Likewise.
(disasm_options_t): Add `arg' member, document members.
(disassembler_options_mips): New prototype.
(disassembler_options_arm, disassembler_options_powerpc)
(disassembler_options_s390): Update prototypes.
opcodes/
PR tdep/8282
* mips-dis.c (mips_option_arg_t): New enumeration.
(mips_options): New variable.
(disassembler_options_mips): New function.
(print_mips_disassembler_options): Reimplement in terms of
`disassembler_options_mips'.
* arm-dis.c (disassembler_options_arm): Adapt to using the
`disasm_options_and_args_t' structure.
* ppc-dis.c (disassembler_options_powerpc): Likewise.
* s390-dis.c (disassembler_options_s390): Likewise.
gdb/
PR tdep/8282
* disasm.h (gdb_disassembler): Add
`m_disassembler_options_holder'. member
* disasm.c (get_all_disassembler_options): New function.
(gdb_disassembler::gdb_disassembler): Use it.
(gdb_buffered_insn_length_init_dis): Likewise.
(gdb_buffered_insn_length): Adjust accordingly.
(set_disassembler_options): Handle options with arguments.
(show_disassembler_options_sfunc): Likewise. Add a leading new
line if showing options with descriptions.
(disassembler_options_completer): Adapt to using the
`disasm_options_and_args_t' structure.
* mips-tdep.c (mips_disassembler_options): New variable.
(mips_disassembler_options_o32): Likewise.
(mips_disassembler_options_n32): Likewise.
(mips_disassembler_options_n64): Likewise.
(gdb_print_insn_mips): Don't set `disassembler_options'.
(gdb_print_insn_mips_n32, gdb_print_insn_mips_n64): Remove
functions.
(mips_gdbarch_init): Always set `gdbarch_print_insn' to
`gdb_print_insn_mips'. Set `gdbarch_disassembler_options',
`gdbarch_disassembler_options_implicit' and
`gdbarch_valid_disassembler_options'.
* arm-tdep.c (_initialize_arm_tdep): Adapt to using the
`disasm_options_and_args_t' structure.
* gdbarch.sh (disassembler_options_implicit): New `gdbarch'
method.
(valid_disassembler_options): Switch from `disasm_options_t' to
the `disasm_options_and_args_t' structure.
* NEWS: Document `set disassembler-options' support for the MIPS
target.
* gdbarch.h: Regenerate.
* gdbarch.c: Regenerate.
gdb/doc/
PR tdep/8282
* gdb.texinfo (Source and Machine Code): Document `set
disassembler-options' support for the MIPS target.
gdb/testsuite/
PR tdep/8282
* gdb.arch/mips-disassembler-options.exp: New test.
* gdb.arch/mips-disassembler-options.s: New test source.
Our interpretation of the layout of floating-point general registers
(FGRs) in o32 MIPS/Linux core files is different from how the kernel
makes them, affecting the CP0 Status.FR=0 aka FP32 mode (we don't
currently support the CP0 Status.FR=1 aka FP64 mode with the o32 ABI).
In the FP32 mode pairs of consecutive even/odd-numbered 32-bit registers
are placed together as 64-bit values in even-indexed 64-bit slots
corresponding to the even index, leaving the odd-indexed 64-bit slots
unused. These 64-bit values are stored according to the endianness in
effect, which is how the MIPS II SDC1 instruction would store them.
It has always been like that with the Linux kernel for MIPS II and
higher ISA processors, which are the vast majority ever supported, as it
is indeed SDC1 that the kernel uses to store FGRs in a floating-point
context.
With MIPS I processors, which lack the SDC1 instruction, a layout that
we expect used to be used long ago, but it was corrected for consistency
with newer processors back in 2002, with `linux-mips.org' (LMO) commit
42533948caac ("Major pile of FP emulator changes."), the fix corrected
with LMO commit 849fa7a50dff ("R3k FPU ptrace() handling fixes."), and
then broken and fixed over and over again, until last time fixed with
commit 80cbfad79096 ("MIPS: Correct MIPS I FP context layout").
Consequently the values we see in FP32 core files or produce with the
`gcore' command are different from those obtained from the same FP
context of a live process, e.g. with a big-endian configuration these
live values:
(gdb) info registers float
f0: 0x4b5c6d7e flt: 14445950 dbl: 1.7446153562345001e-274
f1: 0x0718293a flt: 1.14473244e-34
f2: 0xc3d4e5f6 flt: -425.79657 dbl: -1.046160437414959e-233
f3: 0x8f90a1b2 flt: -1.42617791e-29
f4: 0x4c5d6e7f flt: 58046972 dbl: 1.1908587841220294e-269
f5: 0x08192a3b flt: 4.60914044e-34
f6: 0xc4d5e6f7 flt: -1711.21765 dbl: -6.2784661835068965e-306
f7: 0x8091a2b3 flt: -1.33745124e-38
f8: 0x45566778 flt: 3430.4668 dbl: 1.6530355595710607e-303
f9: 0x01122334 flt: 2.68412219e-38
f10: 0xcddeeff0 flt: -467533312 dbl: -2.1174864564135575e-262
f11: 0x899aabbc flt: -3.72356497e-33
f12: 0x46576879 flt: 13786.1182 dbl: 1.143296486773654e-298
f13: 0x02132435 flt: 1.08102453e-37
f14: 0xcedfe0f1 flt: -1.87803046e+09 dbl: -1.4399511533369862e-257
f15: 0x8a9bacbd flt: -1.4990934e-32
f16: 0x4758697a flt: 55401.4766 dbl: 7.8856820439568725e-294
f17: 0x03142536 flt: 4.3536007e-37
f18: 0xcfd0e1f2 flt: -7.00893696e+09 dbl: -9.7791926757340559e-253
f19: 0x8b9cadbe flt: -6.03504325e-32
f20: 0x48596a7b flt: 222633.922 dbl: 5.4255001483306113e-289
f21: 0x04152637 flt: 1.75324132e-36
f22: 0xc0d1e2f3 flt: -6.55895376 dbl: -6.6332401002310683e-248
f23: 0x8c9daebf flt: -2.42948516e-31
f24: 0x495a6b7c flt: 894647.75 dbl: 3.7244369058749787e-284
f25: 0x05162738 flt: 7.06016945e-36
f26: 0xc1d2e3f4 flt: -26.3613052 dbl: -4.4941535759306202e-243
f27: 0x8d9eafb0 flt: -9.77979703e-31
f28: 0x4a5b6c7d flt: 3595039.25 dbl: 2.5514593711161396e-279
f29: 0x06172839 flt: 2.84294945e-35
f30: 0xc2d3e4f5 flt: -105.947182 dbl: -3.035646690850097e-238
f31: 0x8e9fa0b1 flt: -3.93512664e-30
fcsr: 0x0
fir: 0xf30000
(gdb)
show up in a core file as these:
(gdb) info registers float
f0: 0x0718293a flt: 1.14473244e-34 dbl: nan
f1: 0x7ff80000 flt: nan
f2: 0x8f90a1b2 flt: -1.42617791e-29 dbl: nan
f3: 0x7ff80000 flt: nan
f4: 0x08192a3b flt: 4.60914044e-34 dbl: nan
f5: 0x7ff80000 flt: nan
f6: 0x8091a2b3 flt: -1.33745124e-38 dbl: nan
f7: 0x7ff80000 flt: nan
f8: 0x01122334 flt: 2.68412219e-38 dbl: nan
f9: 0x7ff80000 flt: nan
f10: 0x899aabbc flt: -3.72356497e-33 dbl: nan
f11: 0x7ff80000 flt: nan
f12: 0x02132435 flt: 1.08102453e-37 dbl: nan
f13: 0x7ff80000 flt: nan
f14: 0x8a9bacbd flt: -1.4990934e-32 dbl: nan
f15: 0x7ff80000 flt: nan
f16: 0x03142536 flt: 4.3536007e-37 dbl: nan
f17: 0x7ff80000 flt: nan
f18: 0x8b9cadbe flt: -6.03504325e-32 dbl: nan
f19: 0x7ff80000 flt: nan
f20: 0x04152637 flt: 1.75324132e-36 dbl: nan
f21: 0x7ff80000 flt: nan
f22: 0x8c9daebf flt: -2.42948516e-31 dbl: nan
f23: 0x7ff80000 flt: nan
f24: 0x05162738 flt: 7.06016945e-36 dbl: nan
f25: 0x7ff80000 flt: nan
f26: 0x8d9eafb0 flt: -9.77979703e-31 dbl: nan
f27: 0x7ff80000 flt: nan
f28: 0x06172839 flt: 2.84294945e-35 dbl: nan
f29: 0x7ff80000 flt: nan
f30: 0x8e9fa0b1 flt: -3.93512664e-30 dbl: nan
f31: 0x7ff80000 flt: nan
(gdb)
Notice how values from odd-numbered registers are shown in corresponding
even-numbered registers and how dummy 0x7ff80000 NaN values, which the
kernel places in unused slots, are reported in odd-numbered registers.
Correct our intepretation then, to match the kernel's. As it happens
the o32 FGR core file representation matches that used by the `ptrace'
PTRACE_GETFPREGS request, which means our 64-bit handlers can be readily
used, as they already correctly handle the differences between o32 FP32
mode vs n32/n64 representations.
Adjust comments accordingly throughout, in particular remove a reference
to the r3000/tx39 MIPS I processor peculiarity, long irrelevant.
Add a test case to verify correctness. Avoid GCC bugs and limitations
in the test case where possible; the test case still fails to build with
GCC 8 and the o32 FP64 mode (i.e. with `-mips32r2 -mfp64' options)
giving:
mips-fpregset-core.c: In function 'main':
mips-fpregset-core.c:66:3: error: inconsistent operand constraints in an 'asm'
asm (
^~~
(GCC PR target/85909), but that is not a concern for us as yet, because
as noted above we do not currently support the o32 FP64 mode anyway.
gdb/
* mips-linux-tdep.h (mips_supply_fpregset, mips_fill_fpregset):
Remove prototypes.
* mips-linux-nat.c (supply_fpregset): Always call
`mips64_supply_fpregset' rather than `mips_supply_fpregset'.
(fill_fpregset): Always call `mips64_fill_fpregset' rather than
`mips_fill_fpregset'.
* mips-linux-tdep.c (mips_supply_fpregset)
(mips_supply_fpregset_wrapper, mips_fill_fpregset)
(mips_fill_fpregset_wrapper): Remove functions.
(mips64_supply_fpregset, mips64_fill_fpregset): Update comments.
(mips_linux_fpregset): Remove variable.
(mips_linux_iterate_over_regset_sections): Use
`mips64_linux_fpregset' in place of `mips_linux_fpregset'.
(mips_linux_o32_sigframe_init): Remove comment.
gdb/testsuite/
* gdb.arch/mips-fpregset-core.exp: New test.
* gdb.arch/mips-fpregset-core.c: New test source.
Currently the ppc linux core file target doesn't return target
descriptions with the lager FPSCR introduced in isa205.
This patch changes the core file target so that the auxv is read from
the core file to determine the size of FPSCR, so that the appropriate
target description is selected.
gdb/ChangeLog:
2018-05-22 Pedro Franco de Carvalho <pedromfc@linux.vnet.ibm.com>
* arch/ppc-linux-common.c (ppc_linux_has_isa205): Change the
parameter type to CORE_ADDR.
* arch/ppc-linux-common.h (ppc_linux_has_isa205): Change the
parameter type in declaration to CORE_ADDR.
* ppc-linux-tdep.c (ppc_linux_core_read_description): Call
target_auxv_search to get AT_HWCAP and use the result to get the
target description.
* ppc-linux-nat.c (ppc_linux_get_hwcap): Change the return type
to CORE_ADDR. Remove the cast of the return value to unsigned
long. Fix error predicate of target_auxv_search.
(ppc_linux_nat_target::read_description): Change the type of the
hwcap variable to CORE_ADDR.
gdb/testsuite/ChangeLog:
2018-05-22 Pedro Franco de Carvalho <pedromfc@linux.vnet.ibm.com>
* gdb.arch/powerpc-fpscr-gcore.exp: New file.
The functions used by the VSX regset to collect and supply registers
from core files where incorrect. This patch changes the regset to use
the standard regset collect/supply functions to fix this. The native
target is also changed to use the same regset.
gdb/ChangeLog:
2018-05-22 Pedro Franco de Carvalho <pedromfc@linux.vnet.ibm.com>
* ppc-linux-tdep.c (ppc_linux_vsxregset): New function.
(ppc32_linux_vsxregmap): New global.
(ppc32_linux_vsxregset): Initialize with ppc32_linux_vsxregmap,
regcache_supply_regset, and regcache_collect_regset.
* ppc-linux-tdep.h (ppc_linux_vsxregset): Declare.
* ppc-linux-nat.c (supply_vsxregset, fill_vsxregset): Remove.
(fetch_vsx_register, store_vsx_register): Remove.
(fetch_vsx_registers): Add regno parameter. Get regset using
ppc_linux_vsxregset. Use regset to supply registers.
(store_vsx_registers): Add regno parameter. Get regset using
ppc_linux_vsxregset. Use regset to collect registers.
(fetch_register): Call fetch_vsx_registers instead of
fetch_vsx_register.
(store_register): Call store_vsx_registers instead of
store_vsx_register.
(fetch_ppc_registers): Call fetch_vsx_registers with -1 for the
new regno parameter.
(store_ppc_registers): Call store_vsx_registers with -1 for the
new regno parameter.
* rs6000-tdep.c (ppc_vsx_support_p, ppc_supply_vsxreget)
(ppc_collect_vsxregset): Remove.
gdb/testsuite/ChangeLog:
2018-05-22 Pedro Franco de Carvalho <pedromfc@linux.vnet.ibm.com>
* gdb.arch/powerpc-vsx-gcore.exp: New file.
For GNU/Linux on x86-64, if the target is using the xsave format for
passing the floating-point information from the inferior then there
currently exists a bug relating to the x87 control registers, and the
mxcsr register.
The xsave format allows different floating-point features to be lazily
enabled, a bit in the xsave format tells GDB which floating-point
features have been enabled, and which have not.
Currently in GDB, when reading the floating point state, we check the
xsave bit flags, if the feature is enabled then we read the feature
from the xsave buffer, and if the feature is not enabled, then we
supply the default value from within GDB.
Within GDB, when writing the floating point state, we first fetch the
xsave state from the target and then, for any feature that is not yet
enabled, we write the default values into the xsave buffer. Next we
compare the regcache value with the value in the xsave buffer, and, if
the value has changed we update the value in the xsave buffer, and
mark the feature enabled in the xsave bit flags.
The problem then, is that the x87 control registers were not following
this pattern. We assumed that these registers were always written out
by the kernel, and we always wrote them out to the xsave buffer (but
didn't enabled the feature). The result of this is that if the kernel
had not yet enabled the x87 feature then within GDB we would see
random values for the x87 floating point control registers, and if the
user tried to modify one of these register, that modification would be
lost.
Finally, the mxcsr register was also broken in the same way as the x87
control registers. The added complexity with this case is that the
mxcsr register is part of both the avx and sse floating point feature
set. When reading or writing this register we need to check that at
least one of these features is enabled.
This bug was present in native GDB, and within gdbserver. Both are
fixed with this commit.
gdb/ChangeLog:
* common/x86-xstate.h (I387_FCTRL_INIT_VAL): New constant.
(I387_MXCSR_INIT_VAL): New constant.
* amd64-tdep.c (amd64_supply_xsave): Only read state from xsave
buffer if it was supplied by the inferior.
* i387-tdep.c (i387_supply_fsave): Use I387_MXCSR_INIT_VAL.
(i387_xsave_get_clear_bv): New function.
(i387_supply_xsave): Only read x87 control registers from the
xsave buffer if the feature is enabled, and the state will have
been written, otherwise, provide a suitable default.
(i387_collect_xsave): Pre-clear all registers in xsave buffer,
including x87 control registers. Update control registers if they
have changed from the default value, and mark features as enabled
as required.
* i387-tdep.h (i387_xsave_get_clear_bv): Declare.
gdb/gdbserver/ChangeLog:
* i387-fp.c (i387_cache_to_xsave): Only write x87 control
registers to the cache if their values have changed.
(i387_xsave_to_cache): Provide default values for x87 control
registers when these features are available, but disabled.
* regcache.c (supply_register_by_name_zeroed): New function.
* regcache.h (supply_register_by_name_zeroed): Declare new
function.
gdb/testsuite/ChangeLog:
* gdb.arch/amd64-init-x87-values.S: New file.
* gdb.arch/amd64-init-x87-values.exp: New file.
When a 64-bits (x86-64) gdbarch is created, it is first born as a
32-bits gdbarch in i386_gdbarch_init. The call gdbarch_init_osabi will
call the handler register for the selected (arch, osabi) pair, such as
amd64_linux_init_abi. The various amd64 handlers call amd64_init_abi,
which turns the gdbarch into a 64-bits one.
When selecting the i386:x86-64 architecture with no osabi, no such
handler is ever called, so the gdbarch stays (wrongfully) a 32-bits one.
My first idea was to manually call amd64_init_abi & al in
i386_gdbarch_init when the osabi is GDB_OSABI_NONE. However, this
doesn't work in a build of GDB where i386 is included as a target but
not amd64. My next option (implemented in this patch), is to allow
registering handlers for GDB_OSABI_NONE. I added two such handlers in
amd64-tdep.c, so now it works the same as for the "normal" osabis. It
required re-ordering things in gdbarch_init_osabi to allow running
handlers for GDB_OSABI_NONE.
Without this patch applied (but with the previous one*) :
(gdb) set osabi none
(gdb) set architecture i386:x86-64
The target architecture is assumed to be i386:x86-64
(gdb) p sizeof(void*)
$1 = 4
and now:
(gdb) set osabi none
(gdb) set architecture i386:x86-64
The target architecture is assumed to be i386:x86-64
(gdb) p sizeof(void*)
$1 = 8
* Before the previous patch, which fixed "set osabi none", this bug was
hidden because we didn't actually try to generate a gdbarch for no
osabi, it would always fall back on Linux. Generating the gdbarch for
amd64/linux did work.
gdb/ChangeLog:
PR gdb/22979
* amd64-tdep.c (amd64_none_init_abi): New function.
(amd64_x32_none_init_abi): New function.
(_initialize_amd64_tdep): Register handlers for x86-64 and
x64_32 with GDB_OSABI_NONE.
* osabi.c (gdbarch_init_osabi): Allow running handlers for the
GDB_OSABI_NONE osabi.
gdb/testsuite/ChangeLog:
PR gdb/22979
* gdb.arch/amd64-osabi.exp: New file.
This test starts up and confirms that $xmm0 has the value 0, it then
modifies $xmm0 (in the inferior) and confirms that the new value can
be read (in GDB).
On some machines I was noticing that this test would occasionally
fail, and on investigation I believe that the reason for this is that
the test is linked as a dynamically linked executable and makes use of
the system libraries during startup. The reason that this causes
problems is that both the runtime linker and the startup code run
before main can, and do (on at least some platforms) make use of the
XMM registers.
In this commit I modify the test program slightly to allow it to be
linked statically, without using the startup libraries. Now by the
time GDB reaches the symbol main we have only executed one 'nop'
instruction, and the XMM registers should all have the value 0. I've
extended the test script to confirm that $xmm0 to $xmm15 are all
initially 0, and I also check that at the point after $xmm0 has been
modified, all the other XMM registers ($xmm1 to $xmm15) are still 0.
The test program is still linked against libc in order that we can
call the exit function, however, we now call _exit rather than exit in
order to avoid all of the usual cleanup that exit does. This clean up
tries to tear down things that are usually setup during the startup
code, but now this isn't called calling exit will just result in a
crash.
gdb/testsuite/ChangeLog:
* gdb.arch/amd64-disp-step-avx.S: Add '_start' label.
(done): Call '_exit' not 'exit' to avoid atexit handlers.
* gdb.arch/amd64-disp-step-avx.exp: Pass -static, and
-nostartfiles when compiling the test. Confirm that all registers
xmm0 to xmm15 are initially 0, and that xmm1 to xmm15 are 0 after.
A small number of tests incorrectly tried to pass -Wa,-g through to
GCC as an extra compile time flag, either to gdb_compile or
prepare_for_testing.
The problem is that the syntax used for passing the flags was
incorrect, and as a result these extra flags were being ignored.
Luckily, the 'debug' flag was being passed in each case anyway, which
means that the '-g' flag would already be added.
Given that all these tests pass 'debug', and the invalid flag has been
ignored for some time, I'm just removing the flags in this commit.
I've also changed the tests from using gdb_compile to
prepare_for_testing, which allows some extra code to be removed from a
couple of tests scripts.
There should be no change in the test results after this commit.
gdb/testsuite/ChangeLog:
* gdb.arch/amd64-disp-step-avx.exp: Remove unneeded assembler flag
option, syntax was wrong anyway.
* gdb.arch/arm-disp-step.exp: Likewise.
* gdb.arch/sparc64-regs.exp: Likewise.
* gdb.arch/amd64-disp-step.exp: Remove unneeded assembler flag
option, syntax was wrong anyway, switch to use
prepare_for_testing.
* gdb.arch/i386-disp-step.exp: Likewise.
Rogerio Alves
Luis Machado
Joel Brobecker
Lukas Durfina
Tom de Vries
Ulrich Weigand
Alan Hayward
Srinath Parvathaneni
Andrew Burgess
Tom Tromey
Leszek Swirski
Weimin Pan
Pedro Franco de Carvalho
Jan Vrany
Jan Beulich
Sangamesh Mallayya
Philippe Waroquiers
Edjunior Barbosa Machado
Simon Marchi
Sergio Durigan Junior
Maciej W. Rozycki
Pedro Franco de Carvalho