If we're skipping _BEGIN_ and _END_ we should certainly skip all the other
ABI-required always-emitted symbols given in ld/emultempl/solaris2*em as
well. (This fixes a couple of diagnostics tests, but that's just because
the tests are quite sensitive to CTF section sizes, and introducing any
symtypetab entries for those tests perturbs those.)
Some of these are usually STT_NOTYPE, but not always: if programs already
emitted the symbol they might end up with any type, in particular
STT_OBJECT, and appear in the symtypetabs.
[nca: added commit log, added more symbols]
libctf/
PR libctf/33162
* ctf-serialize.c (ctf_symtab_skippable): Skip
more always-emitted Solaris symbols.
We generate de-commented version scripts for Solaris ld (whose
-z gnu-version-script linker option does not support comments),
but after we switched to generating libctf-nobfd.ver itself, we
failed to adjust this code to pick it up from the new location.
libctf/
PR libctf/33161
* configure.ac: Fix libctf-nobfd.ver path on Solaris.
* configure: Regenerated.
Writable mmaps and read are inconsistent with each other on Solaris 11.4,
which breaks archive writing. Simply assert that Solaris 2.11 doesn't have
mmap, falling back to read(): the archive format is being bumped shortly, to
one with completely different writeout code, so this workaround need not
stay for long.
[nca: added commit log]
libctf/
PR libctf/29292
* configure.ac: Turn off mmap on Solaris 2.11.
* configure: Regenerated.
SFrame generation code assumes that since DW_CFA_restore means
restoration of the state of the register to the one at the beginning of
the function, there must be a state to restore to (hence the gas_assert
(cie_fre)).
This assumption needs adjustment. DW_CFA_restore may be present in the
very beginning of a (e.g., cold) function, with no initialized state for
SFrame functions to restore to.
gas/
PR gas/33170
* gas/gen-sframe.c (sframe_xlate_do_restore): Use current FRE if
CIE FRE is not yet setup.
gas/testsuite/
PR gas/33170
* gas/cfi-sframe/cfi-sframe.exp: New test.
* gas/cfi-sframe/cfi-sframe-x86_64-pr33170.d: New test.
* gas/cfi-sframe/cfi-sframe-x86_64-pr33170.s: New test.
Modernize test-case gdb.base/command-line-input.exp using clean_restart,
multi_line and string_to_regexp.
Tested on x86_64-linux.
Approved-By: Andrew Burgess <aburgess@redhat.com>
Gdb has the ability to gather input over several lines [1], for instance this:
...
(gdb) print 1
$1 = 1
(gdb)
...
can also be typed as:
...
(gdb) print\
1
$2 = 1
(gdb)
...
Furthermore, if we type a command but change our mind, we can abort using ^C
and start over using a fresh gdb prompt [2]:
...
(gdb) print 1❌️ Quit
(gdb) echo 1\n
1
(gdb)
...
Now say we type a multi-line command but abort it, we get:
...
(gdb) print\
1❌️ Quit
(gdb) echo 1\n
❌️ Undefined command: "printecho". Try "help".
(gdb)
...
Using "set trace-commands on", we can see what happened:
...
+printecho 1\n
..
Gdb has prepended the first line of the cancelled multi-line command to the
following command.
Fix this by clearing current_ui->line_buffer on catching a gdb_exception in
start_event_loop.
Tested on x86_64-linux.
Approved-By: Andrew Burgess <aburgess@redhat.com>
PR cli/33063
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33063
[1] https://sourceware.org/gdb/current/onlinedocs/gdb.html/Output.html
[2] https://sourceware.org/gdb/current/onlinedocs/gdb.html/Quitting-GDB.html
As I was working on an unrelated patch, I noticed that all calls to
make_source_files_completion_list had both parameters of the function
call being the same pointer. I think we can remove that redundancy and
make that call with just one parameter.
Approved-By: Andrew Burgess <aburgess@redhat.com>
I found these two small nits while working in this file.
Change-Id: Ibdaa57262f3fe363b039fbad746e285fa7b52f8b
Approved-By: Andrew Burgess <aburgess@redhat.com>
To rename a file on Windows, the target name cannot exist. Removing file
prior to renaming ensures this is handled.
To remove a file on Windows, the file cannot be open. Closing the bfd
handle ensures this is handled.
Moved call to free on isympp / osympp to after bfd is closed to align
with comment earlier in the cmdline_add_object_only_section function.
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
Running the standalone test `gdb.reverse` with the target board configuration `unix/-fPIE/-pie` leads to the following failure:
'''
FAIL: gdb.reverse/i386-avx-reverse.exp: verify ymm15 before vbroadcastsd
'''
This happens because the test expects values stored in `dyn_buf0`, but instead (in the test source) the address of the buffer itself
got broadcast to xmm15 (and thus to ymm15).
This happened because the pointer to the start of `dyn_buf0` wasn't dereferenced (see 'vpbroadcast_test' in 'i386-avx-reverse.c'):
'''
asm volatile ("vbroadcastss %0, %%xmm15": : "m" (dyn_buf0));
^
'''
and this consequently lead to the test failing for the next instruction (`vbroadcastsd`), which depended on the correct value being broadcast to the register.
Also, updated the corresponding expected output (gdb.reverse/i386-avx-reverse.exp) to match.
Tested on x86-64 Linux.
Signed-off-by: Shiven Kashyap <shivenkashyap24@gmail.com>
Approved-By: Guinevere Larsen <guinevere@redhat.com>
Considering the following case,
% cat tmp.s
.option pic
.text
.global _start
_start:
nop
.section .discard.s, "ax"
la x1, _start
% cat tmp.ld
OUTPUT_ARCH(riscv)
ENTRY(_start)
SECTIONS
{
/DISCARD/ : { *(.discard.*) }
. = 0x10000;
.text : { *(.text) }
. = 0x20000;
.got : { *(.got) *(.got.plt)}
. = 0x30000;
.data : { *(.data) *(.data.*) }
}
% riscv64-unknown-linux-gnu-as tmp.s -o tmp.o
% riscv64-unknown-linux-gnu-ld -pie -Ttmp.ld tmp.o
riscv64-unknown-linux-gnu-ld: BFD (GNU Binutils) 2.44.50.20250624 assertion fail binutils-gdb/bfd/elfnn-riscv.c:3638
This happens when pie and the input sections, which refers to the global
symbol by got, are all discarded. Since referenced sections are all discarded,
we won't go into relocate_section for those sections, the got entry also won't
be initialized. Therefore, we will get assert fail when adding the RELATIVE
reloc in the finish_dynamic_symbol.
After seeing other target codes, there are two root causes as follows,
1. risc-v may call bfd_elf_link_record_dynamic_symbol in the allocate_dynrelocs
for not only undefweak symbols.
2. risc-v is missing the code to add RELATIVE to R_RISCV_GOT entries in the
relocate_section if a symbol is not dynamic and is not undefined weak under
pic and pie.
If we call bfd_elf_link_record_dynamic_symbol, then the global symbol will be
forced to dynamic, so the h->dynindx will forced to be a number rather than -1,
even it should be -1. Once h->dynindx != -1 and pic/pie, it will go into
finish_dynamic_symbol and insert RELATIVE/64 relocs for the got entry; For the
above case there are two issues,
1. The global symbol _start is forced to be dynamic in the allocate_dynrelocs.
when pie and all the referenced section are discarded, it won't go into
relocate_section to initialize the got entry, so it will cause assert fail
when adding RELATIVE reloc in the finish_dynamic_symbol. The assert fail
represents another problem - if we don't initialize the got entry in the
relocate_section under pie, which means we don't need to go into the
finish_dynamic_symbol and don't need a RELATIVE reloc for the got entry,
it should be NONE reloc.
2. Without linking any discarded section, it originally forces every RELATIVE
relocs added for every got by the finish_dynamic_symbol. Even The final
result looks correct under pie (genearte a RELATIVE reloc for got entry),
not sure if it may cause other problems for some special cases, excpet the
above one.
Therefore, this patch try to fix the above assert fail, and also clarify the
behavior of the allocate_dynrelocs which should only call bfd_elf_link_record_dynamic_symbol
for undefweak symbols, and add the missing code to generate RELATIVE reloc to
R_RISCV_GOT entries in the relocate_section if a symbol is not dynamic and is
not undefined weak under pic and pie.
Passed the gcc/binutils regressions of riscv-gnu-toolchain at least.
The indices into the auto-generated tables for opcodes are relatively
unstable. Adding a new opcode can permute the code significantly.
But most of this churn is down to changes in the index values. To
minimize this use enumerated constants. While the index values
change, the enumeration names will need to do so far less often, so
most of the changes in the generated code become localized to the
addition (occasionally removal) of opcodes. This change also makes
the state-change comments unnecessary. The enumeration names contain
the same information (and more), so these are simply deleted.
The enumeration values are placed in a new header file, aarch64-tbl-2.h,
so aarch64-gen gains a new option to build this header and the Makefile
rules are adjusted accordingly.
The generated aarch64 operand tables use index values into an array. But if
the table of operands is modified by inserting a new operand into the middle
of the table, *all* the index values can change, leading to a lot of
churn in the generated output.
include/opcode/aarch64.h already provides an enumeration for the operands,
so make use of that instead of printing out the raw index values.
This field was misnamed in aarch64_opcode_table. It previously didn't
matter too much as the name field only appeared in dumps. But it
doesn't match the enum in include/opcode/aarch64.h and we will shortly
start to rely on that.
These method declarations are unused, remove them. I guess that when
writing a previous patch, changed some free functions to be methods,
then changed my mind, and forgot to remove the declarations.
Change-Id: I7452bb773af0f32c4aae2fe6a4fc663ec65c3f15
PR gprofng/33151
gprofng ignores functions that are compiled as weak symbols. This
heavily affects C++ class methods that are always compiled by g++
and clang++ as weak symbols. In this case 'gprofng display text'
just displays <static>@ADDRESS(<FILENAME>) instead of proper method
name.
The bug has been introduced in the commit 470a0288a8.
PR cli/28887 reports the following problem when using a custom prompt.
First, we set up the custom prompt (with ^ marking the position of the
blinking cursor on the line above):
...
$ gdb -q -ex "set prompt \033[31mgdb$ \033[0m"
gdb$
^
...
Then we type some string, and enter it into the command history:
...
gdb$ some long command
❌️ Undefined command: "some". Try "help".
gdb$
^
...
We use C-p to fetch the previous command:
...
gdb$ some long command
^
...
Sofar, so good.
Finally, we use C-a which should move the cursor to just after the prompt, but
instead we get:
...
gdb$ some long command
^
...
This is fixed by using \001 and \002:
...
(gdb) set prompt \001\033[31m\002gdb$ \001\033[0m\002
...
aka as RL_PROMPT_START_IGNORE and RL_PROMPT_END_IGNORE [1].
Add an example to the documentation showing the use of these markers.
The added example is the equivalent of the "\[\e[0;34m\](gdb)\[\e[0m\]"
example documented at gdb.prompt.substitute_string that can be used with
"set extended-prompt".
While working on this, I noticed that "show prompt" doesn't show back the
original string, using '\e' instead of '\033':
...
gdb$ show prompt
Gdb's prompt is "\001\e[31m\002gdb$ \001\e[0m\002".
...
and that the shown string can't be used as an argument to "set prompt":
...
gdb$ set prompt \001\e[31m\002gdb$ \001\e[0m\002
e[31mgdb$ e[0m
...
I've filed this as PR cli/33184.
Approved-By: Eli Zaretskii <eliz@gnu.org>
[1] https://tiswww.case.edu/php/chet/readline/readline.html
I noticed that the test names in test-case
gdb.base/backtrace-through-cu-nodebug.exp are a bit inconsistent:
...
PASS: $exp: no-cfi: maint frame-unwinder disable ARCH
PASS: $exp: verify no-filters unwind fail without CFI
PASS: $exp: maint flush register-cache
PASS: $exp: verify unwind fail without CFI
PASS: $exp: cfi: maint frame-unwinder disable ARCH
PASS: $exp: Verify unwinding works based only on CFI information
...
There's both a no-cfi prefix, and "without CFI".
Fix this by using proc_with_prefix, getting us a consistent prefix:
...
PASS: $exp: no-cfi: maint frame-unwinder disable ARCH
PASS: $exp: no-cfi: verify no-filters unwind fail
PASS: $exp: no-cfi: maint flush register-cache
PASS: $exp: no-cfi: verify unwind fail
PASS: $exp: cfi: maint frame-unwinder disable ARCH
PASS: $exp: cfi: Verify unwinding works
...
While we're at it, use multi_line to make a regexp more readable.
Tested on aarch64-linux.
Reviewed-By: Keith Seitz <keiths@redhat.com>
With a gdb build without python support, and test-case
gdb.base/backtrace-through-cu-nodebug.exp I run into:
...
(gdb) bt^M
Required frame unwinder may have been disabled, \
see 'maint info frame-unwinders'^M
(gdb) FAIL: $exp: verify unwind fail without CFI
...
With a gdb build with python support we have instead:
...
(gdb) bt^M
Python Exception <class 'gdb.error'>: \
Required frame unwinder may have been disabled, \
see 'maint info frame-unwinders'^M
(gdb) PASS: $exp: verify unwind fail without CFI
...
but if I change the "bt" into "bt -no-filters" I get the same FAIL and
corresponding output.
So there are two scenarios here.
In the first:
- the bt command is called
- frame #0 is printed
- trying to get the next frame fails and an error is thrown, aborting the
backtrace
- the error is caught and printed
In the second:
- the bt command is called
- the frame filter is applied
- doing so triggers the same error, which is caught and printed by
gdbpy_apply_frame_filter, returning EXT_LANG_BT_NO_FILTERS
- frame #0 is printed
- getting the next frame fails, and the backtrace stops
It seems worthwhile to exercise both scenarios if possible, so add a
"bt -no-filters" test.
Fix the FAIL by updating the regexp to allow both scenarios.
Tested on aarch64-linux.
Reviewed-By: Keith Seitz <keiths@redhat.com>
With a gdb build without python support and test-case
gdb.multi/pending-bp.exp, I run into:
...
(gdb) python bp=[b for b in gdb.breakpoints() if b.number == 5][0]^M
Python scripting is not supported in this copy of GDB.^M
(gdb) FAIL: $exp: py_test_toggle_thread: find Python gdb.Breakpoint object
...
Fix this by requiring python support for part of the test-case.
Tested on aarch64-linux.
Reviewed-By: Keith Seitz <keiths@redhat.com>
With a gdb build without xml support and test-case gdb.base/break-dbg.exp, I
run into:
...
(gdb) catch syscall^M
warning: Can not parse XML syscalls information; \
XML support was disabled at compile time.^M
Catchpoint 11 (any syscall)^M
(gdb) FAIL: $exp: catch syscall
...
Fix this by updating the regexp.
Tested on aarch64-linux.
Reviewed-By: Keith Seitz <keiths@redhat.com>
For some reason the initial implementation (commit 0672748ac0) of
this macro didn't allow discarding of all relocs in a section, perhaps
because doing so would require a testsuite change. This patch allows
zero size relocation sections to result, and adjusts the testsuite.
i386, x86_64, ppc and ppc64 code that avoids a memmove is also changed
to allow zero size reloc sections, and arc fixed to actually adjust
the reloc section header.
On x86_64-freebsd, with test-case gdb.arch/amd64-disp-step-self-call.exp, I
run into:
...
(gdb) continue
Continuing.
Program received signal SIGBUS, Bus error.
Object-specific hardware error.
0x000000080051492c in alarm () from /lib/libc.so.7
(gdb) FAIL: $exp: continue to breakpoint: test_call
...
The behaviour is not specific to gdb, it can be reproduced by running the
test-case executable:
...
$ ./outputs/gdb.arch/amd64-disp-step-self-call/amd64-disp-step-self-call
Bus error (core dumped)
$
...
The bus error happens when executing this instruction in alarm:
...
0000000000093910 <alarm>:
...
9392c: 0f 29 45 d0 movaps %xmm0, -0x30(%rbp)
...
because $rbp is not 16-byte aligned.
This can be fixed by adding the missing frame setup instructions at the start
of main in amd64-disp-step-self-call.S:
...
main:
+ pushq %rbp
+ movq %rsp, %rbp
...
Instead, fix this by moving main from the assembly file to the c file, which
has the same effect.
Also remove the done label, which looks like a copy-past left-over. Instead,
add an unreachable function and use it where appropriate.
Do the same for i386 case (which makes the source files identical for the
amd64 and i386 case, but I decided to leave it like that).
Tested on x86_64-freebsd and x86_64-linux.
Emit a line in the gdb.log file each time a new gdb.in.NUM command log
is started. The gdb.log line includes the full filename for the new
gdb.in.NUM file.
This change will make it trivial to go from a FAIL in the gdb.log file
to the gdb.in.NUM file that (should) reproduce the failure. When I
encounter a failing test one of my first steps is usually to identify
the gdb.in.NUM file and try re-running it to see if that reproduces
the failure. Some tests create many very similar gdb.in.NUM files, so
finding the exact one can sometimes be difficult. With this patch
that task is now trivial.
There should be no change in what is tested after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Since PR ld/25617 tests expects glibc specific features, limit PR ld/25617
tests to glibc targets.
PR ld/33169
* testsuite/ld-elf/no-section-header.exp: Return if not glibc
targets.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
.bundle_align_mode 32
nop
read.c:776:26: runtime error: shift exponent 32 is too large for
32-bit type 'unsigned int'
Avoid this by using wider types in the expressions.
The initial visium support added in commit d924db559b didn't make
use of RELOC_AGAINST_DISCARDED_SECTION, and so lacked code to remove
relocations in debug sections.
In some test-cases, matching the pagination prompt is split up to address a
matching race but that's no longer necessary, thanks to commit c3f814a143
("Fix paginate-*.exp races").
Fix this by using the pagination_prompt variable.
Tested on x86_64-linux.
Approved-By: Andrew Burgess <aburgess@redhat.com>
In test-case gdb.base/style.exp, we have proc test_pagination_prompt_styling,
which:
- determines a "desired width" by parsing the output of "info files",
- sets width to the "desired width", and
- runs "info files" again.
The "desired width" on my system is 88, but if I override it to 65, I run
into:
...
(gdb) info files^M
Symbols from "^[[32;49;22;27m/data/vries/gdb/leap-15-6/build/gdb/testsuite/outputs/gdb.base/style/style^[[m".^M
--Type <RET> for more, q to quit, c to continue without paging--^M
^MFAIL: gdb.base/style.exp: check pagination prompt styling (timeout)
...
with make target check, and with check-read1 into:
...
(gdb) info files^M
Symbols from "^[[32;49;22;27m/data/vries/gdb/leap-15-6/build/gdb/testsuite/outputs/gdb.base/style/style^[[m".^M
--Type <RET> for more, q to quit, c to continue without paging--^M
^M^[[A^M
Native process:^M
Using the running image of child process 6179.^M
--Type <RET> for more, q to quit, c to continue without paging--ERROR: Window too small.
UNRESOLVED: gdb.base/style.exp: check pagination prompt styling
...
This is caused by the following.
The size of the pagination prompt is 64:
...
1 2 3 4 5 6
1234567890123456789012345678901234567890123456789012345678901234
--Type <RET> for more, q to quit, c to continue without paging--
...
and because we have TERM=ansi and width == 65, readline wraps at 64:
...
(gdb) maint info screen
Number of characters gdb thinks are in a line is 65.
Number of characters readline reports are in a line is 64.
...
In other words, readline wraps when printing the pagination prompt.
This causes some unusual output, and the test is not prepared to handle this.
Fix this by requiring that desired_width is at least
<length of pagination prompt> + 2.
Tested on x86_64-linux.
Approved-By: Andrew Burgess <aburgess@redhat.com>
PR testsuite/33167
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33167
