| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.compile.
Tested on x86_64-linux, fedora rawhide.
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.cp.
Tested on x86_64-linux.
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.debuginfod.
Tested on x86_64-linux.
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.disasm.
The changed test-cases:
- gdb.disasm/am33.exp
- gdb.disasm/hppa.exp
- gdb.disasm/mn10300.exp
- gdb.disasm/sh3.exp
are unsupported for me, but the changes are trivial.
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.dwarf2.
Tested on x86_64-linux using gcc-14.
Tested these test-cases on x86_64-linux with target board unix/-m32:
- gdb.dwarf2/valop.exp
- gdb.dwarf2/callframecfa.exp
- gdb.dwarf2/implptr.exp
- gdb.dwarf2/watch-notconst.exp
- gdb.dwarf2/pieces.exp
- gdb.dwarf2/pieces-optimized-out.exp
Tested these test-cases on x86_64-linux with target board fission-dwp:
- gdb.dwarf2/dwp-symlink.exp
- gdb.dwarf2/dwp-sepdebug.exp
Tested test-case gdb.dwarf2/gdb-index-tilde.exp on x86_64-linux by disabling a
too strict home directory check, see PR testsuite/33364.
|
|
1. Update dump_relr_relocations not to change the symbol table.
2. Update count_relr_relocations and dump_relr_relocations not to
retrieve the same data twice.
binutils/
PR binutils/33328
* readelf.c (count_relr_relocations): Add an argument to return
the retrieved data and remove the FIXME in comments.
(dump_relr_relocations): Add an argument for the retrieved data.
Retrieve the data if needed. Don't change the symbol table and
remove the FIXME in comments.
(display_relocations): Get the data from count_relr_relocations
and pass it to dump_relr_relocations call.
(process_relocs): Pass NULL to dump_relr_relocations.
ld/
PR binutils/33328
* testsuite/ld-i386/dt-relr-2.d: New file.
* testsuite/ld-i386/dt-relr-2.s: Likewise.
* testsuite/ld-x86-64/dt-relr-2-x32.d: Likewise.
* testsuite/ld-x86-64/dt-relr-2.d: Likewise.
* testsuite/ld-x86-64/dt-relr-2.s: Likewise.
* testsuite/ld-i386/i386.exp: Run dt-relr-2.
* testsuite/ld-x86-64/x86-64.exp: Run dt-relr-2 and dt-relr-2-x32.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.fortran.
Tested on x86_64-linux, with gcc 14.
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.gdb.
Tested on x86_64-linux.
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.guile.
Tested on x86_64-linux.
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.linespec.
Tested on x86_64-linux.
|
|
Fix mi_clean_restart <absolute filename> in the test-cases in gdb.mi.
Tested on x86_64-linux.
Also tested test-case gdb.mi/mi-dprintf.exp with target boards
native-gdbserver and native-extended-gdbserver.
Since test-case gdb.mi/mi-regs.exp requires istarget "sparc-*-*", I didn't
test the trivial change in that test-case.
|
|
Fix mi_clean_restart <absolute filename> in the test-cases in gdb.trace.
Tested on x86_64-linux, with target boards unix, native-gdbserver and
native-extended-gdbserver.
|
|
We can't put a breakpoint in the middle of a ll/sc atomic sequence,
so look for the end of the sequence and put the breakpoint there,
it has been handled in the commit 208b57e53ed9 ("gdb: LoongArch:
Deal with atomic sequence").
Especially, maybe there is a conditional branch instruction in the
middle of a ll/sc atomic sequence, its destination address may be
current pc + 4 which is inside the atomic sequence, it should not
put a breakpoint in its destination address in this case, this has
been handled in the commit a4242dc3f5fa ("gdb: LoongArch: Improve
the handling of atomic sequence").
Additionally, if there is a conditional branch instruction in the
middle of a ll/sc atomic sequence, its destination address may be
not current pc + 4 but still inside the atomic sequence, it should
not put a breakpoint in its destination address in this case.
So in order to avoid putting a breakpoint in the middle of a ll/sc
atomic sequence in any case, just look for the start and end of the
sequence, and restrict the breakpoint outside of the atomic sequence.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
In the current loongarch_deal_with_atomic_sequence(), it is just a loop
through a ll/sc atomic instruction sequence, the instructions before the
condition branch are not actually executed, thus the condition register
value is not proper to determine the destination address.
Add a new function cond_branch_destination_address() to calculate the
destination address of a condition branch instruction under an assumed
true condition, then only put a breakpoint at this address when it is
outside of the ll/sc atomic instruction sequence.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.multi.
Tested on x86_64-linux.
|
|
Lazy IBT PLT entries look like
static const bfd_byte elf_i386_lazy_ibt_plt_entry[LAZY_PLT_ENTRY_SIZE] =
{
0xf3, 0x0f, 0x1e, 0xfb, /* endbr32 */
0x68, 0, 0, 0, 0, /* pushl immediate */
0xe9, 0, 0, 0, 0, /* jmp relative */
0x66, 0x90 /* xchg %ax,%ax */
};
static const bfd_byte elf_x86_64_lazy_ibt_plt_entry[LAZY_PLT_ENTRY_SIZE] =
{
0xf3, 0x0f, 0x1e, 0xfa, /* endbr64 */
0x68, 0, 0, 0, 0, /* pushq immediate */
0xe9, 0, 0, 0, 0, /* jmpq relative */
0x66, 0x90 /* xchg %ax,%ax */
};
They only have
unsigned int plt_reloc_offset; /* ... offset into relocation table. */
and don't have
unsigned int plt_got_offset; /* ... address of this symbol in .got. */
We should use plt_reloc_offset, not plt_got_offset, to check IBT PLT.
PR binutils/33358
* elf32-i386.c (elf_i386_get_synthetic_symtab): Check
plt_reloc_offset for lazy IBT PLT.
* elf64-x86-64.c (elf_x86_64_get_synthetic_symtab): Likewise.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
|
|
Update "readelf --got-contents" to skip on non-ET_DYN/ET_EXEC files.
* readelf.c (process_got_section_contents): Skip if not
ET_DYN/ET_EXEC files.
* testsuite/binutils-all/readelf-got.d: Removed.
* testsuite/binutils-all/readelf.exp: Don't run readelf-got.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.objc.
Tested on x86_64-linux, using 'lappend options "nowarnings"' in
gdb_compile_shlib_pthreads. See also PR testsuite/24807.
|
|
Don't call qsort if all_relocations_count < 1.
PR binutils/33351
* readelf.c (process_got_section_contents): Call qsort only if
all_relocations_count > 1.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
|
|
In test-case gdb.opencl/callfuncs.exp I noticed:
...
clean_restart [standard_testfile $testfile]
...
This doesn't have the desired effect of starting gdb with $testfile because
standard_testfile doesn't return anything.
Fix this by using "clean_restart $testfile".
While we're at it:
- move standard_testfile to the start of the file
- drop the redundant 'set testfile "callfuncs"'
- use standard_testfile .cl to properly define $srcfile
- use $srcfile instead of $testfile.cl
Tested on x86_64-linux, using the demonstrator patch in PR testsuite/33363.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33363
|
|
The test gdb.base/gcore-memory-usage is meant to show that the memory
requirements of GDB's gcore command don't grow with the memory usage
of the inferior. It was using hardcoded values for memory, but the
values were too small when building GDB with address sanitizer. This
commit fixes one of the failures by increasing the limit on the first
gcore call.
But, rather than just increasing the hardcoded limit for the second
call, we instead save the amount of memory used in the first call and
ensure that the second call doesn't use more memory than the first.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33148
Approved-By: Tom de Vries <tdevries@suse.de>
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.opt.
Tested on x86_64-linux using gcc 14.
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.perf.
Tested on x86_64-linux using check-perf.
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.python.
Tested on x86_64-linux.
|
|
Fuzzers stress the assembler in ways no sane programmer would ever do.
One x86 oss-fuzz testcase (cleaned up a litte) was:
.sect .debug_frame
call x
.long x,0
.space 1
.long 0,0
The call insn leaves the frag data corresponding to a CIE
uninitialised until later in assembly, leading to reports of
uninitialised data access in ehopt.c:check_eh_frame.
Hack around this problem by noticing an insn has been assembled in
dwarf2_emit_insn. The existing frag has_code can't be used as that
leads to alignment complaints, so add a new segment_info flag.
* subsegs.h (struct segment_info_struct): Move bss and hadone
later. Rename hadone to stab_seen. Add insn_seen bitfield.
* dwarf2dbg.c (dwarf2_emit_insn): Set insn_seen.
* ehopt.c (check_eh_frame): Disable optimisation if insn_seen.
* stabs.c (s_stab_generic): Adjust for hadone rename.
|
|
Avoid the alignment hackery necessary when obstack_alloc is used.
obstack_alloc expands to obstack_blank plus obstack_finish, and the
latter call is where alignment of the tail of the obstack happens.
The docs say obstack_alloc "is invoked almost like malloc", which
implies a fixed size allocation and you don't need other obstack calls
in its use. So I think trying to use obstack_alloc in frag_alloc was
always a poor choice.
* frags.c (frag_alloc): Replace obstack_alloc with obstack_blank.
|
|
"the weird alignment hackery" comment doesn't help anyone understand
the code. Explain what is going on. Replace the zero length
obstack_alloc with obstack_finish, which by inspection of obstack.h is
all the zero length alloc does.
* frags.c (frag_alloc): Comment. Replace zero length
obstack_alloc with obstack_finish.
(frag_new): Remove unnecessary obstack_finish.
* write.c (compress_frag, compress_debug): Likewise.
|
|
For better packing of struct frag.
* frags.h (struct frag <fr_type>): Use ENUM_BITFIELD.
|
|
These weren't wrong, but should use the BUNDLE_SIZE macros, in case
they ever change.
* config/tc-tilegx.h (MAX_MEM_FOR_RS_ALIGN_CODE): Use
TILEGX_BUNDLE_SIZE_IN_BYTES.
* config/tc-tilepro.h (MAX_MEM_FOR_RS_ALIGN_CODE): Use
TILEPRO_BUNDLE_SIZE_IN_BYTES.
|
|
Commit 7ca6020a4e52 "tidy target HANDLE_ALIGN" didn't account for
the "fix" amount emitted by visium_handle_align. This didn't show up
as a problem due to frag alignment hiding the error, until I started
messing with struct frag.
* config/tc-visium.h (MAX_MEM_FOR_RS_ALIGN_CODE): Correct.
|
|
* csky-dis.c (parse_csky_dis_options): Free copy of options.
|
|
|
|
opcodes/
* ppc-opc.c: (VXSEL5, VXSEL4, VXSEL3, VXSEL2, UIMM1): New defines.
(powerpc_opcodes): <vucmprhn, vucmprln, vucmprhb, vucmprlb,
vucmprhh, vucmprlh, vupkhsntob, vupklsntob, vupkint4tobf16,
vupkint8tobf16, vupkint4tofp32, vupkint8tofp32>: New instructions.
gas/
* gas/testsuite/gas/ppc/future.s: Add new testcases.
* gas/testsuite/gas/ppc/future.d: Likewise.
|
|
Since commit 3cb6bc13e328 ("gdb/progspace: add solib_ops pointer in
program_space"), and with the previous patch applied ("gdb/remote: use
scoped_restore_current_program_space in remote_unpush_target"), we get
this failure:
$ make check TESTS="gdb.server/extended-remote-restart.exp" RUNTESTFLAGS="--target_board=native-extended-gdbserver"
In gdb.log:
(gdb) PASS: gdb.server/extended-remote-restart.exp: kill: 0, follow-child 1: disconnect
target extended-remote localhost:2348
Remote debugging using localhost:2348
/home/smarchi/src/binutils-gdb/gdb/progspace.h:240: internal-error: set_solib_ops: Assertion `m_solib_ops == nullptr' failed.
When connecting to a remote that has one or more inferior already
running, the remote target (the GDB-side code) tries to re-use existing
GDB inferiors that are unused. The problem is that the program space of
the inferior that gets re-used unexpectedly has its solib_ops set.
I think that the problem is that when connecting to a remote target that
has multiple inferiors, target_pre_inferior only gets called for the
currently selected (client-side) inferior. It happens here:
#0 target_pre_inferior () at /home/smarchi/src/wt/amd/gdb/target.c:2454
#1 0x0000559c832a350a in target_preopen (from_tty=1) at /home/smarchi/src/wt/amd/gdb/target.c:2510
#2 0x0000559c82e1b8f1 in remote_target::open_1 (name=0x50200006eb58 ":2345", from_tty=1, extended_p=1) at /home/smarchi/src/wt/amd/gdb/remote.c:6171
#3 0x0000559c82e18a5d in extended_remote_target::open (name=0x50200006eb58 ":2345", from_tty=1) at /home/smarchi/src/wt/amd/gdb/remote.c:5446
#4 0x0000559c8329a43e in open_target (args=0x50200006eb58 ":2345", from_tty=1, command=0x512000072c40) at /home/smarchi/src/wt/amd/gdb/target.c:839
I think that target_pre_inferior should be called for the other
inferiors that gain execution as a result of connecting to the remote
target, to make sure inferior or program space-specific data from
previous executions gets cleared. target_pre_inferior is what clears
any previous solib_ops.
It is possible to observe the problem by adding this print in
target_pre_inferior:
printf (">>> target_pre_inferior called for inferior %d\n",
current_inferior ()->num);
Then, starting a gdbserver:
$ gdbserver --multi localhost:2345
Then, this gdb command that starts two remote inferiors, disconnects
(leaving gdbserver and the inferiors running), then reconnects:
$ ./gdb -nx --data-directory=data-directory -q \
-ex 'set sysroot /' \
-ex 'target extended-remote :2345' \
-ex 'file testsuite/outputs/gdb.server/extended-remote-restart/extended-remote-restart' \
-ex 'set remote exec-file testsuite/outputs/gdb.server/extended-remote-restart/extended-remote-restart' \
-ex 'b main' \
-ex r \
-ex 'add-inferior' \
-ex 'inferior 2' \
-ex 'file testsuite/outputs/gdb.server/extended-remote-restart/extended-remote-restart' \
-ex 'run' \
-ex 'inferior 1' \
-ex 'disconnect' \
-ex 'echo About to reconnect\n' \
-ex 'target extended-remote :2345'
>>> target_pre_inferior called for inferior 1
Remote debugging using :2345
Reading symbols from /home/smarchi/build/wt/amd/gdb/testsuite/outputs/gdb.server/extended-remote-restart/extended-remote-restart...
Breakpoint 1 at 0x11fc: file /home/smarchi/src/wt/amd/gdb/testsuite/gdb.server/extended-remote-restart.c, line 50.
>>> target_pre_inferior called for inferior 1
Starting program: /home/smarchi/build/wt/amd/gdb/testsuite/outputs/gdb.server/extended-remote-restart/extended-remote-restart
Breakpoint 1, main () at /home/smarchi/src/wt/amd/gdb/testsuite/gdb.server/extended-remote-restart.c:50
50 pid = fork ();
[New inferior 2]
Added inferior 2 on connection 1 (extended-remote :2345)
[Switching to inferior 2 [<null>] (<noexec>)]
Reading symbols from /home/smarchi/build/wt/amd/gdb/testsuite/outputs/gdb.server/extended-remote-restart/extended-remote-restart...
>>> target_pre_inferior called for inferior 2
Starting program: /home/smarchi/build/wt/amd/gdb/testsuite/outputs/gdb.server/extended-remote-restart/extended-remote-restart
Thread 2.1 "extended-remote" hit Breakpoint 1.2, main () at /home/smarchi/src/wt/amd/gdb/testsuite/gdb.server/extended-remote-restart.c:50
50 pid = fork ();
[Switching to inferior 1 [process 2591936] (/home/smarchi/build/wt/amd/gdb/testsuite/outputs/gdb.server/extended-remote-restart/extended-remote-restart)]
[Switching to thread 1.1 (Thread 2591936.2591936)]
#0 main () at /home/smarchi/src/wt/amd/gdb/testsuite/gdb.server/extended-remote-restart.c:50
50 pid = fork ();
Ending remote debugging.
About to reconnect
>>> target_pre_inferior called for inferior 1
Remote debugging using :2345
main () at /home/smarchi/src/wt/amd/gdb/testsuite/gdb.server/extended-remote-restart.c:50
50 pid = fork ();
We can see that target_pre_inferior is only called for inferior 1 when
reconnecting (after the "About to reconnect" message).
After adding the call to target_pre_inferior in remote_add_inferior, we
get (just the last bit):
About to reconnect
>>> target_pre_inferior called for inferior 1
Remote debugging using :2345
>>> target_pre_inferior called for inferior 1
>>> target_pre_inferior called for inferior 2
Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...
(No debugging symbols found in /lib/x86_64-linux-gnu/libc.so.6)
Reading symbols from /lib64/ld-linux-x86-64.so.2...
(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
main () at /home/smarchi/src/wt/amd/gdb/testsuite/gdb.server/extended-remote-restart.c:50
50 pid = fork ();
The duplicate calls to target_pre_inferior for inferior 1 are due to the
existing call in target_preopen. It might be possible to get rid of it:
with the call I added in remote_target::remote_add_inferior, I presume
it's now unnecessary for the remote target to have the call in
target_preopen as well. But since target_preopen is used by other
targets, I prefer to leave it there to be safe, for the moment. Calling
target_pre_inferior multiple times should not be a problem, as it should
be idempotent.
However, once I added that, test gdb.server/stop-reply-no-thread.exp
started failing, with this in the logs:
target remote localhost:2347
Remote debugging using localhost:2347
Remote 'g' packet reply is too long (expected 560 bytes, got 820 bytes): 000000... <truncated>
It became apparent that the new call to target_pre_inferior would wipe a
previously fetched target description. I fixed that by adding calls to
target_find_description in two callers of remote_add_inferior. I'm not
100% sure of what I'm doing here, but it seems somewhat correct that
when we map a remote inferior to an existing client-side inferior, we
wipe out any previous target description (which would have been left by
a previous execution) and fetch a new one.
The other call to remote_add_inferior is in
extended_remote_target::attach, where there is already a call to
target_find_description shortly after.
Change-Id: I85426bfff286a67d5fb74bbf978df80060ee6deb
|
|
Since commit 3cb6bc13e328 ("gdb/progspace: add solib_ops pointer in
program_space"), this fails with an internal error:
$ make check TESTS="gdb.server/extended-remote-restart.exp" RUNTESTFLAGS="--target_board=native-extended-gdbserver"
In gdb.log:
(gdb) PASS: gdb.server/extended-remote-restart.exp: kill: 1, follow-child 0: disconnect
target extended-remote localhost:2347
Remote debugging using localhost:2347
/home/smarchi/src/binutils-gdb/gdb/progspace.h:240: internal-error: set_solib_ops: Assertion `m_solib_ops == nullptr' failed.
The issue is that remote_unpush_target uses
scoped_restore_current_inferior to save the context, which only restores
the current inferior on exit. But it then uses
switch_to_inferior_no_thread, which switches the inferior and the
program space. The program space is therefore left unrestored. This
can leave the current inferior and current program space out of sync.
With two inferiors, let's say we enter with current inferior == 1 and
current program space == 1. When calling switch_to_inferior_no_thread
for inferior 2, we set the current inferior to 2 and current program
space to 2. On exit, only the original inferior is restored, so we end
up with current inferior == 1 and current program space == 2.
The problem can be observed manually by starting two remote inferiors
and disconnecting while inferior 1 is selected:
$ ./gdb -nx --data-directory=data-directory -q \
-ex 'set sysroot /' \
-ex 'target extended-remote | gdbserver --multi --once -' \
-ex 'file /home/smarchi/build/wt/amd/gdb/testsuite/outputs/gdb.server/extended-remote-restart/extended-remote-restart' \
-ex 'set remote exec-file /home/smarchi/build/wt/amd/gdb/testsuite/outputs/gdb.server/extended-remote-restart/extended-remote-restart' \
-ex 'b main' \
-ex r \
-ex 'add-inferior' \
-ex 'inferior 2' \
-ex 'file /home/smarchi/build/wt/amd/gdb/testsuite/outputs/gdb.server/extended-remote-restart/extended-remote-restart' \
-ex 'run' \
-ex 'inferior 1' \
-ex 'disconnect'
Then, connecting top-gdb to that gdb, we see the inconsistency:
(top-gdb) p current_inferior_.m_obj.num
$1 = 1
(top-gdb) p current_program_space.num
$2 = 2
When the test tries to connect to a remote target again, GDB maps the
remote inferior to inferior 1, but tries to set the solib_ops of program
space 2, which already has an solib_ops set, causing the internal error.
Fix this by using scoped_restore_current_program_space in addition to
scoped_restore_current_inferior. With this patch applied, we get:
(top-gdb) p current_inferior_.m_obj.num
$1 = 1
(top-gdb) p current_program_space.num
$2 = 1
With this patch, we then hit another internal error, fixed by the
following patch.
Change-Id: If916f581a223d6611f7f23a9cbbf1825d2cdd0ba
Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
|
|
Fix clean_restart <absolute filename> in the test-case in gdb.replay.
Tested on x86_64-linux, with target boards unix, native-gdbserver and
native-extended-gdbserver.
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.reverse.
Tested on:
- x86_64-linux, target boards unix and unix/-m32
- aarch64-linux
- ppc64le-linux
- s390x-linux
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.rocm.
Since these test-cases are unsupported for me, do the simple substitution:
...
clean_restart $binfile
->
clean_restart
gdb_load $binfile
...
|
|
Update "readelf --got-contents" to report if no GOT section found.
* readelf.c (process_got_section_contents): Report if no GOT
section found.
* testsuite/binutils-all/readelf-got.d: New file.
* testsuite/binutils-all/readelf.exp: Run readelf-got.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.server.
Tested on x86_64-linux.
|
|
PR gas/15273
The apparent intent of the original code added in
https://sourceware.org/pipermail/binutils/2012-August/078044.html was
to emit an error message if the instruction was obsolete and only to
emit a deprecation warning if an error hadn't already been emitted.
However, when the insn has not yet been obsoleted, the code would
generate a warning with a (null) message body if the selected CPU was
'any'.
The previous fix for this bug was to remove the support for the
obsoletion message entirely, which was probably the wrong approach. A
better fix is to only call check_obsolete if obs_msg is non-null; we
can use this as a proxy for the instruction not being obsolete on any
architecture.
While we are here, fix an incorrect capitalization in the deprecation
message ('This' to 'this').
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.testsuite.
Tested on x86_64-linux.
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.threads.
Tested on x86_64-linux.
|
|
Tom de Vries ran the testsuite on msys2-ucrt64 with mount point map:
...
/bin C:/msys64/usr/bin
/c C:
/ C:/msys64
...
and ran into the problem that host_file_normalize didn't translate:
...
/home/user/gdb/build/gdb/testsuite/temp/n/x
...
into:
...
C:/msys64/home/user/gdb/build/gdb/testsuite/temp/n/x
...
The problem is that host_file_normalize_mingw mishandles a
file/directory under the root mount point. A simpler reproducer is
"/foo". If we add that as a test to
gdb.testsuite/mount-point-map.exp, we see:
input: /foo
expected: C:/msys64/foo/
got: /foo
FAIL: gdb.testsuite/mount-point-map.exp: /foo
For a mount point that ends in /, this line in
host_file_normalize_mingw:
} elseif {[string index $filename $mount_len] eq "/"} {
... is always false, because the character at $mount_len is the one
_after_ the slash.
Notice that the "/" mount point is the only one that ends in "/".
This is even if you try to create one explicitly with a trailing /.
On MSYS2:
$ mount c:/foo /foo/
mount: warning - /foo/ does not exist.
$ mount
C:/foo on /foo type ntfs (binary,user)
...
So fix this by special casing the "/" mount point.
And then... while playing with fixing this, I noticed I had done
something strange with this case:
if {[string length $filename] == $mount_len} {
return "$win_filename/"
The intent was to append the slash when the mount is a drive letter,
like 'cygpath -ma' does:
$ cygpath -ma /c
C:/
Other cases do not get a trailing slash:
$ cygpath -ma /c/foo
C:/foo
I think this is because on Windows, every drive letter has a current
directory, and really "C:" means "current directory of drive letter
C:", not "root of C:". Resolving it to "C:/" makes it unambiguous.
However, I mishandled that in a63213cd374d ('MSYS2+MinGW testing: Unix
<-> Windows path conversion'). The original version of that patch
when I posted it to the mailing list only supported drive mounts,
which turned out incorrect, and then I generalized it to work with all
mount points before it was merged. In the process, I inadvertently
made the code append the slash whenever the input filename matches a
mount exactly, any mount.
I also now noticed that TCL's "file normalize" on Linux always removes
the trailing slash, and since host_file_normalize is an abstraction
for it, I think host_file_normalize_mingw should do the same.
Likewise for duplicate slashes, "file normalize" gets rid of them.
Fix all this in host_file_normalize_mingw, and add corresponding tests
to gdb.testsuite/mount-point-map.exp.
I smoke tested this here with a few of the testcases that required
tweaking in the patch that added host_file_normalize, like
gdb.base/source-dir.exp and gdb.base/fullname.exp and they still pass.
Tom ran gdb.testsuite/mount-point-map.exp on both x86_64-linux and
msys2-ucrt64, and it passed in both cases.
Change-Id: I852a8662f0cb8b0ee4e683e9b157618cf6955477
|
|
Proc host_file_normalize is structured like this:
...
proc host_file_normalize {filename} {
if {[ishost *-*-mingw*]} {
...
}
return [file normalize $filename]
...
so a testcase exercising the mingw specific part can only be run on a
mingw host.
Factor out a new proc host_file_normalize_mingw, which can be used on
any host platform.
Add testcase gdb.testsuite/mount-point-map.exp, exercising
host_file_normalize_mingw.
Tested on aarch64-linux, x86-64-linux, msys2-ucrt64, and msys2-mingw.
Co-Authored-By: Pedro Alves <pedro@palves.net>
Change-Id: Ia130de5c12c940852b6367c422d04896863bfc02
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.trace.
Tested on x86_64-linux, with target boards unix, native-gdbserver and
native-extended-gdbserver.
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.tui.
Tested on x86_64-linux.
|
|
The tests mentioned in PR33348 needs different care.
For FRED tests, we could simply remove them since there are
no operands and the tests are the same as AT&T Syntax.
For MOVRS tests, we allowed suffixes for AT&T suffixes although
we could tell the difference according to register operand to
align with legacy mov. Thus, the suffixes tests are needed for
AT&T Syntax while not needed for Intel Syntax. Adjust them
accordingly.
gas/ChangeLog:
PR ld/33348
* testsuite/gas/i386/x86-64-movrs-suffix.d: Describe the
test with more precise.
* testsuite/gas/i386/x86-64-movrs-suffix.s: Remove Intel
Syntax part.
* testsuite/gas/i386/x86-64.exp: Add MOVRS suffix tests.
* testsuite/gas/i386/x86-64-fred-intel.d: Removed.
* testsuite/gas/i386/x86-64-movrs-suffix-intel.d: Ditto.
|
|
When parsing FDEs in `.eh_frame` using `objdump -Wf`, it is necessary to
resolve `BFD_RELOC_LARCH_32_PCREL` to determine the address ranges of
the FDEs. Set the `pcrel_offset` field of `BFD_RELOC_LARCH_32_PCREL` to
help `objdump` correctly compute the address ranges of the FDEs.
Apply the same modification to BFD_RELOC_LARCH_64_PCREL.
|
|
|
