| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Many test cases had a few lines in the beginning that look like:
if { condition } {
continue
}
Where conditions varied, but were mostly in the form of ![runto_main] or
[skip_*_tests], making it quite clear that this code block was supposed
to finish the test if it entered the code block. This generates TCL
errors, as most of these tests are not inside loops. All cases on which
this was an obvious mistake are changed in this patch.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
cooked_index::m_start is unused and can be removed. I think this was
a leftover from a previous approach in the index finalization code,
and then when rewriting it I forgot to remove it.
Tested by rebuilding.
|
| |
|
|
|
|
|
|
|
|
| |
I noticed that gdbserver did not implement pid_to_exec_file for
Windows, while gdb did implement it. This patch moves the code to
nat/windows-nat.c, so that it can be shared. This makes the gdbserver
implementation trivial.
|
| |
|
|
|
|
|
|
| |
I noticed that windows_process_info::id is only used by gdbserver, and
not really necessary. This patch removes it.
|
| |
|
|
|
|
|
|
|
|
|
| |
This changes target_pid_to_exec_file and target_ops::pid_to_exec_file
to return a "const char *". I couldn't build many of these targets,
but did examine the code by hand -- also, as this only affects the
return type, it's normally pretty safe. This brings gdb and gdbserver
a bit closer, and allows for the removal of a const_cast as well.
|
| |
|
|
|
|
|
|
| |
I noticed that corefile-run.core ends up in the 'runtest' directory.
It's better, when at all possible, for test files to end up in the
test's designated subdirectory. This patch makes this change.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This changes coffread.c to avoid re-reading minimal symbols when
possible. This only works when there are no COFF symbols to be read,
but at least for my mingw builds of gdb, this seems to be the case.
Tested using the AdaCore internal test suite on Windows. I also did
some local builds to ensure that no warnings crept in.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If you load a core file into GDB with the --write option, or "set
write on" (equivalent), and then poke memory expecting it to patch the
core binary, you'll notice something odd -- the write seems to
succeed, but in reality, it doesn't. The value you wrote doesn't
persist. Like so:
$ gdb -q --write -c testsuite/outputs/gdb.base/patch/gcore.test
[New LWP 615986]
Core was generated by `/home/pedro/gdb/build/gdb/testsuite/outputs/gdb.base/patch/patch'.
Program terminated with signal SIGTRAP, Trace/breakpoint trap.
#0 0x0000555555555131 in ?? ()
(gdb) p *(unsigned char *)0x0000555555555131 = 1
$1 = 1 '\001'
(gdb) p *(unsigned char *)0x0000555555555131
$2 = 185 '\271'
(gdb)
Diffing hexdumps of before/after patching, reveals that a "0x1" was
actually written somewhere in the file. The problem is that the "0x1"
was written at the wrong offset in the file...
That happens because _bfd_elf_set_section_contents does this to seek
to the section's offset:
pos = hdr->sh_offset + offset;
if (bfd_seek (abfd, pos, SEEK_SET) != 0
|| bfd_bwrite (location, count, abfd) != count)
return false;
... and 'hdr->sh_offset' is zero, so we seek to just OFFSET, which is
incorrect. The reason 'hdr->sh_offset' is zero is that
kernel-generated core files normally don't even have a section header
table (gdb-generated ones do, but that's more an accident than a
feature), and indeed elf_core_file_p doesn't even try to read sections
at all:
/* Core files are simply standard ELF formatted files that partition
the file using the execution view of the file (program header table)
rather than the linking view. In fact, there is no section header
table in a core file.
The process status information (including the contents of the general
register set) and the floating point register set are stored in a
segment of type PT_NOTE. We handcraft a couple of extra bfd sections
that allow standard bfd access to the general registers (.reg) and the
floating point registers (.reg2). */
bfd_cleanup
elf_core_file_p (bfd *abfd)
Changing _bfd_elf_set_section_contents from:
pos = hdr->sh_offset + offset;
to:
pos = section->filepos + offset;
fixes it. If we do that however, the tail end of
_bfd_elf_set_section_contents ends up as a copy of
_bfd_generic_set_section_contents, so just call the latter, thus
eliminating some duplicate code.
New GDB testcase included, which exercises both patching an executable
and patching a core file. Patching an executable already works
without this fix, because in that case BFD reads in the sections
table. Still, we had no testcase for that yet. In fact, we have no
"set write on" testcases at all, this is the first one.
Tested on x86-64 GNU/Linux, gdb, ld, binutils, and gas.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18227
Change-Id: I0f49f58b48aabab2e269f2959b8fd8a7fe36fdce
|
| | |
|
| |
|
|
|
|
|
| |
PTR will soon disappear from ansidecl.h. Remove uses in sim. Where
a PTR cast is used in assignment or function args to a void* I've
simply removed the unnecessary (in C) cast rather than replacing with
(void *).
|
| | |
|
| |
|
|
|
| |
PTR will disappear from ansidecl.h and libiberty on the next import
from gcc. Remove current uses in gdb.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When running test-case gdb.cp/break-f-std-string.exp on openSUSE Leap 15.3
with system gcc 7.5.0, I run into:
...
(gdb) whatis /r std::string^M
No symbol "string" in namespace "std".^M
(gdb) FAIL: gdb.cp/break-f-std-string.exp: _GLIBCXX_USE_CXX11_ABI=1: \
whatis /r std::string
...
The same for gcc 8.2.1, but it passes with gcc 9.3.1.
At source level (as we can observe in the .ii file with -save-temps) we have
indeed:
...
namespace std {
namespace __cxx11 {
typedef basic_string<char> string;
}
}
...
while with gcc 9.3.1, we have instead:
...
namespace std {
namespace __cxx11 {
...
}
typedef basic_string<char> string;
}
...
due to gcc commit 33b43b0d8cd ("Define std::string and related typedefs
outside __cxx11 namespace").
Fix this by adding the missing typedef for gcc version 5 (the first version to
have the dual abi) to 8 (the last version missing aforementioned gcc commit).
Tested on x86_64-linux, with:
- system gcc 7.5.0
- gcc 4.8.5, 8.2.1, 9.3.1, 10.3.0, 11.2.1
- clang 8.0.1, 12.0.1
|
| |
|
|
|
|
|
|
|
|
|
| |
PR 29006
* pe-dll.c (dll_name): Delete, replacing with..
(dll_filename): ..this, moved earlier in file.
(generate_edata): Delete parameters. Don't set up dll_name here..
(pe_process_import_defs): ..instead set up dll_filename and
dll_symname here before returning.
(dll_symname_len): Delete write-only variable.
(pe_dll_generate_implib): Don't set up dll_symname here.
|
| |
|
|
|
|
|
|
|
|
|
| |
Just like on s390x with g++ 11.2.1, ppc64le with g++ 11.3.1 produces a
spurious warning for stringop-overread in debuginfod_is_enabled
for url_view. Also suppress it on powerpc64.
gdb/ChangeLog:
* debuginfod-support.c (debuginfod_is_enabled): Use
DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD on powerpc64.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are assumptions in the test about the long double format
being used. While the results are OK for i387 128-bit long doubles, it
is not correct for IEEE quad 128-bit long doubles.
Also, depending on the target (64-bit/32-bit), long doubles may not
be available at all. And it may be the case that the compiler for a 64-bit
target doesn't support 128-bit long doubles, but GDB might still support it
internally.
Lastly, not every long double format has invalid values. Some formats
consider all values as valid floating point numbers.
These divergences cause the following FAIL's on aarch64/arm:
FAIL: gdb.ada/float-bits.exp: print val_long_double
FAIL: gdb.ada/float-bits.exp: print val_long_double after assignment
With the above in mind, extend the test a little so it behaves well on
different architectures and so it works with different long double
formats.
Main changes:
- Use long double values appropriate for the long double format.
- Test long double assignment to compiler-generated long
double variables.
- Test long double assignment to GDB internal variables.
Tested on x86_64 (16 PASS), i686 (16 PASS), aarch64 (12 PASS) and arm (9 PASS).
|
| |
|
|
|
|
|
|
| |
Fix two things in update-linux.sh:
- remove use of unnecessary tmp file
- inline gen-header.py into update-linux.sh
Tested on x86_64-linux.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On aarch64-linux, with test-case gdb.dwarf2/dw2-out-of-range-end-of-seq.exp I
run into:
...
(gdb) run ^M
Starting program: dw2-out-of-range-end-of-seq ^M
^M
Program received signal SIGILL, Illegal instruction.^M
main () at src/gdb/testsuite/gdb.dwarf2/main.c:1^M
1 /* This testcase is part of GDB, the GNU debugger.^M
(gdb) FAIL: gdb.dwarf2/dw2-out-of-range-end-of-seq.exp: runto: run to main
...
There are two problems here:
- the test-case contains a hardcoded "DW_LNS_advance_pc 1" which causes the
breakpoint pointing in the middle of an insn
- the FAIL triggers on aarch64-linux, but not on x86_64-linux, because the
test-case uses 'main_label' as the address of the first and only valid entry
in the line table, and:
- on aarch64-linux, there's no prologue, so main_label and main coincide,
while
- on x86_64-linux, there's a prologue, so main_label is different from main.
Fix these problems by:
- eliminating the use of "DW_LNS_advance_pc 1", and using
"DW_LNE_set_address $main_end" instead, and
- eliminating the use of main_label, using "DW_LNE_set_address $main_start"
instead.
Tested on both x86_64-linux and aarch64-linux.
|
| |
|
|
|
|
|
| |
As was done for hash_insn_array in commit d3d1cc7b13b4.
* cgen-dis.c (hash_insn_list): Increase size of buf. Assert
size is large enough.
|
| |
|
|
|
| |
PR 29142
* ar.c (main): Properly handle libdeps for zero file_count.
|
| |
|
|
|
|
|
|
|
|
|
| |
The new test failed on s390-linux due to bfd_sprintf_vma trimming
output to 32 bits for 32-bit targets. The test was faulty anyway,
expecting zero as the min end of the range is plainly wrong, but
that's what you get if you cast min to int.
* config/tc-s390.c (s390_insert_operand): Print range error using
PRId64.
* testsuite/gas/s390/zarch-z900-err.l: Correct expected output.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When doing a gdb build with --with-expat=no, I run into:
...
(gdb) PASS: gdb.base/catch-syscall.exp: determine pipe syscall: \
continue to breakpoint: before pipe call
catch syscall pipe^M
Unknown syscall name 'pipe'.^M
(gdb) PASS: gdb.base/catch-syscall.exp: determine pipe syscall: \
catch syscall pipe
catch syscall pipe2^M
Unknown syscall name 'pipe2'.^M
(gdb) PASS: gdb.base/catch-syscall.exp: determine pipe syscall: \
catch syscall pipe2
continue^M
Continuing.^M
[Detaching after vfork from child process 18538]^M
[Inferior 1 (process 18537) exited normally]^M
(gdb) FAIL: gdb.base/catch-syscall.exp: determine pipe syscall: continue
...
This is a regression since recent commit 5463a15c18b ("[gdb/testsuite] Handle
pipe2 syscall in gdb.base/catch-syscall.exp").
Fix this by using pipe/pipe2 syscall numbers instead.
Tested on x86_64-linux.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When doing a gdb build without --enable-targets, I run into:
...
(gdb) UNSUPPORTED: gdb.base/catch-syscall.exp: multiple targets: \
s390:31-bit vs s390:64-bit: set architecture s390:64-bit
delete breakpoints^M
(gdb) info breakpoints^M
No breakpoints or watchpoints.^M
(gdb) break -qualified main^M
No symbol table is loaded. Use the "file" command.^M
Make breakpoint pending on future shared library load? (y or [n]) n^M
(gdb) FAIL: gdb.base/catch-syscall.exp: gdb_breakpoint: set breakpoint at main
...
The problem is that due to recent commit e21d8399303 ("[gdb/testsuite] Remove
target limits in gdb.base/catch-syscall.exp") "clean_restart $binfile" no
longer is called at the end of test_catch_syscall_multi_arch.
Fix this by moving "clean_restart $binfile" back to
test_catch_syscall_multi_arch.
Tested on x86_64-linux.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On powerpc64le-linux, I ran into:
...
FAIL: gdb.base/maint.exp: maint print objfiles: symtabs
...
The problem is that:
- the "Cooked index in use" line occurs twice in the gdb output:
- once for exec maint, and
- once for "Object file system-supplied DSO".
- the matching of the second "Cooked index in use" also consumes
the "Symtabs:" string, and consequently the corresponding
clause does not trigger and $symtabs remains 0.
Fix this by limiting the output of the command to the exec.
Tested on x86_64-linux and powerpcle-linux.
|
| |
|
|
| |
Regenerate syscalls/{ppc64,ppc}-linux.xml on a system with 5.14 kernel.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In test-case gdb.base/catch-syscall.exp, proc test_catch_syscall_multi_arch we
test for supported targets using istarget, like so:
...
if { [istarget "i*86-*-*"] || [istarget "x86_64-*-*"] } {
...
} elseif { [istarget "powerpc-*-linux*"] \
|| [istarget "powerpc64*-linux*"] } {
...
...
but the tests excercised there can all be executed if gdb is configured with
--enable-targets=all.
Rewrite the proc to iterate over all cases, and check if the test is supported
by trying "set arch $arch1" and "set arch $arch2".
Tested on x86_64-linux, with:
- a gdb build with --enable-targets=all, and
- a gdb build build with my usual --enable-targets setting (too long to
include here) which means the sparc vs sparc:v9 case is unsupported.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When running test-case gdb.reverse/fstatat-reverse.exp with target board
unix/-m32 on openSUSE Tumbleweed, I run into:
...
(gdb) PASS: gdb.reverse/fstatat-reverse.exp: set breakpoint at marker2
continue^M
Continuing.^M
Process record and replay target doesn't support syscall number 383^M
Process record: failed to record execution log.^M
^M
Program stopped.^M
0xf7fc5555 in __kernel_vsyscall ()^M
(gdb) FAIL: gdb.reverse/fstatat-reverse.exp: continue to breakpoint: marker2
...
The problems is that while with native we're trying to record these syscalls
(showing strace output):
...
openat(AT_FDCWD, "/", O_RDONLY|O_PATH) = 3
newfstatat(3, ".", {st_mode=S_IFDIR|0755, st_size=146, ...}, 0) = 0
...
with unix/-m32 we have instead:
...
openat(AT_FDCWD, "/", O_RDONLY|O_PATH) = 3
statx(3, ".", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT, STATX_BASIC_STATS, \
{stx_mask=STATX_ALL|STATX_MNT_ID, stx_attributes=STATX_ATTR_MOUNT_ROOT, \
stx_mode=S_IFDIR|0755, stx_size=146, ...}) = 0
...
and statx is not supported.
Fix this by adding support for recording syscall statx.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28461
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Note that opcodes is regenerated with cgen commit d1dd5fcc38e reverted,
due to failure of bpf to compile with that patch applied.
.../opcodes/bpf-opc.c:57:11: error: conversion from ‘long unsigned int’ to ‘unsigned int’ changes value from ‘18446744073709486335’ to ‘4294902015’ [-Werror=overflow]
57 | 64, 64, 0xffffffffffff00ff, { { F (F_IMM32) }, { F (F_OFFSET16) }, { F (F_SRCLE) }, { F (F_OP_CODE) }, { F (F_DSTLE) }, { F (F_OP_SRC) }, { F (F_OP_CLASS) }, { 0 } }
plus other similar errors.
cpu/
* mep.opc (print_tpreg, print_spreg): Delete unnecessary
forward declarations. Replace PTR with void *.
* mt.opc (print_dollarhex, print_pcrel): Delete forward decls.
opcodes/
* bpf-desc.c, * bpf-dis.c, * cris-desc.c,
* epiphany-desc.c, * epiphany-dis.c,
* fr30-desc.c, * fr30-dis.c, * frv-desc.c, * frv-dis.c,
* ip2k-desc.c, * ip2k-dis.c, * iq2000-desc.c, * iq2000-dis.c,
* lm32-desc.c, * lm32-dis.c, * m32c-desc.c, * m32c-dis.c,
* m32r-desc.c, * m32r-dis.c, * mep-desc.c, * mep-dis.c,
* mt-desc.c, * mt-dis.c, * or1k-desc.c, * or1k-dis.c,
* xc16x-desc.c, * xc16x-dis.c,
* xstormy16-desc.c, * xstormy16-dis.c: Regenerate.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
$ objdump -d outputs/gdb.base/large-frame/large-frame-O2
0000000120000b20 <func>:
120000b20: 67bdbff0 daddiu sp,sp,-16400
120000b24: ffbc4000 sd gp,16384(sp)
120000b28: 3c1c0002 lui gp,0x2
120000b2c: 679c8210 daddiu gp,gp,-32240
120000b30: 0399e02d daddu gp,gp,t9
120000b34: df998058 ld t9,-32680(gp)
120000b38: ffbf4008 sd ra,16392(sp)
120000b3c: 0411ffd8 bal 120000aa0 <blah>
...
The disassembly of the above func function shows that we may use
instructions such as daddiu/daddu, so add "daddiu $gp,$gp,n",
"daddu $gp,$gp,$t9" and "daddu $gp,$t9,$gp" to the mips32_scan_prologue
function to fix the large-frame.exp test case.
Before applying the patch:
backtrace
#0 blah (a=0xfffffee220) at .../gdb/testsuite/gdb.base/large-frame-1.c:24
#1 0x0000000120000b44 in func ()
Backtrace stopped: frame did not save the PC
(gdb) FAIL: gdb.base/large-frame.exp: optimize=-O2: backtrace
# of expected passes 5
# of unexpected failures 1
After applying the patch:
# of expected passes 6
Signed-off-by: Youling Tang <tangyouling@loongson.cn>
|
| |
|
|
|
|
|
| |
The GDB style is to write 'if (readbuf != nullptr)', and the same for
writebuf.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PR build/29110 points out that GDB fails to build on mingw when the
"win32" thread model is in use. It turns out that the Fedora cross
tools using the "posix" thread model, which somehow manages to support
std::future, whereas the win32 model does not.
While looking into this, I found that the configuring with
--disable-threading will also cause a build failure.
This patch fixes this build by introducing a compatibility wrapper for
std::future.
I am not able to test the win32 thread model build, but I'm going to
ask the reporter to try this patch.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29110
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If you try to set a breakpoint at a function such as "b
f(std::string)", and the current language is C, the breakpoint fails
to be set, like so:
(gdb) set language c
break f(std::string)
Function "f(std::string)" not defined.
Make breakpoint pending on future shared library load? (y or [n]) n
(gdb)
The problem is that the code in GDB that expands the std::string
typedef hits this in c-typeprint.c:
/* If we have "typedef struct foo {. . .} bar;" do we want to
print it as "struct foo" or as "bar"? Pick the latter for
C++, because C++ folk tend to expect things like "class5
*foo" rather than "struct class5 *foo". We rather
arbitrarily choose to make language_minimal work in a C-like
way. */
if (language == language_c || language == language_minimal)
{
if (type->code () == TYPE_CODE_UNION)
gdb_printf (stream, "union ");
else if (type->code () == TYPE_CODE_STRUCT)
{
if (type->is_declared_class ())
gdb_printf (stream, "class ");
else
gdb_printf (stream, "struct ");
}
else if (type->code () == TYPE_CODE_ENUM)
gdb_printf (stream, "enum ");
}
I.e., std::string is expanded to "class std::..." instead of just
"std::...", and then the "f(class std::..." symbol doesn't exist.
Fix this by making cp-support.c:inspect_type print the expanded
typedef type using the language of the symbol whose type we're
expanding the typedefs for -- in the example in question, the
"std::string" typedef symbol, which is a C++ symbol.
Use type_print_raw_options as it seems to me that in this scenario we
always want raw types, to match the real symbol names.
Adjust the gdb.cp/break-f-std-string.exp testcase to try setting a
breakpoint at "f(std::string)" in both C and C++.
Change-Id: Ib54fab4cf0fd307bfd55bf1dd5056830096a653b
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The next patch will want to do language->print_type(type, ...), to
print a type in a given language, avoiding a dependency on the current
language. That doesn't work correctly currently, however, because
most language implementations of language_defn::print_type call
c_print_type without passing down the language. There are two
overloads of c_print_type, one that takes a language, and one that
does not. The one that does not uses the current language, defeating
the point of calling language->print_type()...
This commit removes the c_print_type overload that does not take a
language, and adjusts the codebase throughout to always pass down a
language. In most places, there's already an enum language handy.
language_defn::print_type implementations naturally pass down
this->la_language. In a couple spots, like in ada-typeprint.c and
rust-lang.c there's no enum language handy, but the code is written
for a specific language, so we just hardcode the language.
In gnuv3_print_method_ptr, I wasn't sure whether we could hardcode C++
here, and we don't have an enum language handy, so I made it use the
current language, just like today. Can always be improved later.
Change-Id: Ib54fab4cf0fd307bfd55bf1dd5056830096a653b
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, on any remotely modern GNU/Linux system,
gdb.cp/no-dmgl-verbose.exp fails like so:
break 'f(std::string)'
Function "f(std::string)" not defined.
(gdb) FAIL: gdb.cp/no-dmgl-verbose.exp: gdb_breakpoint: set breakpoint at 'f(std::string)'
break 'f(std::basic_string<char, std::char_traits<char>, std::allocator<char> >)'
Function "f(std::basic_string<char, std::char_traits<char>, std::allocator<char> >)" not defined.
(gdb) PASS: gdb.cp/no-dmgl-verbose.exp: DMGL_VERBOSE-demangled f(std::string) is not defined
This testcase was added back in 2011, here:
[patch] Remove DMGL_VERBOSE
https://sourceware.org/pipermail/gdb-patches/2011-June/083081.html
Back then, the testcase would pass cleanly. It turns out that the
reason it fails today is that the testcase is exercising something in
GDB that only makes sense if the program is built for the pre-C++11
libstc++ ABI. Back then the C++11 ABI didn't exist yet, but nowadays,
you need to compile with -D_GLIBCXX_USE_CXX11_ABI=0 to use the old
ABI. See "Dual ABI" in the libstdc++ manual, at
<https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html>.
If we tweak the gdb.cp/no-dmgl-verbose.exp testcase to force the old
ABI with -D_GLIBCXX_USE_CXX11_ABI=0, then it passes cleanly.
So why is it that setting a breakpoint at "f(std::string)" fails with
modern ABI, but passes with old ABI?
This is where libiberty demangler's DMGL_VERBOSE option comes in. The
Itanium ABI mangling scheme has a shorthand form for std::string (and
some other types). See
<https://itanium-cxx-abi.github.io/cxx-abi/abi.html>:
"In addition, the following catalog of abbreviations of the form "Sx" are used:
<substitution> ::= St # ::std::
<substitution> ::= Sa # ::std::allocator
<substitution> ::= Sb # ::std::basic_string
<substitution> ::= Ss # ::std::basic_string < char,
::std::char_traits<char>,
::std::allocator<char> >
<substitution> ::= Si # ::std::basic_istream<char, std::char_traits<char> >
<substitution> ::= So # ::std::basic_ostream<char, std::char_traits<char> >
<substitution> ::= Sd # ::std::basic_iostream<char, std::char_traits<char> >
"
When the libiberty demangler encounters such a abbreviation, by
default, it expands it to the user-friendly typedef "std::string",
"std::iostream", etc.. If OTOH DMGL_VERBOSE is specified, the
abbreviation is expanded to the underlying, non-typedefed fullname
"std::basic_string<char, std::char_traits<char>, std::allocator<char> >"
etc. as documented in the Itanium ABI, and pasted above. You can see
the standard abbreviations/substitutions in
libiberty/cp-demangle.c:standard_subs.
Back before Jan's patch in 2011, there were parts of GDB that used
DMGL_VERBOSE, and others that did not, leading to mismatches. The
solution back then was to stop using DMGL_VERBOSE throughout.
GDB has code in place to let users set a breakpoint at a function with
typedefs in its parameters, like "b f(uint32_t)". Demangled function
names as they appear in the symbol tables almost (more on this is in a
bit) never have typedefs in them, so when processing "b f(uint32_t)"
GDB first replaces "uint32_t" for its underlying type, and then sets a
breakpoint on the resulting prototype, in this case "f(unsigned int)".
Now, if DMGL_VERBOSE is _not_ used, then the demangler demangles the
mangled name of a function such as "void f(std::string)" that was
mangled using the standard abbreviations mentioned above really as:
"void f(std::string)".
For example, the mangled name of "void f(std::string)" if you compile
with old pre-C++11 ABI is "_Z1fSs". That uses the abbreviation "Ss",
so if you demangle that without DMGL_VERBOSE, you get:
$ echo "_Z1fSs" | c++filt --no-verbose
f(std::string)
while with DMGL_VERBOSE you'd get:
$ echo "_Z1fSs" | c++filt
f(std::basic_string<char, std::char_traits<char>, std::allocator<char> >)
If, when the user sets a breakpoint at "f(std::string)", GDB would
replace the std::string typedef for its underlying type using the same
mechanism I mentioned for the "f(uint32_t)" example above, then GDB
would really try to set a breakpoint at "f(std::basic_string<char,
std::char_traits<char>, std::allocator<char> >)", and that would fail,
as the function symbol GDB knows about for that function, given no
DMGL_VERBOSE, is "f(std::string)".
For this reason, the code that expands typedefs in function parameter
names has an exception for std::string (and other standard
abbreviation types), such that "std::string" is never
typedef-expanded.
And here lies the problem when you try to do "b f(std::string)" with a
program compiled with the C++11 ABI. In that case, std::string
expands to a different underlying type, like so:
f(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >)
and this symbol naturally mangles differently, as:
_Z1fNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
and then because this doesn't use the shorthand mangling abbreviation
for "std::string" anymore, it always demangles as:
f(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >)
Now, when using the C++11 ABI, and you set a breakpoint at
"f(std::string)", GDB's typedefs-in-parameters expansion code hits the
exception for "std::string" and doesn't expand it, so the breakpoint
fails to be inserted, because the symbol that exists is really the
f(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >)
one, not "f(std::string)".
So to fix things for C++11 ABI, clearly we need to remove the
"std::string" exception from the typedef-in-parameters expansion
logic. If we do just that, then "b f(std::string)" starts working
with the C++11 ABI.
However, if we do _just_ that, and nothing else, then we break
pre-C++11 ABI...
The solution is then to in addition switch GDB to always use
DMGL_VERBOSE. If we do this, then pre-C++11 ABI symbols works the
same as C++11 ABI symbols overall -- the demangler expands the
standard abbreviation for "std::string" as "std::basic_string<char,
std::char_traits<char>, std::allocator<char> >" and letting GDB expand
the "std::string" typedef (etc.) too is no longer a problem.
To avoid getting in the situation where some parts of GDB use
DMGL_VERBOSE and others not, this patch adds wrappers around the
demangler's entry points that GDB uses, and makes those force
DMGL_VERBOSE.
The point of the gdb.cp/no-dmgl-verbose.exp testcase was to try to
ensure that DMGL_VERBOSE doesn't creep back in:
gdb_test {break 'f(std::basic_string<char, std::char_traits<char>, std::allocator<char> >)'} \
{Function ".*" not defined\.} \
"DMGL_VERBOSE-demangled f(std::string) is not defined"
This obviously no longer makes sense to have, since we now depend on
DMGL_VERBOSE. So the patch replaces gdb.cp/no-dmgl-verbose.exp with a
new gdb.cp/break-f-std-string.exp testcase whose purpose is to make
sure that setting a breakpoint at "f(std::string)" works. It
exercises both pre-C++11 ABI and C++11 ABI.
Change-Id: Ib54fab4cf0fd307bfd55bf1dd5056830096a653b
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit fixes two regressions introduced by
891e4190ba705373eec7b374209478215fff5401.
Reason for the failures was, that on a 32 bit machine the maximum
array length as well as the maximum allocatable memory for arrays
(in bytes) both seem to be limited by the maximum value of a 4
byte (signed) Fortran integer. This lead to compiler errors/unexpected
behavior when compiling/running the test with the -m32 board. This
behavior is compiler dependent and can differ for different compiler
implementations, but generally, it seemed like a good idea to simply
avoid such situations.
The affected tests check for GDB's overflow behavior when using KIND
parameters with GDB implemented Fortran intrinsic functions. If these
KIND parameters are too small to fit the actual intrinsic function's
result, an overflow is expected. This was done for 1, 2, and 4
byte overflows. The last one caused problems, as it tried to allocate
arrays of length/byte-size bigger than the 4 byte signed integers which
would then be used with the LBOUND/UBOUND/SIZE intrinsics.
The tests were adapted to only execute the 4 byte overflow tests when
running on targets with 64 bit. For this, the compiled tests evaluate the
byte size of a C_NULL_PTR via C_SIZEOF, both defined in the ISO_C_BINDING
module. The ISO_C_BINDING constant C_NULL_PTR is a Fortran 2003, the
C_SIZEOF a Fortran 2008 extension. Both have been implemented in their
respective compilers for while (e.g. C_SIZEOF is available since
gfortran 4.6). If this byte size evaluates to less than 8 we skip the
4 byte overflow tests in the compiled tests of size.f90 and
lbound-ubound.f90. Similarly, in the lbound-ubound.exp testsfile we skip
the 4 byte overflow tests if the procedure is_64_target evaluates to false.
In size.f90, additionally, the to-be-allocated amount of bytes did not
fit into 4 byte signed integers for some of the arrays, as it was
approximately 4 times the maximum size of a 4 byte signed integer. We
adapted the dimensions of the arrays in question as the meaningfulness
of the test does not suffer from this.
With this patch both test run fine with the unix/-m32 board and
gcc/gfortran (9.4) as well as the standard board file.
We also thought about completely removing the affected test from the
testsuite. We decided against this as the 32 bit identification comes
with Fortran 2008 and removing tests would have decreased coverage.
A last change that happened with this patch was due to gfortran's and
ifx's type resolution when assigning big constants to Fortran Integer*8
variables. Before the above changes this happened in a parameter
statement. Here, both compilers happily accepted a line like
integer*8, parameter :: var = 2147483647 + 5.
After this change the assignment is not done as a parameter
anymore, as this triggered compile time overflow errors. Instead,
the assignment is done dynamically, depending on the kind of machine one
is on. Sadly, just changing this line to
integer*8 :: var
var = 2147483647 + 5
does not work with ifx (or flang for that matter, they behave similarly
here). It will create an integer overflow in the addition as ifx deduces
the type the additon is done in as Integer*4. So var will actually
contain the value -2147483644 after this. The lines
integer*8 :: var
var = 2147483652
on the other hand fail to compile with gfortran (9.4.0) as the compiler
identifies an Integer overflow here. Finally, to make this work with
all three compilers an additional parameter has been introduced
integer*8, parameter :: helper = 2147483647
integer*8 :: var
var = helper + 5.
This works on all 3 compilers as expected.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29053
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29054
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The other day, while looking at the symbols that end up in a GDB
index, I noticed that the gdb::observers::observable::visit_state enum
class appears a number of times:
$ grep VISIT gdb-index-symbol-names.txt
gdb::observers::observable<bpstat*, int>::visit_state::NOT_VISITED
gdb::observers::observable<bpstat*, int>::visit_state::VISITED
gdb::observers::observable<bpstat*, int>::visit_state::VISITING
gdb::observers::observable<breakpoint*>::visit_state::NOT_VISITED
gdb::observers::observable<breakpoint*>::visit_state::VISITED
gdb::observers::observable<breakpoint*>::visit_state::VISITING
gdb::observers::observable<char const*, char const*>::visit_state::NOT_VISITED
gdb::observers::observable<char const*, char const*>::visit_state::VISITED
gdb::observers::observable<char const*, char const*>::visit_state::VISITING
gdb::observers::observable<char const*>::visit_state::NOT_VISITED
gdb::observers::observable<char const*>::visit_state::VISITED
gdb::observers::observable<char const*>::visit_state::VISITING
gdb::observers::observable<enum_flags<user_selected_what_flag> >::visit_state::NOT_VISITED
gdb::observers::observable<enum_flags<user_selected_what_flag> >::visit_state::VISITED
gdb::observers::observable<enum_flags<user_selected_what_flag> >::visit_state::VISITING
gdb::observers::observable<frame_info*, int>::visit_state::NOT_VISITED
gdb::observers::observable<frame_info*, int>::visit_state::VISITED
gdb::observers::observable<frame_info*, int>::visit_state::VISITING
gdb::observers::observable<gdbarch*>::visit_state::NOT_VISITED
gdb::observers::observable<gdbarch*>::visit_state::VISITED
gdb::observers::observable<gdbarch*>::visit_state::VISITING
gdb::observers::observable<gdb_signal>::visit_state::NOT_VISITED
gdb::observers::observable<gdb_signal>::visit_state::VISITED
gdb::observers::observable<gdb_signal>::visit_state::VISITING
[... snip ...]
$ grep VISIT gdb-index-symbol-names.txt | wc -l
72
enum class visit_state is defined inside the class template
observable, but it doesn't have to be, as it does not depend on the
template parameters. This commit moves it out, so that only one such
type exists. This reduces the size of a -O0 -g3 build for me by
around 0.6%, like so:
$ du -b gdb.before gdb.after
164685280 gdb.before
163707424 gdb.fixed
and codesize by some 0.5%.
Change-Id: I405f4ef27b8358fdd22158245b145d849b45658e
|
| | |
|
| |
|
|
|
|
|
| |
gprofng/ChangeLog
2022-05-09 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
* src/gprofng.rc: Include percentages in default metrics list.
|
| |
|
|
|
|
|
|
|
| |
* basic_blocks.c: Replace uses of PTR with void * throughout.
* cg_arcs.c: Likewise.
* cg_print.c: Likewise.
* hist.c: Likewise.
* source.h: Likewise.
* symtab.c: Likewise.
|
| |
|
|
| |
* config/obj-evax.c (evax_symbol_new_hook): Don't cast to PTR.
|
| |
|
|
|
|
|
|
|
|
|
| |
The non-cgen parts of opcodes.
* cr16-dis.c (print_arg): Replace PTR with void *.
* crx-dis.c (print_arg): Likewise.
* rl78-dis.c (print_insn_rl78_common): Don't use PTR cast.
* rx-dis.c (print_insn_rx): Likewise.
* visium-dis.c (print_insn_visium): Likewise.
* z8k-dis.c (print_insn_z8k): Likewise.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
* coffcode.h (coff_write_object_contents): Don't cast to PTR.
* elf32-csky.c (csky_elf_link_hash_traverse): Remove use of PTR
and PARAMS.
(csky_allocate_dynrelocs): Don't use PTR cast.
* elf32-nios2.c (adjust_dynrelocs, allocate_dynrelocs): Replace
PTR with void *.
* elf32-visium.c (visium_elf_howto_parity_reloc): Likewise.
* elfxx-ia64.c (ia64_elf_reloc): Likewise.
* plugin.c (bfd_plugin_bfd_print_private_bfd_data): Likewise.
|
| |
|
|
|
| |
* hashtab.h (HTAB_EMPTY_ENTRY): Replace PTR with void *.
(HTAB_DELETED_ENTRY): Likewise.
|
| | |
|
