| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Remove includes reported as unused by clangd. Then, add any includes
necessary to get rid of errors (includes possibly relying on previous
includes)..
I didn't remove the includes of gdb-safe-ctypes.h, because it appears to
do some some preprocessor magic. I'm afraid that removing these
includes could change the behavior unintentionally.
Change-Id: I4c5b652355c3bbce022fe0d447a72dc4e1d17d34
|
|
It seems like gdb_curses.h is included whenever we want to access
ncurses functionality, instead of including directly ncurses.h. As a
result, clangd often erroneously shows that gdb_curses.h inclusions are
unused.
By adding those pragmas, clangd (and the include-what-you-use tool)
understands that gdb_curses.h is a valid provider for whatever these
ncurses.h files provide.
Change-Id: Ia8acd761dae1577f7151d5fb558f35514b4e4ea2
|
|
Change the `TUI_*` macros to access known windows to functions. Define
them in their respective files, because trying to define them in
tui-data.h would end up causing include cycles.
Change-Id: I1e38cee843984c48ab34030b19dac0d726f851af
|
|
For files under the dwarf2 directory:
- Remove includes that are reported as unused by clangd.
- Add any include required to ensure that all files include what they
use.
Change-Id: I2f13d75f18a390df480c6da8bdab1edba1e035e1
|
|
It uses "allocate_on_obstack".
Change-Id: I49fbfcb49a5adadae2381a89060914d90b21384e
|
|
Remove some includes reported as unused by clangd. Add some includes in
other files that were previously relying on the transitive include.
Change-Id: Ibdd0a998b04d21362a20d0ca8e5267e21e2e133e
|
|
Remove some includes reported as unused by clangd.
Change-Id: Iebd986eaf42409f1e526f09df0fcb0ce45c2fad6
|
|
Remove some includes reported as unused by clangd.
Change-Id: I36d388bcff166f6baafa212f0bcbe8af64b2946d
|
|
invoking src-release.sh
|
|
|
|
|
|
|
|
While preparing the new release it was discovered that commit:
commit 824083f34c222aa7419e2ea58e82d6f230d5f531
Date: Fri Apr 12 17:47:20 2024 +0100
gdb/doc: use silent-rules.mk in the Makefile
was causing problems. Given a release tar file, an attempt to build
and install GDB would give an error like this:
[...]
TEXI2POD gdb.pod
cannot find GDBvn.texi at ../../../gdb-15.0.50.20240508/gdb/doc/../../etc/texi2pod.pl line 251, <GEN0> line 16.
make[5]: *** [Makefile:663: gdb.pod] Error 2
The problem here is how the man pages are built, and how they are
distributed within a release.
Within the development (git) tree, the man page files are not part of
the source tree, these files are built as needed. Within a release
tar file though, the man pages are included. The idea being that a
user can build and install GDB, including getting the man pages,
without having to install the tools needed to generate the man pages.
The man pages are generated in a two step process. First the .texi
file is processed with texi2pod to create a .pod file, then this .pod
file is processed to create the .1 or .5 man file.
Prior to the above commit these two steps were combined into a single
recipe, this meant that when a user performed a build/install from a
release tree all of the dependencies, as well as the final result,
were all present in the source tree, and so nothing needed to be
rebuilt.
However, the above commit split the two steps apart. Now we had a
separate rule for building the .pod files, and the .1/.5 man page
files depended on the relevant .pod file.
As the .pod files are not shipped in a GDB release, this meant that
one of the dependencies of the man page files was now missing. As a
result if a user tried to install from a release tree a rebuild of the
.pod files would be attempted, and if that succeeded then building the
man pages would follow that.
Unfortunately, building the .pod files would fail as the GDBvn.texi
file, though present in the source tree, was not present in the build
tree, which is where it is needed for the .pod file generation to
work.
To fix this, I propose merging the .pod creation and the .1/.5 man
page creation back into a single recipe. Having these two steps split
is probably the "cleaner" solution, but makes it harder for us to
achieve our goal of shipping the prebuilt man page files. I've added
a comment explaining what's going on (such a comment would have
prevented this mistake having been made in the first place).
One possibly weird thing here is that I have left both an
ECHO_TEXI2POD and a ECHO_TEXI2MAN in the rule $(MAN1S) and $(MAN5S)
recipes. This is 100% not going to break anything, these just print
two different progress messages while executing the recipes, but I'm
not sure if this is considered poor style or not. Maybe we're only
supposed to have a single ECHO_* per recipe?
Anyway, even if this is poor style, I figure it really is just a style
thing. We can tweak this later as needed. Otherwise, this commit
should fix the current issue blocking the next GDB release.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
In some cases using section names instead of symbol names for
displaying an address is more useful.
If the symbol falls outside the section where the address is
then likely it is not useful to display the address relative to.
And if symbols are stripped from a binary then printing the
section that contains the address is more useful than printing
<no sym>.
|
|
Filter symbols before binary searching for the right symbol to display
for a given address, such that only displayable symbols are present and
at most one per address.
The current logic does not handle multiple symbols for the same address
well if some of them are empty, the selected symbol is not stable with
respect to an unrelated symbol table change and on aarch64 often mapping
symbols are displayed which is not useful.
Filtering solves these problems at the cost of a linear scan of the
sorted symbol table.
The heuristic to select the best symbol likely could be improved, this
patch aims to improve symbol display for RELR without complex logic
such that the output is useful and stable for ld tests.
|
|
Except for very few insns mnemonic suffixes aren't permitted in Intel
syntax. Warn about such for now, indicating that they will be outright
refused down the road.
While fiddling with testcases to address fallout, drop a few things
which should never have been tested as valid Intel syntax.
Also add a previously missing line to simd-suffix.d.
|
|
Since we uniformly permit D suffixes in Intel mode whenever in AT&T mode
an L suffix may be used, we need to be consistent with this.
Take the easy route, despite that still leading to an anomaly which is
also visible from the new testcase:
shld eax, ecx, 1
shld eax, ecx, cl
can mean two things with APX: SHL with a D suffix in NDD EVEX encoding,
or the traditional SHLD in legacy encoding.
|
|
PR31796 is the result of lack of aarch64 support in obj-coff-seh.c.
Nick fixed this with commit 73c8603c3f. Make the seh support
consistently warn in future if some archictecture is missing, rather
than giving internal errors.
PR 31796
* config/obj-coff-seh.c (verify_target): New function.
(obj_coff_seh_handler, obj_coff_seh_endproc, obj_coff_seh_proc),
(obj_coff_seh_endprologue): Use it.
|
|
|
|
The default memory region sizes for PRU were set somewhat arbitrarily to
the sizes of the most popular BeagleBone board with AM33x SoC. But the
PRU toolchain documentation has always instructed to use SoC-specific
spec files to override the defaults and set the correct memory sizes [1].
The small default memory sizes can cause IMEM memory region overflow
even for simple printf("Hello world") programs, as usually done by
Autotools checks. The stdio is simply too big to fit in 8K
instruction memory. This can confuse the check and lead to wrong
feature selection during configure [2].
Fix by bumping the default DMEM and IMEM memory sizes.
There is no need to backport this patch. Issue was caught with a
feature-rich newlib build used for daily CI. The release builds of the
PRU toolchain use stripped newlib configuration, which does not overflow
the IMEM region, even for 8K.
[1] https://github.com/dinuxbg/gnuprumcu
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115158
Signed-off-by: Dimitar Dimitrov <dimitar@dinux.eu>
|
|
Nothing overrides tui_win_info::make_window, so remove the "virtual".
Tested by rebuilding.
|
|
Introduces instructions for the SVE2 lut extension for AArch64. They are documented in the following links:
* luti2: https://developer.arm.com/documentation/ddi0602/2024-03/SVE-Instructions/LUTI2--Lookup-table-read-with-2-bit-indices-?lang=en
* luti4: https://developer.arm.com/documentation/ddi0602/2024-03/SVE-Instructions/LUTI4--Lookup-table-read-with-4-bit-indices-?lang=en
These instructions use new SVE2 vector operands. They are called
SVE_Zm1_23_INDEX, SVE_Zm2_22_INDEX, and Zm3_12_INDEX and they have
1 bit, 2 bit, and 3 bit indices respectively.
The lsb and width of these new operands are the same as many existing
operands but the convention is to give different names to fields that
serve different purpose so we introduced new fields in aarch64-opc.c
and aarch64-opc.h.
We made a design choice for the second operand of the halfword variant of
luti4 with two register tables. We could have either defined a new operand,
like SVE_Znx2, or we could have use the existing operand SVE_ZnxN. With
the new operand, we would need to implement constraints on register
lists based on either operand or opcode flag. With existing operand, we
could just existing constraint checks using opcode flag. We chose
the second approach and went with SVE_ZnxN and added opcode flag to
enforce lengths of vector register list operands. This way, we can reuse
the existing constraint check logic.
|
|
Introduces instructions for the Advanced SIMD lut extension for AArch64. They are documented in the following links:
* luti2: https://developer.arm.com/documentation/ddi0602/2024-03/SIMD-FP-Instructions/LUTI2--Lookup-table-read-with-2-bit-indices-?lang=en
* luti4: https://developer.arm.com/documentation/ddi0602/2024-03/SIMD-FP-Instructions/LUTI4--Lookup-table-read-with-4-bit-indices-?lang=en
These instructions needed definition of some new operands. We will first
discuss operands for the third operand of the instructions and then
discuss a vector register list operand needed for the second operand.
The third operands are vectors with bit indices and without type
qualifiers. They are called Em_INDEX1_14, Em_INDEX2_13, and Em_INDEX3_12
and they have 1 bit, 2 bit, and 3 bit indices respectively. For these
new operands, we defined new parsing case branch. The lsb and width of
these operands are the same as many existing but the convention is to
give different names to fields that serve different purpose so we
introduced new fields in aarch64-opc.c and aarch64-opc.h for these new
operands.
For the second operand of these instructions, we introduced a new
operand called LVn_LUT. This represents a vector register list with
stride 1. We defined new inserter and extractor for this new operand and
it is encoded in FLD_Rn. We are enforcing the number of registers in the
reglist using opcode flag rather than operand flag as this is what other
SIMD vector register list operands are doing. The disassembly also uses
opcode flag to print the correct number of registers.
|
|
This changes target_ops::thread_events and target_thread_events to use
'bool'. The callers were already doing this.
Tested by rebuilding.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
|
|
PR 31796
|
|
|
|
The autogenerated files in opcodes use spaces for indentation.
Changing that would be a lot of work to little benefit, so add a local
override to the white-space rules, so patches apply cleanly.
|
|
|
|
The type U RISC-V instruction format in gas/doc/c-riscv.texi shows the
bit arrangement of the simm20 immediate that belongs to the J type;
It should be just `simm20[19:0]`. The current behavior of `gas` matches
the proposed documentation change.
Additionally, the opcode is called `opcode6` despite of having 7 bits.
Rename it to `opcode7`.
gas/
* doc/c-riscv.texi: Fix U type, and replace opcode6 with opcode7.
|
|
|
|
I re-ran make-target-delegates.py and discovered that the tree was out
of sync. This patch corrects the problem.
|
|
This was originally reported by Hau Hsu <hau.hsu@sifive.com>.
Similar to commit 51a8a7c2e3cc0730831963651a55d23d1fae624d
We shouldn't use riscv_elf_append_rela to add dynamic relocs into .rela.iplt
in the riscv_elf_relocate_section when handling ifunc data reloc R_RISCV_32/64.
This just like what did in the riscv_elf_finish_dynamic_symbol.
bfd/
* elfnn-riscv.c (riscv_elf_relocate_section): We shouldn't use
riscv_elf_append_rela to add dynamic relocs into .rela.iplt in the
riscv_elf_relocate_section when handling ifunc data reloc.
ld/
* testsuite/ld-riscv-elf/ifunc-overwrite.s: Updated and renamed.
* testsuite/ld-riscv-elf/ifunc-overwrite-exe.rd: Likewise.
* testsuite/ld-riscv-elf/ifunc-overwrite-pic.rd: Likewise.
* testsuite/ld-riscv-elf/ifunc-overwrite-pie.rd: Likewise.
* testsuite/ld-riscv-elf/ifunc-overwrite.d: Renamed.
|
|
This was originally reported by Ard Biesheuvel <ardb@kernel.org>.
The followings are reproduce steps,
https://lore.kernel.org/all/202404260640.9GQVTmrw-lkp@intel.com/T/#u
The segment fault happens in the riscv_elf_finish_dynamic_sections when the
output got section is an ABS. Refer to MIPS code, they added an extra
bfd_is_abs_section check to avoid ABS got, so this seems the right and easier
way to go in the short-term.
bfd/
* elfnn-riscv.c (riscv_elf_finish_dynamic_sections): Set sh_entsize
and fill the got entries only when the got isn't an ABS section, and
the size of got is larger than zero. The similar goes for gotplt,
except we already reported error when the gotplt is an ABS.
|
|
ld -z separate-code let .text and .rodata in two different but read only
segment. If the symbol and pc in two segment, the offset from pc to
symbol need to consider segment alignment.
Add a function 'loongarch_two_sections_in_same_segment' to determine
whether two sections are in the same segment.
|
|
|
|
This commit a new section for the next release branch, and renames
the section of the current branch, now that it has been cut.
|
|
Now that the GDB 15 branch has been created,
this commit bumps the version number in gdb/version.in to
16.0.50.DATE-git
For the record, the GDB 15 branch was created
from commit 3a624d9f1c5ccd8cefdd5b7ef12b41513f9006cd.
Also, as a result of the version bump, the following changes
have been made in gdb/testsuite:
* gdb.base/default.exp: Change $_gdb_major to 16.
|
|
|
|
This is the v2 patch I am checking in.
H.J.
|
|
|
|
Adjust the gas testsuite to suit commit de203ed568f6.
* testsuite/gas/loongarch/relax-cfi-fde-DW_CFA_advance_loc.d:
Expect data alignment of -8. Tidy.
|
|
PR gas/31752
These are effectively macro-like, without any separate macro definition.
They already support \@, so they would better also support \+. This
allows, where desired, to get away without maintaining an explicit count
variable in source code.
With this the recently introduced testcase doesn't need any xfails
anymore.
|
|
The present handling of inner double quotes can lead to very strange
diagnostics. Follow one of the two possible interpretations of the doc:
@dots{} referring to possibly multiple white space separated
@var{values}, each of which may be quoted. The original implementation,
prior to 465e5617233f ("PR gas/3856"), hints at the other possible
interpretation: When quoted there's only a single @var{values}, with
inner quotes taken as ordinary characters. That, however, seems overall
less useful to me.
While touching the documentation, mirror the (inverse) spelling
correction (@section line inconsistent with actual description) to .irp
as well.
|
|
As already suggested during review, rather than having an extra
conditional in build_modrm_byte() (a code path used for quite a few
more insns, including even certain GPR ones), adjust the attribute in
the installed template to properly describe things with operands
swapped.
|
|
These run after template matching. Therefore operands are already known
to match the template in use. With the loop bodies skipping anything not
a GPR in the actual operands, there's therefore no need to check the
template's operand type for permitting Reg or Accum.
At the same time bring the three functions in sync for the "byte" part
of the logic, as far as checking the template for other sizes (qword
specifically) goes. Plus drop a stale comment from check_qword_reg(),
when all three are now behaving the same in this regard.
|
|
Properly reject inappropriate suffixes (No_lSuf / No_qSuf mistakenly
omitted by cf665fee1d6c ["x86: re-work AVX512 embedded rounding / SAE"]),
to avoid emitting bad or arbitrarily guessed instructions. Interestingly
check_{long,qword}_suffix() don't help here, which perhaps is another
indication that the way they work right now isn't quite appropriate.
Sadly correcting just the templates breaks operand ambiguity detection,
since so far that worked from a single template permitting more than one
suffix. Here we have ambiguity though which can now be noticed only when
taking all (matching) templates together. Therefore we need to determine
further matching templates (see code comments for constraints), to then
accumulate permitted suffixes across all of them.
|
|
gdb.threads/attach-many-short-lived-threads.exp
When running test-case gdb.threads/attach-many-short-lived-threads.exp, I run
regularly into PR26286:
...
(gdb) continue^M
Continuing.^M
[LWP ... exited]^M
...
[LWP ... exited]^M
^M
Program terminated with signal SIGTRAP, Trace/breakpoint trap.^M
The program no longer exists.^M
(gdb) FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 9: \
break at break_fn: 1
...
Add a kfail for this, such that we have:
...
(gdb) KFAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 9: \
break at break_fn: 1 (PRMS: threads/26286)
...
Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Tested on x86_64-linux.
|
|
|
|
In a remote testing setup, I saw this error:
~~~
(gdb) FAIL: gdb.base/foll-fork.exp: check_fork_catchpoints: runto: run to main
ERROR: tcl error sourcing gdb/gdb/testsuite/gdb.base/foll-fork.exp.
ERROR: expected boolean value but got ""
while executing
"if { ![check_fork_catchpoints] } {
untested "follow-fork not supported"
return
}"
(file "gdb/gdb/testsuite/gdb.base/foll-fork.exp" line 434)
invoked from within
"source gdb/gdb/testsuite/gdb.base/foll-fork.exp"
("uplevel" body line 1)
invoked from within
"uplevel #0 source gdb/gdb/testsuite/gdb.base/foll-fork.exp"
invoked from within
"catch "uplevel #0 source $test_file_name""
Remote debugging from host 172.0.1.3, port 37766
Killing process(es): 1171
Quit
~~~
The actual reason for this were some connection problems. Though the
function check_fork_catchpoints shouldn't return an empty string, especially
as it promises to always return 0 or 1. Fix that.
Approved-By: Tom Tromey <tom@tromey.com>
|
