AARCH64_OPDE_EXPECTED_A_AFTER_B and AARCH64_OPDE_A_SHOULD_FOLLOW_B
are not paired with an error string, but we had an assert that the
error was nonnull. Previously this assert was testing uninitialised
memory and so could pass or fail arbitrarily.
opcodes/
* aarch64-opc.c (verify_mops_pme_sequence): Initialize the error
field to null for AARCH64_OPDE_EXPECTED_A_AFTER_B and
AARCH64_OPDE_A_SHOULD_FOLLOW_B.
* aarch64-dis.c (print_verifier_notes): Move assert.
The function value_subscripted_rvalue is only used in valarith.c, so
lets make it a static function.
There should be no user visible change after this commit.
A test in gdb.python/py-send-packet.exp added in this commit:
commit 24b2de7b77
Date: Tue Aug 31 14:04:36 2021 +0100
gdb/python: add gdb.RemoteTargetConnection.send_packet
included a large amount of binary data in the command sent to GDB. As
this test didn't have a real test name the binary data was included in
the gdb.sum file. The contents of the binary data could change
between different runs of GDB, and this makes comparing results
harder.
This commit gives the test a real test name.
This commit:
commit 288712bbac
Date: Mon Nov 22 15:16:27 2021 +0000
gdb/remote: use scoped_restore to control starting_up flag
introduced a use after free bug. The scoped restore added in the
above commit resets a flag within a remote_target's remote_state
object.
However, in some situations, the remote_target can be unpushed before
the error is thrown. If the only reference to the target is the one
in the target stack, then unpushing the target will cause the
remote_target to be deleted, which, in turn, will delete the
remote_state object. The scoped restore will then try to reset the
flag within a deleted object.
This problem was caught in the gdb.server/server-connect.exp test,
which, when run with the address sanitizer enabled, highlights the
write after free bug described above.
This commit resolves this issue by adding a new class specifically for
the purpose of managing the starting_up flag. As well as setting, and
then clearing the starting_up flag, this new class increments, and
then decrements the reference count on the remote_target object. This
prevents the remote_target from being deleted until after the flag has
been reset.
The gdb.server/server-connect.exp now runs cleanly with the address
sanitizer enabled.
It looks like automake makes assumptions about its ability to build info
pages based on the GNU standard behavior of shipping info pages with the
distributions. So even though the info pages were conditionalized, and
automake disabled some of the targets, it was still creeping in by way
of unconditional INFO_DEPS settings.
We can workaround this by adding a stub target for the info page when
building info pages are disabled. This tricks automake into disabling
its own extended generation target. I'll follow up with the automake
folks to see what they think.
That xstrdup is not correct, since we are assigning an std::string. The
result of xstrdup is used to initialize the string, and then lost
forever. Remove it.
Change-Id: Ief7771055e4bfd643ef3b285ec9fb7b1bfd14335
PR27257 reports a problem that can be reproduced as follows:
- use x86_64 machine with avx512 support
- compile a hello world with -m32 to a.out
- start a gdbserver session with a.out
- use gdb to connect to the gdbserver session
This makes us run into:
...
Listening on port 2346
Remote debugging from host ::1, port 34940
src/gdbserver/regcache.cc:257: \
A problem internal to GDBserver has been detected.
Unknown register zmm16h requested
...
The problem is that i387_xsave_to_cache in gdbserver/i387-fp.cc can't find a
register zmm16h in the register cache.
To understand how this happens, first some background.
SSE has 16 128-bit wide xmm registers.
AVX extends the SSE registers set as follows:
- it extends the 16 existing 128-bit wide xmm registers to 256-bit wide ymm
registers.
AVX512 extends the AVX register set as follows:
- it extends the 16 existing 256-bit wide ymm registers to 512-bit wide zmm
registers.
- it adds 16 additional 512-bit wide zmm registers (with corresponding ymm and
xmm subregisters added as well)
However, in 32-bit mode, there are only 8 xmm/ymm/zmm registers.
The problem we're running into is that gdbserver/i387-fp.cc uses these
constants to describe the size of the register file:
...
static const int num_avx512_zmmh_low_registers = 16;
static const int num_avx512_zmmh_high_registers = 16;
static const int num_avx512_ymmh_registers = 16;
static const int num_avx512_xmm_registers = 16;
...
which are all incorrect for the 32-bit case.
Fix this by replacing the constants with variables that have the appropriate
values in 64-bit and 32-bit mode.
Tested on x86_64-linux with native and unix/-m32.
Commit ab557072b8 ("gdb: use actual DWARF version in compunit's
debugformat field") changes the debug format string in "info source" to
show the actual DWARF version, rather than always show "DWARF 2".
However, it failed to consider that some tests checked for the "DWARF 2"
string to see if the test program is compiled with DWARF debug
information. Since everything is compiled with DWARF 4 or 5 nowadays,
that changed the behavior of those tests. Notably, it prevent the
tests using skip_inline_var_tests to run.
Grep through the testsuite for "DWARF 2" and change all occurrences I
could find to use "DWARF [0-9]" instead (that string is passed to TCL's
string match).
Change-Id: Ic7fb0217fb9623880c6f155da6becba0f567a885
In the gdb.ada/fixed_points_function.exp testcase, we have the following
Ada code...
type FP1_Type is delta 0.1 range -1.0 .. +1.0; -- Ordinary
function Call_FP1 (F : FP1_Type) return FP1_Type is
begin
FP1_Arg := F;
return FP1_Arg;
end Call_FP1;
... used as follow:
F1 : FP1_Type := 1.0;
F1 := Call_FP1 (F1);
The testcase, among other things, verifies that "return" works
properly as follow:
| (gdb) return 1.0
| Make pck.call_fp1 return now? (y or n) y
| [...]
| 9 F1 := Call_FP1 (F1);
| (gdb) next
| (gdb) print f1
| $1 = 0.0625
The output of the last command shows that we returned the wrong
value. The value printed gives a clue about the problem, since
it is 1/16th of the value we expected, where 1/16 is FP1_Type's
scaling factor.
The problem, here, comes from the fact that the function
handling return values for base types (ppc64_sysv_abi_return_value_base)
writes the return value using unpack_long which, upon seeing that
the value being unpacked is a fixed point type, applies the scaling
factor, to get the integer-representation of our fixed-point value
(similar to what it does with floats, for instance).
So, the fix consists in teaching ppc64_sysv_abi_return_value_base
about fixed-point types, and to avoid the unwanted application
of the scaling factor.
Note that the "finish" function, on the other hand, does not
suffer from this issue, simply becaue the value returned by
the function is read from register without the use of a type,
thus avoiding an unwanted application of a scaling factor.
No test added, as this change is already tested by
gdb.ada/fixed_points_function.exp.
Co-Authored-By: Tristan Gingold <gingold@adacore.com>
This commit adds support for TYPE_CODE_FIXED_POINT types for
"finish" and "return" commands.
Consider the following Ada code...
type FP1_Type is delta 0.1 range -1.0 .. +1.0; -- Ordinary
function Call_FP1 (F : FP1_Type) return FP1_Type is
begin
FP1_Arg := F;
return FP1_Arg;
end Call_FP1;
... used as follow:
F1 : FP1_Type := 1.0;
F1 := Call_FP1 (F1);
"finish" currently behaves as follow:
| (gdb) finish
| [...]
| Value returned is $1 = 0
We expect the returned value to be "1".
Similarly, "return" makes the function return the wrong value:
| (gdb) return 1.0
| Make pck.call_fp1 return now? (y or n) y
| [...]
| 9 F1 := Call_FP1 (F1);
| (gdb) next
| (gdb) print f1
| $1 = 0.0625
(we expect it to print "1" instead).
This problem comes from the handling of integral return values
when the return value is actually fixed point type. Our type
here is actually a range of a fixed point type, but the same
principles should also apply to pure fixed-point types. For
the record, here is what the debugging info looks like:
<1><238>: Abbrev Number: 2 (DW_TAG_subrange_type)
<239> DW_AT_lower_bound : -16
<23a> DW_AT_upper_bound : 16
<23b> DW_AT_name : pck__fp1_type
<23f> DW_AT_type : <0x248>
<1><248>: Abbrev Number: 4 (DW_TAG_base_type)
<249> DW_AT_byte_size : 1
<24a> DW_AT_encoding : 13 (signed_fixed)
<24b> DW_AT_binary_scale: -4
<24c> DW_AT_name : pck__Tfp1_typeB
<250> DW_AT_artificial : 1
... where the scaling factor is 1/16.
Looking at the "finish" command, what happens is that riscv_arg_location
determines that our return value should be returned by parameter using
an integral convention (via builtin type long). And then,
riscv_return_value uses a cast to that builtin type long to
store the value of into a buffer with the right register size.
This doesn't work in our case, because the underlying value
returned by the function is unscaled, which means it is 16,
and thus the cast is like doing:
arg_val = (FP1_Type) 16
... In other words, it is trying to create an FP1_Type enty whose
value is 16. Applying the scaling factor, that's 256, and because
the size of FP1_Type is 1 byte, we overflow and thus it ends up
being zero.
The same happen with the "return" function, but the other way around.
The fix consists in handling fixed-point types separately from
integral types.
Consider the following Ada code:
type FP1_Type is delta 0.1 range -1.0 .. +1.0; -- Ordinary
FP1_Arg : FP1_Type := 0.0;
function Call_FP1 (F : FP1_Type) return FP1_Type is
begin
FP1_Arg := F;
return FP1_Arg;
end Call_FP1;
After having stopped inside function Call_FP1 as follow:
Breakpoint 1, pck.call_fp1 (f=1) at /[...]/pck.adb:5
5 FP1_Arg := F;
Returning from that function call using "finish" should show
that the function return "1.0" (the same value as was passed
as an argument). However, this is not the case:
(gdb) finish
Run till exit from #0 pck.call_fp1 (f=1)
[...]
9 F1 := Call_FP1 (F1);
Value returned is $1 = 0
This patch enhances the extraction of the return value to know about
fixed point types.
Consider the following code:
type FP1_Type is delta 0.1 range -1.0 .. +1.0; -- Ordinary
function Call_FP1 (F : FP1_Type) return FP1_Type is
begin
return F;
end Call_FP1;
When the default in GCC is to generate proper DWARF info for fixed point
types, then in gdb, printing the result of a call to call_fp1 with a
decimal parameter leads to:
(gdb) p call_fp1(0.5)
$1 = 0
The displayed value is wrong, and we actually expected:
(gdb) p call_fp1(0.5)
$1 = 0.5
What happened is that our fixed point type parameter got promoted to a
32bit integer because we detected that the length of that object was less
than 4 bytes. The compiler does not perform this promotion and therefore
GDB should not either.
This patch fixes the behavior described above.
This adds a 'task apply' command, which is the Ada tasking analogue of
'thread apply'. Unlike 'thread apply', it doesn't offer the
'ascending' flag; but otherwise it's essentially the same.
The MOPS instructions should be used as a triple, such as:
cpyfp [x0]!, [x1]!, x2!
cpyfm [x0]!, [x1]!, x2!
cpyfe [x0]!, [x1]!, x2!
The registers should also be the same for each writeback operand.
This patch adds a warning for code that doesn't follow this rule,
along similar lines to the warning that we already emit for
invalid uses of MOVPRFX.
include/
* opcode/aarch64.h (C_SCAN_MOPS_P, C_SCAN_MOPS_M, C_SCAN_MOPS_E)
(C_SCAN_MOPS_PME): New macros.
(AARCH64_OPDE_A_SHOULD_FOLLOW_B): New aarch64_operand_error_kind.
(AARCH64_OPDE_EXPECTED_A_AFTER_B): Likewise.
(aarch64_operand_error): Make each data value a union between
an int and a string.
opcodes/
* aarch64-tbl.h (MOPS_CPY_OP1_OP2_INSN): Add scan flags.
(MOPS_SET_OP1_OP2_INSN): Likewise.
* aarch64-opc.c (set_out_of_range_error): Update after change to
aarch64_operand_error.
(set_unaligned_error, set_reg_list_error): Likewise.
(init_insn_sequence): Use a 3-instruction sequence for
MOPS P instructions.
(verify_mops_pme_sequence): New function.
(verify_constraints): Call it.
* aarch64-dis.c (print_verifier_notes): Handle
AARCH64_OPDE_A_SHOULD_FOLLOW_B and AARCH64_OPDE_EXPECTED_A_AFTER_B.
gas/
* config/tc-aarch64.c (operand_mismatch_kind_names): Add entries
for AARCH64_OPDE_A_SHOULD_FOLLOW_B and AARCH64_OPDE_EXPECTED_A_AFTER_B.
(operand_error_higher_severity_p): Check that
AARCH64_OPDE_A_SHOULD_FOLLOW_B and AARCH64_OPDE_EXPECTED_A_AFTER_B
come between AARCH64_OPDE_RECOVERABLE and AARCH64_OPDE_SYNTAX_ERROR;
their relative order is not significant.
(record_operand_error_with_data): Update after change to
aarch64_operand_error.
(output_operand_error_record): Likewise. Handle
AARCH64_OPDE_A_SHOULD_FOLLOW_B and AARCH64_OPDE_EXPECTED_A_AFTER_B.
* testsuite/gas/aarch64/mops_invalid_2.s,
testsuite/gas/aarch64/mops_invalid_2.d,
testsuite/gas/aarch64/mops_invalid_2.l: New test.
This patch adds support for FEAT_MOPS, an Armv8.8-A extension
that provides memcpy and memset acceleration instructions.
I took the perhaps controversial decision to generate the individual
instruction forms using macros rather than list them out individually.
This becomes useful with a follow-on patch to check that code follows
the correct P/M/E sequence.
[https://developer.arm.com/documentation/ddi0596/2021-09/Base-Instructions?lang=en]
include/
* opcode/aarch64.h (AARCH64_FEATURE_MOPS): New macro.
(AARCH64_ARCH_V8_8): Make armv8.8-a imply AARCH64_FEATURE_MOPS.
(AARCH64_OPND_MOPS_ADDR_Rd): New aarch64_opnd.
(AARCH64_OPND_MOPS_ADDR_Rs): Likewise.
(AARCH64_OPND_MOPS_WB_Rn): Likewise.
opcodes/
* aarch64-asm.h (ins_x0_to_x30): New inserter.
* aarch64-asm.c (aarch64_ins_x0_to_x30): New function.
* aarch64-dis.h (ext_x0_to_x30): New extractor.
* aarch64-dis.c (aarch64_ext_x0_to_x30): New function.
* aarch64-tbl.h (aarch64_feature_mops): New feature set.
(aarch64_feature_mops_memtag): Likewise.
(MOPS, MOPS_MEMTAG, MOPS_INSN, MOPS_MEMTAG_INSN)
(MOPS_CPY_OP1_OP2_PME_INSN, MOPS_CPY_OP1_OP2_INSN, MOPS_CPY_OP1_INSN)
(MOPS_CPY_INSN, MOPS_SET_OP1_OP2_PME_INSN, MOPS_SET_OP1_OP2_INSN)
(MOPS_SET_INSN): New macros.
(aarch64_opcode_table): Add MOPS instructions.
(aarch64_opcode_table): Add entries for AARCH64_OPND_MOPS_ADDR_Rd,
AARCH64_OPND_MOPS_ADDR_Rs and AARCH64_OPND_MOPS_WB_Rn.
* aarch64-opc.c (aarch64_print_operand): Handle
AARCH64_OPND_MOPS_ADDR_Rd, AARCH64_OPND_MOPS_ADDR_Rs and
AARCH64_OPND_MOPS_WB_Rn.
(verify_three_different_regs): New function.
* aarch64-asm-2.c: Regenerate.
* aarch64-dis-2.c: Likewise.
* aarch64-opc-2.c: Likewise.
gas/
* doc/c-aarch64.texi: Document +mops.
* config/tc-aarch64.c (parse_x0_to_x30): New function.
(parse_operands): Handle AARCH64_OPND_MOPS_ADDR_Rd,
AARCH64_OPND_MOPS_ADDR_Rs and AARCH64_OPND_MOPS_WB_Rn.
(aarch64_features): Add "mops".
* testsuite/gas/aarch64/mops.s, testsuite/gas/aarch64/mops.d: New test.
* testsuite/gas/aarch64/mops_invalid.s,
* testsuite/gas/aarch64/mops_invalid.d,
* testsuite/gas/aarch64/mops_invalid.l: Likewise.
Armv8.8-A defines a read-only system register called id_aa64isar2_el1.
The register was previously RES0 and should therefore be accepted
at all architecture levels.
[https://developer.arm.com/documentation/ddi0595/2021-09/AArch64-Registers/ID-AA64ISAR2-EL1--AArch64-Instruction-Set-Attribute-Register-2?lang=en]
opcodes/
* aarch64-opc.c (aarch64_sys_regs): Add id_aa64isar2_el1.
gas/
* testsuite/gas/aarch64/sysreg-diagnostic.s: Test writes to
id_aa64isar2_el1.
* testsuite/gas/aarch64/sysreg-diagnostic.d: Update accordingly.
* testsuite/gas/aarch64/sysreg-diagnostic.l: Likewise.
* testsuite/gas/aarch64/sysreg.s: Test reads from
id_aa64isar2_el1.
* testsuite/gas/aarch64/sysreg.d: Update accordingly.
This patch adds skeleton support for -march=armv8.8-a, testing only
that it correctly inherits from armv8.7-a.
include/
* opcode/aarch64.h (AARCH64_FEATURE_V8_8): New macro.
(AARCH64_ARCH_V8_8): Likewise.
gas/
* doc/c-aarch64.texi: Document armv8.8-a.
* config/tc-aarch64.c (aarch64_archs): Add armv8-8-a
* testsuite/gas/aarch64/v8-8-a.s,
* testsuite/gas/aarch64/v8-8-a.d: New test.
We warn about MOVPRFX instructions that have no following
instruction. This patch adds a line number to the message,
which is useful if the assembly code has multiple text sections.
The new code is unconditional since OBJ_ELF is always defined
for aarch64.
gas/
* config/tc-aarch64.h (aarch64_segment_info_type): Add last_file
and last_line.
* config/tc-aarch64.c (now_instr_sequence): Delete.
(force_automatic_sequence_close): Provide a line number when
reporting unclosed sequences.
(md_assemble): Record the location of the instruction in
tc_segment_info.
* testsuite/gas/aarch64/sve-movprfx_4.l: Add line number to error
message.
* testsuite/gas/aarch64/sve-movprfx_7.l: Likewise.
* testsuite/gas/aarch64/sve-movprfx_8.l: Likewise.
libopcodes has some code to check constraints across sequences
of consecutive instructions. It was added to support MOVPRFX
sequences but is going to be useful for the Armv8.8-A MOPS
feature as well.
Currently the structure has one field to record the instruction
that started a sequence and another to record the remaining
instructions in the sequence. It's more convenient for the
MOPS code if we put the instructions into a single array instead.
No functional change intended.
include/
* opcode/aarch64.h (aarch64_instr_sequence): Replace num_insns
and current_insns with num_added_insns and num_allocated_insns.
opcodes/
* aarch64-opc.c (add_insn_to_sequence): New function.
(init_insn_sequence): Update for new aarch64_instr_sequence layout.
Add the first instruction to the inst array.
(verify_constraints): Update for new aarch64_instr_sequence layout.
Don't add the last instruction to the array.
The immediate form of MSR has a 4-bit immediate field (in CRm).
However, many forms of MSR require a smaller immediate. These cases
are identified by value in operand_general_constraint_met_p,
but they're now the common case rather than the exception.
This patch therefore adds the maximum value to the sys_reg
description and gets the range from there. It also enforces
the minimum of 0, which avoids a situation in which:
msr dit, #2
would give the expected:
Error: immediate value out of range 0 to 1
whereas:
msr dit, #-1
would give:
Error: immediate value out of range 0 to 15
(from the later UIMM4 checking).
Also:
- we were reporting the first error above against the wrong operand
- TCO takes a single-bit immediate, but we previously allowed
all 16 values.
[https://developer.arm.com/documentation/ddi0596/2021-09/Base-Instructions/MSR--immediate---Move-immediate-value-to-Special-Register-?lang=en]
opcodes/
* aarch64-opc.h (F_REG_MAX_VALUE, F_GET_REG_MAX_VALUE): New macros.
* aarch64-opc.c (operand_general_constraint_met_p): Read the
maximum MSR immediate value from aarch64_pstatefields.
(aarch64_pstatefields): Add the maximum immediate value
for each register.
gas/
* testsuite/gas/aarch64/sysreg-4.s: Use an immediate value of 1
rather than 8 for the TCO test.
* testsuite/gas/aarch64/sysreg-4.d: Update accordingly.
* testsuite/gas/aarch64/armv8_2-a-illegal.l: Fix operand number
in MSR immediate error messages.
* testsuite/gas/aarch64/diagnostic.l: Likewise.
* testsuite/gas/aarch64/pan-illegal.l: Likewise.
* testsuite/gas/aarch64/ssbs-illegal1.l: Likewise.
* testsuite/gas/aarch64/illegal-sysreg-4b.s,
* testsuite/gas/aarch64/illegal-sysreg-4b.d,
* testsuite/gas/aarch64/illegal-sysreg-4b.l: New test.
When introducing this code, I forgot that we had some macros for this.
Replace some "manual" pragma diagnostic with some DIAGNOSTIC_* macros,
provided by include/diagnostics.h.
In diagnostics.h:
- Add DIAGNOSTIC_ERROR, to enable a diagnostic at error level.
- Add DIAGNOSTIC_ERROR_SWITCH, to enable -Wswitch at error level, for
both gcc and clang.
Additionally, using DIAGNOSTIC_PUSH, DIAGNOSTIC_ERROR_SWITCH and
DIAGNOSTIC_POP seems to misbehave with g++ 4.8, where we see these
errors:
CXX ada-tasks.o
/home/smarchi/src/binutils-gdb/gdb/ada-tasks.c: In function void read_known_tasks():
/home/smarchi/src/binutils-gdb/gdb/ada-tasks.c:998:10: error: enumeration value ADA_TASKS_UNKNOWN not handled in switch [-Werror=switch]
switch (data->known_tasks_kind)
^
Because of the POP, the diagnostic should go back to being disabled,
since it was disabled in the beginning, but that's not what we see
here. Versions of GCC >= 5 compile correctly.
Work around this by making DIAGNOSTIC_ERROR_SWITCH a no-op for GCC < 5.
Note that this code (already as it exists in master today) enables
-Wswitch at the error level even if --disable-werror is passed. It
shouldn't be a problem, as it's not like a new enumerator will appear
out of nowhere and cause a build error if building with future
compilers. Still, for correctness, we would ideally want to ask the
compiler to enable -Wswitch at its default level (as if the user had
passed -Wswitch on the command-line). There doesn't seem to be a way to
do this.
Change-Id: Id33ebec3de39bd449409ea0bab59831289ffe82d
When configuring gas, I get:
config.status: error: cannot find input file: `doc/Makefile.in'
This is because configure is out-of-date, re-generate it.
Change-Id: Iaa5980c282900d9fd23b90f0df25bf8ba3676498
When configuring libctf, I get:
config.status: error: cannot find input file: `doc/Makefile.in'
This is because configure is out-of-date, re-generate it.
Change-Id: Ie69acd33012211a4620661582c7d24ad6d2cd169
These have been around for decades but don't appear to be used, and
trying to build them (e.g. `make archive.p archive.ip`) doesn't work,
so just delete it all.
The "info source" command, with a DWARF-compile program, always show
that the debug info is "DWARF 2":
(gdb) info source
Current source file is test.c
Compilation directory is /home/smarchi/build/binutils-gdb/gdb
Located in /home/smarchi/build/binutils-gdb/gdb/test.c
Contains 2 lines.
Source language is c.
Producer is GNU C17 9.3.0 -mtune=generic -march=x86-64 -g3 -gdwarf-5 -O0 -fasynchronous-unwind-tables -fstack-protector-strong -fstack-clash-protection -fcf-protection.
Compiled with DWARF 2 debugging format.
Includes preprocessor macro info.
Change it to display the actual DWARF version:
(gdb) info source
Current source file is test.c
Compilation directory is /home/smarchi/build/binutils-gdb/gdb
Located in /home/smarchi/build/binutils-gdb/gdb/test.c
Contains 2 lines.
Source language is c.
Producer is GNU C17 9.3.0 -mtune=generic -march=x86-64 -g3 -gdwarf-5 -O0 -fasynchronous-unwind-tables -fstack-protector-strong -fstack-clash-protection -fcf-protection.
Compiled with DWARF 5 debugging format.
Includes preprocessor macro info.
The comp_unit_head::version field is guaranteed to be between 2 and 5,
thanks to the check in read_comp_unit_head. So we can still use static
strings to pass to record_debugformat, and keep it efficient.
In the future, when somebody will update GDB to support DWARF 6, they'll
hit this assert and have to update this code.
Change-Id: I3270b7ebf5e9a17b4215405bd2e365662a4d6172
1. Discard input .note.gnu.build-id sections.
2. Clear the build ID field before writing.
3. Use bfd_make_section_anyway_with_flags to create the output
.note.gnu.build-id section.
PR ld/28639
* ldelf.c (ldelf_after_open): Discard input .note.gnu.build-id
sections, excluding the first one.
(write_build_id): Clear the build ID field before writing.
(ldelf_setup_build_id): Use bfd_make_section_anyway_with_flags
to create the output .note.gnu.build-id section.
* testsuite/ld-elf/build-id.exp: New file.
* testsuite/ld-elf/pr28639a.rd: Likewise.
* testsuite/ld-elf/pr28639b.rd: Likewise.
* testsuite/ld-elf/pr28639c.rd: Likewise.
* testsuite/ld-elf/pr28639d.rd: Likewise.
As defined on: https://systemd.io/COREDUMP_PACKAGE_METADATA/
this note will be used starting from Fedora 36. Allow
readelf --notes to pretty print it:
Displaying notes found in: .note.package
Owner Data size Description
FDO 0x00000039 FDO_PACKAGING_METADATA
Packaging Metadata: {"type":"deb","name":"fsverity-utils","version":"1.3-1"}
Signed-off-by: Luca Boccassi <luca.boccassi@microsoft.com>
With gdb.multi/multi-arch-exec.exp I run into:
...
Running src/gdb/testsuite/gdb.multi/multi-arch-exec.exp ...
ERROR: tcl error sourcing src/gdb/testsuite/gdb.multi/multi-arch-exec.exp.
ERROR: wrong # args: extra words after "else" clause in "if" command
while executing
"if [istarget "powerpc64*-*-*"] {
set march "-m64"
} else if [istarget "s390*-*-*"] {
set march "-m31"
} else {
set march "-m32"
}"
...
Fix the else if -> elseif typo.
Tested on x86_64-linux.
When running test-case gdb.arch/i386-pkru.exp on a machine with "Memory
Protection Keys for Userspace" support, we run into:
...
(gdb) PASS: gdb.arch/i386-pkru.exp: probe PKRU support
print $pkru^M
$2 = 1431655764^M
(gdb) FAIL: gdb.arch/i386-pkru.exp: pkru register
...
The test-case expects the $pkru register to have the default value 0, matching
the "init state" of 0 defined by the XSAVE hardware.
Since linux kernel version v4.9 containing commit acd547b29880 ("x86/pkeys:
Default to a restrictive init PKRU"), the register is set to 0x55555554 by
default (which matches the printed decimal value above).
Fix the FAIL by accepting this value for linux.
Tested on x86_64-linux.
This commit makes use of a scoped_restore object to control the
remote_state::starting_up flag within the remote_target::start_remote
method.
Ideally I would have liked to create the scoped_restore inside
start_remote and just leave the restore in place until the end of the
scope, however, I'm worried that doing this would change the behaviour
of GDB. Specifically, in start_remote, the following code is executed
once the starting_up flag has been restored to its previous value:
if (breakpoints_should_be_inserted_now ())
insert_breakpoints ();
I think (but am not 100% sure) that calling install_breakpoints could
end up back inside remote_target::can_download_tracepoint, which does
check the value of remote_state::starting_up. And so, I'm concerned
that leaving the scoped_restore in place until the end of start_remote
will cause a possible change in behaviour.
To avoid this, and to leave things as close to the current behaviour
as possible, I've split remote_target::start_remote into two, there's
the main function body which moves into remote_target::start_remote_1,
this function uses the scoped_restore to change the ::starting_up
flag, then there's the old remote_target::start_remote, which now just
calls ::start_remote_1, and then does the insert_breakpoints call.
There should be no user visible changes after this commit, unless
there's a situation where the ::starting_up flag could previously have
been left set, if this was the case, then this situation should no
longer be possible.
When my system isn't properly configured to generate core files in the
local directory, I see these DUPLICATEs:
DUPLICATE: gdb.base/corefile-buildid.exp: could not generate core file
Fix that by having a single with_test_prefix around that message and
what follows.
Change-Id: I4ac245fcce1c666db56e3bad3582aa17f183dcba
The expect file has a procedure append_arch_options which sets march based
the istarget. The current if / else statement does not check for
powerpc64. The else statement is hit which sets march to -m32. This
results in compilation errors on 64-bit PowerPC.
This patch adds an if statement to check for powerpc64 and if true sets mach
to -m64.
The patch was tested on a Power 10 system. No compile errors were generated.
The test completes with 1 expected pass and no failures.
