| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
I wrote a read_core_file_mappings method for FreeBSD and then registered
this gdbarch method. I saw some strange behavior while testing it and
wanted a way to make sure that mappings were being correctly loaded
into corelow.c, so I wrote the new command which is the topic of this
commit. I think it might be occasionally useful for debugging strange
corefile behavior.
With regard to FreeBSD, my work isn't ready yet. Unlike Linux,
FreeBSD puts all mappings into its core file note. And, unlike Linux,
it doesn't dump load segments which occupy no space in the file. So
my (perhaps naive) implementation of a FreeBSD read_core_file_mappings
didn't work all that well: I saw more failures in the corefile2.exp
tests than without it. I think it should be possible to make FreeBSD
work as well as Linux, but it will require doing something with all of
the mappings, not just the file based mappings that I was considering.
In the v4 series, Pedro asked the following:
I don't understand what this command provides that "info proc
mappings" doesn't? Can you give an example of when you'd use this
command over "info proc mappings" ?
On Linux, "info proc mappings" and "maint print core-file-backed-mappings"
will produce similar, possibly identical, output. This need not be
the case for other OSes. E.g. on FreeBSD, had I finished the
implementation, the output from these commands would have been very
different. The FreeBSD "info proc mappings" command would show
additional (non-file-backed) mappings in addition to at least one
additional field (memory permissions) for each mapping.
As noted earlier, I was seeing some unexpected behavior while working
on the FreeBSD implementation and wanted to be certain that the
mappings were being correctly loaded by corelow.c. "info proc
mappings" prints the core file mappings, but doesn't tell us anything
about whether they've been loaded by corelow.c This new maintenance
command directly interrogates the data structures and prints the
values found there.
gdb/ChangeLog:
* corelow.c (gdbcmd.h): Include.
(core_target::info_proc_mappings): New method.
(get_current_core_target): New function.
(maintenance_print_core_file_backed_mappings): New function.
(_initialize_corelow): Add core-file-backed-mappings to
"maint print" commands.
|
|
This commit makes adjustments to coredump-filter.exp to account
for the fact that NT_FILE file-backed mappings are now available
when a core file is loaded. Thus, a test which was expected
to PASS when a memory region was determined to be unavailable
(due to no file-backed mappings being available) will now FAIL
due to those mappings being available from having loaded the
NT_FILE note.
I had originally marked the test as XFAIL, but Mihails Strasuns
suggested a much better approach:
1) First test that it still works if file is accessible in the
filesystem.
2) Temporarily move / rename the file and test that disassembly
doesn't work anymore.
That's what this commit implements.
gdb/testsuite/ChangeLog:
* gdb.base/coredump-filter.exp: Add second
non-Private-Shared-Anon-File test.
(test_disasm): Rename binfile for test which is expected
to fail.
|
|
When making a core file with the GDB's gcore command on Linux,
the same criteria used for determining which mappings should be
dumped were also being used for determining which entries should
be placed in the NT_FILE note. This is wrong; we want to place
all file-backed mappings in this note.
The predicate function, dump_mapping_p, was used to determine whether
or not to dump a mapping from within linux_find_memory_regions_full.
This commit leaves this predicate in place, but adds a new parameter,
should_dump_mapping_p, to linux_find_memory_regions_full. It then
calls should_dump_mapping_p instead of dump_mapping_p. dump_mapping_p
is passed to linux_find_memory_regions_full at one call site; at the
other call site, dump_note_entry_p is passed instead.
gdb/ChangeLog:
* linux-tdep.c (dump_note_entry_p): New function.
(linux_dump_mapping_p_ftype): New typedef.
(linux_find_memory_regions_full): Add new parameter,
should_dump_mapping_p.
(linux_find_memory_regions): Adjust call to
linux_find_memory_regions_full.
(linux_make_mappings_core_file_notes): Use dump_note_entry_p in
call to linux_find_memory_regions_full.
|
|
This test passes when run using a GDB with my corefile patches. When
run against a GDB without my patches, I see the following failures,
the first of which is due to the test added by this commit:
FAIL: gdb.base/corefile.exp: accessing read-only mmapped data in core file (mapping address not found in core file)
FAIL: gdb.base/corefile.exp: accessing anonymous, unwritten-to mmap data
gdb/testsuite/ChangeLog:
* gdb.base/corefile.exp: Add test "accessing read-only mmapped
data in core file".
* gdb.base/coremaker.c (buf2ro): New global.
(mmapdata): Add a read-only mmap mapping.
|
|
In his reviews of my v1 and v2 corefile related patches, Pedro
identified two cases which weren't handled by those patches.
In https://sourceware.org/pipermail/gdb-patches/2020-May/168826.html,
Pedro showed that debugging a core file in which mmap() is used to
create a new mapping over an existing file-backed mapping will
produce incorrect results. I.e, for his example, GDB would
show:
(gdb) disassemble main
Dump of assembler code for function main:
0x00000000004004e6 <+0>: push %rbp
0x00000000004004e7 <+1>: mov %rsp,%rbp
=> 0x00000000004004ea <+4>: callq 0x4003f0 <abort@plt>
End of assembler dump.
This sort of looks like it might be correct, but is not due to the
fact that mmap(...MAP_FIXED...) was used to create a mapping (of all
zeros) on top of the .text section. So, the correct result should be:
(gdb) disassemble main
Dump of assembler code for function main:
0x00000000004004e6 <+0>: add %al,(%rax)
0x00000000004004e8 <+2>: add %al,(%rax)
=> 0x00000000004004ea <+4>: add %al,(%rax)
0x00000000004004ec <+6>: add %al,(%rax)
0x00000000004004ee <+8>: add %al,(%rax)
End of assembler dump.
The other case that Pedro found involved an attempted examination of a
particular section in the test case from gdb.base/corefile.exp. On
Fedora 27 or 28, the following behavior may be observed:
(gdb) info proc mappings
Mapped address spaces:
Start Addr End Addr Size Offset objfile
...
0x7ffff7839000 0x7ffff7a38000 0x1ff000 0x1b5000 /usr/lib64/libc-2.27.so
...
(gdb) x/4x 0x7ffff7839000
0x7ffff7839000: Cannot access memory at address 0x7ffff7839000
FYI, this section appears to be unrelocated vtable data. See
https://sourceware.org/pipermail/gdb-patches/2020-May/168331.html for
a detailed analysis.
The important thing here is that GDB should be able to access this
address since it should be backed by the shared library. I.e. it
should do this:
(gdb) x/4x 0x7ffff7839000
0x7ffff7839000: 0x0007ddf0 0x00000000 0x0007dba0 0x00000000
Both of these cases are fixed with this commit.
In a nutshell, this commit opens a "binary" target BFD for each of the
files that are mentioned in an NT_FILE / .note.linuxcore.file note
section. It then uses these mappings instead of the file stratum
mappings that GDB has used in the past.
If this note section doesn't exist or is mangled for some reason, then
GDB will use the file stratum as before. Should this happen, then
we can expect both of the above problems to again be present.
See the code comments in the commit for other details.
gdb/ChangeLog:
* corelow.c (solist.h, unordered_map): Include.
(class core_target): Add field m_core_file_mappings and
method build_file_mappings.
(core_target::core_target): Call build_file_mappings.
(core_target::~core_target): Free memory associated with
m_core_file_mappings.
(core_target::build_file_mappings): New method.
(core_target::xfer_partial): Use m_core_file_mappings
for memory transfers.
* linux-tdep.c (linux_read_core_file_mappings): New
function.
(linux_core_info_proc_mappings): Rewrite to use
linux_read_core_file_mappings.
(linux_init_abi): Register linux_read_core_file_mappings.
|
|
The new gdbarch method, read_core_file_mappings, will be used for
reading file-backed mappings from a core file. It'll be used
for two purposes: 1) to construct a table of file-backed mappings
in corelow.c, and 2) for display of core file mappings.
For Linux, I tried a different approach in which knowledge of the note
format was placed directly in corelow.c. This seemed okay at first;
it was only one note format and the note format was fairly simple.
After looking at FreeBSD's note/mapping reading code, I concluded
that it's best to leave architecture specific details for decoding
the note in (architecture specific) tdep files.
With regard to display of core file mappings, I experimented with
placing the mappings display code in corelow.c. It has access to the
file-backed mappings which were read in when the core file was loaded.
And, better, still common code could be used for all architectures.
But, again, the FreeBSD mapping code convinced me that this was not
the best approach since it has even more mapping info than Linux.
Display code which would work well for Linux will leave out mappings
as well as protection info for mappings.
So, for these reasons, I'm introducing a new gdbarch method for
reading core file mappings.
gdb/ChangeLog:
* arch-utils.c (default_read_core_file_mappings): New function.
* arch-utils.c (default_read_core_file_mappings): Declare.
* gdbarch.sh (read_core_file_mappings): New gdbarch method.
* gdbarch.h, gdbarch.c: Regenerate.
|
|
gdb/testsuite/ChangeLog:
PR corefiles/25631
* gdb.base/corefile.exp (accessing anonymous, unwritten-to mmap data):
New test.
* gdb.base/coremaker.c (buf3): New global.
(mmapdata): Add mmap call which uses MAP_ANONYMOUS and MAP_PRIVATE
flags.
|
|
Consider the following program:
- - - mkmmapcore.c - - -
static char *buf;
int
main (int argc, char **argv)
{
buf = mmap (NULL, 8192, PROT_READ | PROT_WRITE,
MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
abort ();
}
- - - end mkmmapcore.c - - -
Compile it like this:
gcc -g -o mkmmapcore mkmmapcore.c
Now let's run it from GDB. I've already placed a breakpoint on the
line with the abort() call and have run to that breakpoint.
Breakpoint 1, main (argc=1, argv=0x7fffffffd678) at mkmmapcore.c:11
11 abort ();
(gdb) x/x buf
0x7ffff7fcb000: 0x00000000
Note that we can examine the memory allocated via the call to mmap().
Now let's try debugging a core file created by running this program.
Depending on your system, in order to make a core file, you may have to
run the following as root (or using sudo):
echo core > /proc/sys/kernel/core_pattern
It may also be necessary to do:
ulimit -c unlimited
I'm using Fedora 31. YMMV if you're using one of the BSDs or some other
(non-Linux) system.
This is what things look like when we debug the core file:
[kev@f31-1 tmp]$ gdb -q ./mkmmapcore core.304767
Reading symbols from ./mkmmapcore...
[New LWP 304767]
Core was generated by `/tmp/mkmmapcore'.
Program terminated with signal SIGABRT, Aborted.
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 return ret;
(gdb) x/x buf
0x7ffff7fcb000: Cannot access memory at address 0x7ffff7fcb000
Note that we can no longer access the memory region allocated by mmap().
Back in 2007, a hack for GDB was added to _bfd_elf_make_section_from_phdr()
in bfd/elf.c:
/* Hack for gdb. Segments that have not been modified do
not have their contents written to a core file, on the
assumption that a debugger can find the contents in the
executable. We flag this case by setting the fake
section size to zero. Note that "real" bss sections will
always have their contents dumped to the core file. */
if (bfd_get_format (abfd) == bfd_core)
newsect->size = 0;
You can find the entire patch plus links to other discussion starting
here:
https://sourceware.org/ml/binutils/2007-08/msg00047.html
This hack sets the size of certain BFD sections to 0, which
effectively causes GDB to ignore them. I think it's likely that the
bug described above existed even before this hack was added, but I
have no easy way to test this now.
The output from objdump -h shows the result of this hack:
25 load13 00000000 00007ffff7fcb000 0000000000000000 00013000 2**12
ALLOC
(The first field, after load13, shows the size of 0.)
Once the hack is removed, the output from objdump -h shows the correct
size:
25 load13 00002000 00007ffff7fcb000 0000000000000000 00013000 2**12
ALLOC
(This is a digression, but I think it's good that objdump will now show
the correct size.)
If we remove the hack from bfd/elf.c, but do nothing to GDB, we'll
see the following regression:
FAIL: gdb.base/corefile.exp: print coremaker_ro
The reason for this is that all sections which have the BFD flag
SEC_ALLOC set, but for which SEC_HAS_CONTENTS is not set no longer
have zero size. Some of these sections have data that can (and should)
be read from the executable. (Sections for which SEC_HAS_CONTENTS
is set should be read from the core file; sections which do not have
this flag set need to either be read from the executable or, failing
that, from the core file using whatever BFD decides is the best value
to present to the user - it uses zeros.)
At present, due to the way that the target strata are traversed when
attempting to access memory, the non-SEC_HAS_CONTENTS sections will be
read as zeroes from the process_stratum (which in this case is the
core file stratum) without first checking the file stratum, which is
where the data might actually be found.
What we should be doing is this:
- Attempt to access core file data for SEC_HAS_CONTENTS sections.
- Attempt to access executable file data if the above fails.
- Attempt to access core file data for non SEC_HAS_CONTENTS sections, if
both of the above fail.
This corresponds to the analysis of Daniel Jacobowitz back in 2007
when the hack was added to BFD:
https://sourceware.org/legacy-ml/binutils/2007-08/msg00045.html
The difference, observed by Pedro in his review of my v1 patches, is
that I'm using "the section flags as proxy for the p_filesz/p_memsz
checks."
gdb/ChangeLog:
PR corefiles/25631
* corelow.c (core_target:xfer_partial): Revise
TARGET_OBJECT_MEMORY case to consider non-SEC_HAS_CONTENTS
case after first checking the stratum beneath the core
target.
(has_all_memory): Return true.
* target.c (raw_memory_xfer_partial): Revise comment
regarding use of has_all_memory.
|
|
This patch is motivated by the need to be able to select sections
that section_table_xfer_memory_partial should consider for memory
transfers. I'll use this facility in the next patch in this series.
section_table_xfer_memory_partial() can currently be passed a section
name which may be used to make name-based selections. This is similar
to what I want to do, except that I want to be able to consider
section flags instead of the name.
I'm replacing the section name parameter with a predicate that,
when passed a pointer to a target_section struct, will return
true if that section should be further considered, or false which
indicates that it shouldn't.
I've converted the one existing use where a non-NULL section
name is passed to section_table_xfer_memory_partial(). Instead
of passing the section name, it now looks like this:
auto match_cb = [=] (const struct target_section *s)
{
return (strcmp (section_name, s->the_bfd_section->name) == 0);
};
return section_table_xfer_memory_partial (readbuf, writebuf,
memaddr, len, xfered_len,
table->sections,
table->sections_end,
match_cb);
The other callers all passed NULL; they've been simplified somewhat
in that they no longer need to pass NULL.
gdb/ChangeLog:
* exec.h (section_table_xfer_memory): Revise declaration,
replacing section name parameter with an optional callback
predicate.
* exec.c (section_table_xfer_memory): Likewise.
* bfd-target.c, exec.c, target.c, corelow.c: Adjust all callers
of section_table_xfer_memory.
|
|
In his review of my BZ 25631 patch series, Pedro was unable to
reproduce the regression which should occur after patch #1, "Remove
hack for GDB which sets the section size to 0", is applied.
Pedro was using an ld version older than 2.30. Version 2.30
introduced the linker option -z separate-code. Here's what the man
page has to say about it:
Create separate code "PT_LOAD" segment header in the object. This
specifies a memory segment that should contain only instructions
and must be in wholly disjoint pages from any other data.
In ld version 2.31, use of separate-code became the default for
Linux/x86. So, really, 2.31 or later is required in order to see the
regression that occurs in recent Linux distributions when only the
bfd hack removal patch is applied.
For the test case in question, use of the separate-code linker option
means that the global variable "coremaker_ro" ends up in a separate
load segment (though potentially with other read-only data). The
upshot of this is that when only patch #1 is applied, GDB won't be
able to correctly access coremaker_ro. The reason for this is due
to the fact that this section will now have a non-zero size, but
will not have contents from the core file to find this data.
So GDB will ask BFD for the contents and BFD will respond with
zeroes for anything from those sections. GDB should instead be
looking in the executable for this data. Failing that, it can
then ask BFD for a reasonable value. This is what a later patch
in this series does.
When using ld versions earlier than 2.31 (or 2.30 w/ the
-z separate-code option explicitly provided to the linker), there is
the possibility that coremaker_ro ends up being placed near other data
which is recorded in the core file. That means that the correct value
will end up in the core file, simply because it resides on a page that
the kernel chooses to put in the core file. This is why Pedro wasn't
able to reproduce the regression that should occur after fixing the
BFD hack.
This patch places a big chunk of memory, two pages worth on x86, in
front of "coremaker_ro" to attempt to force it onto another page
without requiring use of that new-fangled linker switch.
Speaking of which, I considered changing the test to use
-z separate-code, but this won't work because it didn't
exist prior to version 2.30. The linker would probably complain
of an unrecognized switch. Also, it likely won't be available in
other linkers not based on current binutils. I.e. it probably won't
work in FreeBSD, NetBSD, etc.
To make this more concrete, this is what *should* happen when
attempting to access coremaker_ro when only patch #1 is applied:
Core was generated by `/mesquite2/sourceware-git/f28-coresegs/bld/gdb/testsuite/outputs/gdb.base/coref'.
Program terminated with signal SIGABRT, Aborted.
#0 0x00007f68205deefb in raise () from /lib64/libc.so.6
(gdb) p coremaker_ro
$1 = 0
Note that this result is wrong; 201 should have been printed instead.
But that's the point of the rest of the patch series.
However, without this commit, or when using an old Linux distro with
a pre-2.31 ld, this is what you might see instead:
Core was generated by `/mesquite2/sourceware-git/f28-coresegs/bld/gdb/testsuite/outputs/gdb.base/coref'.
Program terminated with signal SIGABRT, Aborted.
#0 0x00007f63dd658efb in raise () from /lib64/libc.so.6
(gdb) p coremaker_ro
$1 = 201
I.e. it prints the right answer, which sort of makes it seem like the
rest of the series isn't required.
Now, back to the patch itself... what should be the size of the memory
chunk placed before coremaker_ro?
It needs to be at least as big as the page size (PAGE_SIZE) from
the kernel. For x86 and several other architectures this value is
4096. I used MAPSIZE which is defined to be 8192 in coremaker.c.
So it's twice as big as what's currently needed for most Linux
architectures. The constant PAGE_SIZE is available from <sys/user.h>,
but this isn't portable either. In the end, it seemed simpler to
just pick a value and hope that it's big enough. (Running a separate
program which finds the page size via sysconf(_SC_PAGESIZE) and then
passes it to the compilation via a -D switch seemed like overkill
for a case which is rendered moot by recent linker versions.)
Further information can be found here:
https://sourceware.org/pipermail/gdb-patches/2020-May/168168.html
https://sourceware.org/pipermail/gdb-patches/2020-May/168170.html
Thanks to H.J. Lu for telling me about the '-z separate-code' linker
switch.
gdb/testsuite/ChangeLog:
* gdb.base/coremaker.c (filler_ro): New global constant.
|
|
-stack-list-arguments will crash when stopped in an Ada procedure that
has an argument with a certain name ("_objectO" -- which can only be
generated by the compiler). The bug occurs because lookup_symbol will
fail in this case.
This patch changes -stack-list-arguments to mirror what is done with
arguments elsewhere. (As an aside, I don't understand why this lookup
is even needed, but I assume it is some stabs thing?)
In the longer term I think it would be good to share this code between
MI and the CLI. However, due to the upcoming release, I preferred a
more local fix.
gdb/ChangeLog
2020-07-22 Tom Tromey <tromey@adacore.com>
* mi/mi-cmd-stack.c (list_args_or_locals): Use
lookup_symbol_search_name.
gdb/testsuite/ChangeLog
2020-07-22 Tom Tromey <tromey@adacore.com>
* gdb.ada/mi_prot.exp: New file.
* gdb.ada/mi_prot/pkg.adb: New file.
* gdb.ada/mi_prot/pkg.ads: New file.
* gdb.ada/mi_prot/prot.adb: New file.
|
|
The list of commands that a stub must implement was wrong.
gdb/ChangeLog:
2020-07-22 Reuben Thomas <rrt@sc3d.org>
* gdb.texinfo (Remote Protocol, Overview): Correct the description
of which remote protocol commands are mandatory for a stub to
implement.
|
|
Pedro's review comments arrived after I'd already committed this
change:
commit f7306dac19c502232f766c3881313857915f330d
Date: Tue Jul 7 15:00:30 2020 +0100
gdb/python: Reuse gdb.RegisterDescriptor objects where possible
See:
https://sourceware.org/pipermail/gdb-patches/2020-July/170726.html
There should be no user visible changes after this commit.
gdb/ChangeLog:
* python/py-registers.c (gdbpy_register_object_data_init): Remove
redundant local variable.
(gdbpy_get_register_descriptor): Extract descriptor vector as a
reference, not pointer, update code accordingly.
|
|
To detect whether an objfile is a JITer, we lookup JIT interface
symbols in the objfile. If an objfile does not have these symbols, we
conclude that it is not a JITer. An objfile that does not have the
symbols will never have them. Therefore, once we do a lookup and find
out that the objfile does not have JIT symbols, just set a flag so
that we can skip symbol lookup for that objfile the next time we reset
JIT breakpoints.
gdb/ChangeLog:
2020-07-22 Simon Marchi <simon.marchi@polymtl.ca>
Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* objfiles.h (struct objfile) <skip_jit_symbol_lookup>: New field.
* jit.c (jit_breakpoint_re_set_internal): Use the
`skip_jit_symbol_lookup` field.
|
|
gdb/ChangeLog:
2020-07-22 Simon Marchi <simon.marchi@polymtl.ca>
Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* jit.c (jit_read_descriptor): Define the descriptor address once,
use twice.
(jit_breakpoint_deleted): Move the declaration of the loop variable
`iter` into the loop header.
(jit_breakpoint_re_set_internal): Move the declaration of the local
variable `objf_data` to the first point of definition.
(jit_event_handler): Move the declaration of local variables
`code_entry`, `entry_addr`, and `objf` to their first point of use.
Rename `objf` to `jited`.
|
|
This is no longer needed, remove it.
gdb/ChangeLog:
2020-07-22 Simon Marchi <simon.marchi@polymtl.ca>
* jit.h (struct jiter_objfile_data) <jiter_objfile_data, objfile>:
Remove.
* jit.c (get_jiter_objfile_data): Update.
|
|
GDB's JIT handler stores an objfile (and data associated with it) per
program space to keep track of JIT breakpoint information. This assumes
that there is at most one JITer objfile in the program space. However,
there may be multiple. If so, only the first JITer's hook breakpoints
would be realized and the JIT events from the other JITers would be
missed.
This patch removes that assumption, allowing an arbitrary number of
objfiles within a program space to be JITers.
- The "unique" program_space -> JITer objfile pointer in
jit_program_space_data is removed. In fact, jit_program_space_data
becomes empty, so it is removed entirely.
- jit_breakpoint_deleted is modified, it now has to assume that any
objfile in a program space is a potential JITer. It now iterates on
all objfiles, checking if they are indeed JITers, and if they are,
whether the deleted breakpoint belongs to them.
- jit_breakpoint_re_set_internal also has to assume that any objfile in
a program space is a potential JITer. It creates (or updates) one
jiter_objfile_data structure for each JITer it finds.
- Same for jit_inferior_init. It now iterates all objfiles to read the
initial JIT object list.
gdb/ChangeLog:
2020-07-22 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
Simon Marchi <simon.marchi@polymtl.ca>
* jit.c (struct jit_program_space_data): Remove.
(jit_program_space_key): Remove.
(jiter_objfile_data::~jiter_objfile_data): Remove program space
stuff.
(get_jit_program_space_data): Remove.
(jit_breakpoint_deleted): Iterate on all of the program space's
objfiles.
(jit_inferior_init): Likewise.
(jit_breakpoint_re_set_internal): Likewise. Also change return
type to void.
(jit_breakpoint_re_set): Pass current_program_space to
jit_breakpoint_re_set_internal.
gdb/testsuite/ChangeLog:
2020-07-22 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.base/jit-reader-simple.exp: Add a scenario for a binary that
loads two JITers.
|
|
This is in preparation for allowing more than one JITer objfile per
program space. Once we do that, each JITer objfile will have its own
JIT breakpoint (on the __jit_debug_register_code function it provides).
The cached_code_address field is just the runtime / relocated address of
that symbol.
Since they are going to become JITer-objfile-specific and not
program-space-specific, move these fields from jit_program_space_data to
jiter_objfile_data.
gdb/ChangeLog:
2020-07-22 Simon Marchi <simon.marchi@polymtl.ca>
* jit.h (struct jiter_objfile_data) <cached_code_address,
jit_breakpoint>: Move to here from ...
* jit.c (jit_program_space_data): ... here.
(jiter_objfile_data::~jiter_objfile_data): Update.
(jit_breakpoint_deleted): Update.
(jit_breakpoint_re_set_internal): Update.
|
|
Following patch "gdb/jit: split jit_objfile_data in two", there are some
simplifications we can make. The invariants described there mean that
we can assume / assert some things instead of checking them using
conditionals.
If an instance of jiter_objfile_data exists for a given objfile, it's
because the required JIT interface symbols were found. Therefore, in
~jiter_objfile_data, the `register_code` field can't be NULL. It was
previously used to differentiate a jit_objfile_data object used for a
JITer vs a JITed. We can remove that check.
If an instance of jiter_objfile_data exists for a given objfile, it's
because it's the sole JITer objfile in the scope of its program space
(jit_program_space_data::objfile points to it). At the moment,
jit_breakpoint_re_set_internal won't create a second instance of
jiter_objfile_data for a given program space. Therefore, it's not
necessary to check for `ps_data != NULL` in ~jiter_objfile_data: we know
a jit_program_space_data for that program space exists. We also don't
need to check for `ps_data->objfile == this->objfile`, because we know
the objfile is the sole JITer in this program space. Replace these two
conditions with assertions.
A pre-condition for calling the jit_read_descriptor function (which is
respected in the two call sites) is that the objfile `jiter` _is_ a
JITer - it already has a jiter_objfile_data attached to it. When a
jiter_objfile_data exists, its `descriptor` field is necessarily set:
had the descriptor symbol not been found, jit_breakpoint_re_set_internal
would not have created the jiter_objfile_data. Remove the check and
early return in jit_read_descriptor. Access objfile's `jiter_data` field
directly instead of calling `get_jiter_objfile_data` (which creates the
jiter_objfile_data if it doesn't exist yet) and assert that the result
is not nullptr.
Finally, `jit_event_handler` is always passed a JITer objfile. So, add
an assertion to ensure that.
gdb/ChangeLog:
2020-07-22 Simon Marchi <simon.marchi@polymtl.ca>
* jit.c (jiter_objfile_data::~jiter_objfile_data): Remove some
checks.
(jit_read_descriptor): Remove NULL check.
(jit_event_handler): Add an assertion.
|
|
The jit_objfile_data is currently used to hold information about both
objfiles that are the result of JIT compilation (JITed) and objfiles
that can produce JITed objfiles (JITers). I think that this double use
of the type is confusing, and that things would be more obvious if we
had one type for each role.
This patch splits it into:
- jited_objfile_data: for data about an objfile that is the result of a
JIT compilation
- jiter_objfile_data: for data about an objfile which produces JITed
objfiles
There are now two JIT-related fields in an objfile, one for each kind.
With this change, the following invariants hold:
- an objfile has a non-null `jiter_data` field iff it defines the required
symbols of the JIT interface
- an objfile has a non-null `jited_data` field iff it is the product of
JIT compilation (has been produced by some JITer)
gdb/ChangeLog:
2020-07-22 Simon Marchi <simon.marchi@polymtl.ca>
* jit.h (struct jit_objfile_data): Split into...
(struct jiter_objfile_data): ... this ...
(struct jited_objfile_data): ... and this.
* objfiles.h (struct objfile) <jit_data>: Remove.
<jiter_data, jited_data>: New fields.
* jit.c (jit_objfile_data::~jit_objfile_data): Rename to ...
(jiter_objfile_data::~jiter_objfile_data): ... this.
(get_jit_objfile_data): Rename to ...
(get_jiter_objfile_data): ... this.
(add_objfile_entry): Update.
(jit_read_descriptor): Use get_jiter_objfile_data.
(jit_find_objf_with_entry_addr): Use objfile's jited_data field.
(jit_breakpoint_re_set_internal): Use get_jiter_objfile_data.
(jit_inferior_exit_hook): Use objfile's jited_data field.
|
|
Remove the use of objfile_data to associate a jit_objfile_data with an
objfile. Instead, directly link to a jit_objfile_data from an objfile
struct. The goal is to eliminate unnecessary abstraction.
The free_objfile_data function naturally becomes the destructor of
jit_objfile_data. However, free_objfile_data accesses the objfile to
which the data is attached, which the destructor of jit_objfile_data
doesn't have access to. To work around this, add a backlink to the
owning objfile in jit_objfile_data. This is however temporary, it goes
away in a subsequent patch.
gdb/ChangeLog:
2020-07-22 Simon Marchi <simon.marchi@polymtl.ca>
* jit.h: Forward-declare `struct minimal_symbol`.
(struct jit_objfile_data): Migrate to here from jit.c; also add a
constructor, destructor, and an objfile* field.
* jit.c (jit_objfile_data): Remove.
(struct jit_objfile_data): Migrate from here to jit.h.
(jit_objfile_data::~jit_objfile_data): New destructor
implementation with code moved from free_objfile_data.
(free_objfile_data): Delete.
(get_jit_objfile_data): Update to use the jit_data field of objfile.
(jit_find_objf_with_entry_addr): Ditto.
(jit_inferior_exit_hook): Ditto.
(_initialize_jit): Remove the call to
register_objfile_data_with_cleanup.
* objfiles.h (struct objfile) <jit_data>: New field.
|
|
This is a refactoring that adds a new parameter to the `jit_event_handler`
function: the JITer objfile. The goal is to distinguish which JITer
triggered the JIT event, in case there are multiple JITers -- a capability
that is added in a subsequent patch.
gdb/ChangeLog:
2020-07-22 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* jit.h: Forward-declare `struct objfile`.
(jit_event_handler): Add a second parameter, the JITer objfile.
* jit.c (jit_read_descriptor): Change the signature to take the
JITer objfile as an argument instead of the jit_program_space_data.
(jit_inferior_init): Update the call to jit_read_descriptor.
(jit_event_handler): Use the new JITer objfile argument when calling
jit_read_descriptor.
* breakpoint.c (handle_jit_event): Update the call to
jit_event_handler to pass the JITer objfile.
|
|
* gdbarch.c: Regenerate.
* gdbarch.h: Regenerate.
* gdbarch.sh (handle_segmentation_fault): Remove method.
* infrun.c (handle_segmentation_fault): Remove.
(print_signal_received_reason): Remove call to
handle_segmentation_fault.
|
|
gdb/ChangeLog:
* sparc64-linux-tdep.c (sparc64_linux_handle_segmentation_fault):
Rename to sparc64_linux_report_signal_info and add siggnal
argument.
(sparc64_linux_init_abi): Use sparc64_linux_report_signal_info
instead of sparc64_linux_handle_segmentation_fault.
|
|
gdb/ChangeLog:
* amd64-linux-tdep.c (amd64_linux_init_abi_common): Use
i386_linux_report_signal_info instead of
i386_linux_handle_segmentation_fault.
* i386-linux-tdep.c (i386_linux_handle_segmentation_fault): Rename
to i386_linux_report_signal_info and add siggnal argument.
(i386_linux_init_abi): Use i386_linux_report_signal_info instead
of i386_linux_handle_segmentation_fault.
* i386-linux-tdep.h (i386_linux_handle_segmentation_fault): Rename
to i386_linux_report_signal_info and add siggnal argument.
|
|
When opening a core file, if the process terminated due to a signal,
invoke the gdbarch report_signal_info hook to report
architecture-specific information about the signal.
gdb/ChangeLog:
* corelow.c (core_target_open): Invoke gdbarch report_signal_info
hook if present.
|
|
This is a more general version of the existing handle_segmentation_fault
hook that is able to report information for an arbitrary signal, not
just SIGSEGV.
gdb/ChangeLog:
* gdbarch.c: Regenerate.
* gdbarch.h: Regenerate.
* gdbarch.sh (report_signal_info): New method.
* infrun.c (print_signal_received_reason): Invoke gdbarch
report_signal_info hook if present.
|
|
Only create one gdb.RegisterGroup Python object for each of GDB's
reggroup objects.
I could have added a field into the reggroup object to hold the Python
object pointer for each reggroup, however, as reggroups are never
deleted within GDB, and are global (not per-architecture) a simpler
solution seemed to be just to hold a single global map from reggroup
pointer to a Python object representing the reggroup. Then we can
reuse the objects out of this map.
After this commit it is possible for a user to tell that two
gdb.RegisterGroup objects are now identical when previously they were
unique, however, as both these objects are read-only I don't think
this should be a problem.
There should be no other user visible changes after this commit.
gdb/ChangeLog:
* python/py-registers.c : Add 'unordered_map' include.
(gdbpy_new_reggroup): Renamed to...
(gdbpy_get_reggroup): ...this. Update to only create register
group descriptors when needed.
(gdbpy_reggroup_iter_next): Update.
gdb/testsuite/ChangeLog:
* gdb.python/py-arch-reg-groups.exp: Additional tests.
|
|
Instead of having the gdb.RegisterDescriptorIterator creating new
gdb.RegisterDescriptor objects for each regnum, instead cache
gdb.RegisterDescriptor objects on the gdbarch object and reuse these.
This means that for every gdbarch/regnum pair there is a single unique
gdb.RegisterDescriptor, this feels like a neater implementation than
the existing one.
It is possible for a user to see (in Python code) that the descriptors
are now identical, but as the descriptors are read-only this should
make no real difference.
There should be no other user visible changes.
gdb/ChangeLog:
* python/py-registers.c (gdbpy_register_object_data): New static
global.
(gdbpy_register_object_data_init): New function.
(gdbpy_new_register_descriptor): Renamed to...
(gdbpy_get_register_descriptor): ...this, and update to reuse
existing register descriptors where possible.
(gdbpy_register_descriptor_iter_next): Update.
(gdbpy_initialize_registers): Register new gdbarch data.
gdb/testsuite/ChangeLog:
* gdb.python/py-arch-reg-names.exp: Additional tests.
|
|
I noticed that my IDE was confusing the two stopped_pids variables.
There is one in GDB and one in GDBserver. They should be static, make
them so.
gdb/ChangeLog:
* linux-nat.c (stopped_pids): Make static.
gdbserver/ChangeLog:
* linux-low.cc (stopped_pids): Make static.
Change-Id: If4a2bdcd45d32eb3a732d266a0f686a4e4c23672
|
|
This patch fixes a failure in test `gdb.ada/access_to_packed_array.exp`.
The failure was introduced by 8c2e4e0689ea24 ("gdb: add accessors to
struct dynamic_prop"), but I think it in fact exposed a latent buglet.
Note that to reproduce it, I had to use AdaCore's Ada "distribution"
[1]. The one that comes with my distro doesn't have debug info for the
standard library stuff, so the bug wouldn't trigger.
The bug is that while executing the `maint print symbols` command, we
are accessing the value of a range type's high bound dynamic prop as a
"const" value (PROP_CONST), when it is actually undefined
(PROP_UNDEFINED). It results in this failed assertion:
/home/simark/src/binutils-gdb/gdb/gdbtypes.h:526: internal-error: LONGEST dynamic_prop::const_val() const: Assertion `m_kind == PROP_CONST' failed.
`ada_discrete_type_high_bound` calls `resolve_dynamic_type`, which
eventually calls `resolve_dynamic_range`. This one is responsible for
evaluating a range type's dynamic bounds in the current context and
returning static values. It returns a new range type with these static
bounds.
The resulting bounds are typically properties of the PROP_CONST kind.
But when it's not possible to evaluate the properties, the properties
are PROP_UNDEFINED. In the case we are looking at, it's not possible to
evaluate the dynamic high bound, which is of type PROP_LOCLIST. It
would require a target with registers and a frame, but we run `maint
print symbols` without a live process.
`ada_discrete_type_high_bound` then accesses the high bound
unconditionally as a const value, which triggers the assert.
Note that the previous code in resolve_dynamic_range (before commit
8c2e4e0689ea24) did this:
prop = &TYPE_RANGE_DATA (dyn_range_type)->high;
if (dwarf2_evaluate_property (prop, NULL, addr_stack, &value))
{
high_bound.kind = PROP_CONST;
high_bound.data.const_val = value;
if (TYPE_RANGE_DATA (dyn_range_type)->flag_upper_bound_is_count)
high_bound.data.const_val
= low_bound.data.const_val + high_bound.data.const_val - 1;
}
else
{
high_bound.kind = PROP_UNDEFINED;
high_bound.data.const_val = 0;
}
That did not really made sense, setting the kind to `PROP_UNDEFINED` but
also setting the `const_val` field. The `const_val` field is only
meaningful if the kind if `PROP_CONST`. The new code
(post-8c2e4e0689ea24) simply calls `set_undefined ()`.
Fix this by making the caller, `ada_discrete_type_high_bound`, consider
that a range high bound could be of kind `PROP_UNDEFINED`, and return
0 in this case. I made the same change in ada_discrete_type_low_bound.
I didn't encounter a problem with this function, but the same could in
theory happen there.
Returning 0 here is kind of a lie, but the goal here is just to restore
the behavior of pre-8c2e4e0689ea24.
The output of `maint print symbols` is:
typedef <ada__exceptions__exception_data__append_info_basic_exception_information__TTnameSP1: range 1 .. 0;
record
ada__exceptions__exception_data__append_info_basic_exception_information__TTnameSP1: range 1 .. 0;
end record;
Instead of `1 .. 0`, which does not make sense, we could say something
like `1 .. <dynamic>`. But that would require more changes than I'm
willing to do at the moment.
[1] https://www.adacore.com/download
gdb/ChangeLog:
PR ada/26235
* gdbtypes.c (ada_discrete_type_low_bound,
ada_discrete_type_high_bound): Handle undefined bounds.
Change-Id: Ia12167e61ef030941c0790f83294f3418e6a7c12
|
|
With gcc-8, we have the following FAILs, which are not there for gcc-7:
...
FAIL: gdb.reverse/solib-precsave.exp: reverse-step into solib function one
FAIL: gdb.reverse/solib-precsave.exp: reverse-step within solib function one
FAIL: gdb.reverse/solib-precsave.exp: reverse-step back to main one
FAIL: gdb.reverse/solib-precsave.exp: reverse-step into solib function two
FAIL: gdb.reverse/solib-precsave.exp: reverse-step within solib function two
FAIL: gdb.reverse/solib-precsave.exp: reverse-step back to main two
FAIL: gdb.reverse/solib-precsave.exp: run until end part two
FAIL: gdb.reverse/solib-precsave.exp: reverse-next over solib function one
FAIL: gdb.reverse/solib-reverse.exp: reverse-step into solib function one
FAIL: gdb.reverse/solib-reverse.exp: reverse-step within solib function one
FAIL: gdb.reverse/solib-reverse.exp: reverse-step back to main one
FAIL: gdb.reverse/solib-reverse.exp: reverse-step into solib function two
FAIL: gdb.reverse/solib-reverse.exp: reverse-step within solib function two
FAIL: gdb.reverse/solib-reverse.exp: reverse-step back to main two
FAIL: gdb.reverse/solib-reverse.exp: run until end part two
FAIL: gdb.reverse/solib-reverse.exp: reverse-next over solib function one
...
Looking at the first FAIL for gdb.reverse/solib-precsave.exp, we have:
...
(gdb) PASS: reverse-next first shr1
reverse-next^M
40 b[0] = 6; b[1] = 9; /* generic statement, end part two */^M
(gdb) PASS: reverse-next generic
reverse-step^M
-shr2 (x=17) at gdb.reverse/shr2.c:23^M
-23 }^M
-(gdb) PASS: reverse-step into solib function one
+38 b[1] = shr2(17); /* middle part two */^M
+(gdb) FAIL: reverse-step into solib function one
...
There's a difference in line number info for line 38, where for gcc-7 we have:
...
Line number Starting address View Stmt
38 0x4005c6 x
...
and for gcc-8:
...
38 0x4005c1 x
38 0x4005cb x
...
which explains why we don't step directly into "solib function one".
Fix this by recognizing the extra "recommended breakpoint location" and
issuing an additional reverse-next/step.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-07-21 Tom de Vries <tdevries@suse.de>
* gdb.reverse/solib-precsave.exp: Handle additional "recommended
breakpoint locations".
* gdb.reverse/solib-reverse.exp: Same.
|
|
The file gdb.reverse/step-reverse.c is used in test-cases:
- gdb.reverse/step-reverse.exp
- gdb.reverse/next-reverse-bkpt-over-sr.exp
- gdb.reverse/step-precsave.exp
With gcc-7, there are only PASSes (apart from one KFAIL), but with gcc-10, we
have the following FAILs:
...
FAIL: gdb.reverse/step-reverse.exp: reverse stepi from a function call \
(start statement)
FAIL: gdb.reverse/step-reverse.exp: simple reverse stepi
FAIL: gdb.reverse/step-reverse.exp: reverse step out of called fn
FAIL: gdb.reverse/step-reverse.exp: reverse next over call
FAIL: gdb.reverse/step-reverse.exp: reverse step test 1
FAIL: gdb.reverse/step-reverse.exp: reverse next test 1
FAIL: gdb.reverse/step-reverse.exp: reverse step test 2
FAIL: gdb.reverse/step-reverse.exp: reverse next test 2
FAIL: gdb.reverse/step-precsave.exp: reverse stepi from a function call \
(start statement)
FAIL: gdb.reverse/step-precsave.exp: simple reverse stepi
FAIL: gdb.reverse/step-precsave.exp: reverse step out of called fn
FAIL: gdb.reverse/step-precsave.exp: reverse next over call
FAIL: gdb.reverse/step-precsave.exp: reverse step test 1
FAIL: gdb.reverse/step-precsave.exp: reverse next test 1
FAIL: gdb.reverse/step-precsave.exp: reverse step test 2
FAIL: gdb.reverse/step-precsave.exp: reverse next test 2
...
Looking at the first step-precsave.exp FAIL, we have:
...
(gdb) stepi^M
26 myglob++; return 0; /* ARRIVED IN CALLEE */^M
(gdb) PASS: gdb.reverse/step-precsave.exp: reverse stepi thru function return
stepi^M
0x000000000040055f 26 myglob++; return 0; /* ARRIVED IN CALLEE */^M
(gdb) FAIL: gdb.reverse/step-precsave.exp: reverse stepi from a function call \
(start statement)
...
There's a difference in line info for callee:
...
25 int callee() { /* ENTER CALLEE */
26 myglob++; return 0; /* ARRIVED IN CALLEE */
27 } /* RETURN FROM CALLEE */
...
between gcc-7:
...
Line number Starting address View Stmt
25 0x400557 x
26 0x40055b x
27 0x40056f x
...
and gcc-10:
...
25 0x400552 x
26 0x400556 x
26 0x400565 x
27 0x40056a x
...
The two "recommend breakpoint location" entries at line 26 are for the two
statements ("myglob++" and "return 0"), but the test-case expects to hit line
26 only once.
Fix this by rewriting the two statements into a single statement:
...
- myglob++; return 0; /* ARRIVED IN CALLEE */
+ return myglob++; /* ARRIVED IN CALLEE */
...
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-07-21 Tom de Vries <tdevries@suse.de>
* gdb.reverse/step-reverse.c (callee): Merge statements.
|
|
This enables proper support for multiple inferiors and ptrace(2)
assisted management of the inferior processes and their threads.
(gdb) info inferior
Num Description Connection Executable
* 1 process 14952 1 (native) /usr/bin/dig
2 <null> 1 (native)
3 process 25684 1 (native) /bin/ls
4 <null> 1 (native) /bin/ls
Without this patch, additional inferiors can be added, but not
properly controlled.
gdb/ChangeLog:
* nbsd-nat.h (nbsd_nat_target::supports_multi_process): New
declaration.
* nbsd-nat.c (nbsd_nat_target::supports_multi_process): New
function.
|
|
When using test-case gdb.fortran/info-modules.exp with gcc 8.4.0, I run into:
...
FAIL: gdb.fortran/info-modules.exp: info module variables: check for entry \
'info-types.f90', '35', 'Type m1t1 mod1::__def_init_mod1_M1t1;'
FAIL: gdb.fortran/info-modules.exp: info module variables: check for entry \
'info-types.f90', '35', 'Type __vtype_mod1_M1t1 mod1::__vtab_mod1_M1t1;'
...
This is caused by this change in gdb output:
...
(gdb) info module variables
...
File gdb.fortran/info-types.f90:
-35: Type m1t1 mod1::__def_init_mod1_M1t1;
+ Type m1t1 mod1::__def_init_mod1_M1t1;
-35: Type __vtype_mod1_M1t1 mod1::__vtab_mod1_M1t1;
+ Type __vtype_mod1_M1t1 mod1::__vtab_mod1_M1t1;
21: real(kind=4) mod1::mod1_var_1;
22: integer(kind=4) mod1::mod1_var_2;
...
caused by a change in debug info.
Fix this by allowing those entries without line number.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-07-21 Tom de Vries <tdevries@suse.de>
* gdb.fortran/info-modules.exp (info module variables): Allow missing
line numbers for some variables.
|
|
When running testcase gdb.opt/inline-locals.exp on openSUSE Tumbleweed, I get:
...
(gdb) info locals^M
array = {0 <repeats 48 times>, 15775231, 0, 194, 0, -11497, 32767, 4199061, \
0, 0, 0, 0, 0, 4198992, 0, 4198432, 0}^M
(gdb) FAIL: gdb.opt/inline-locals.exp: info locals above bar 2
...
Fix this by:
- completely initializing array before printing any value
- updating the pattern to match "array = {0 <repeats 64 times>}"
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-07-21 Tom de Vries <tdevries@suse.de>
* gdb.opt/inline-locals.c (init_array): New func.
(func1): Use init_array.
* gdb.opt/inline-locals.exp: Update pattern.
|
|
Test-case gdb.debuginfod/fetch_src_and_symbols.exp leaks env vars
DEBUGINFOD_URLS, DEBUGINFOD_TIMEOUT and DEBUGINFOD_CACHE_PATH, causing
timeouts in subsequent tests.
Fix this by using save_vars. Also, fix PATH and DUPLICATE errors. Finally,
cleanup whitespace.
gdb/testsuite/ChangeLog:
2020-07-21 Tom de Vries <tdevries@suse.de>
* gdb.debuginfod/fetch_src_and_symbols.exp: Use save_vars for env
vars. Fix PATH and DUPLICATE errors. Cleanup whitespace.
|
|
The ELF runtime linker on all FreeBSD architectures uses the
"_rtld_bind" entry point for unresolved PTL entries. FreeBSD/mips has
an additional entry point called "_mips_rtld_bind".
gdb/ChangeLog:
* fbsd-tdep.c (fbsd_skip_solib_resolver): New function.
(fbsd_init_abi): Install gdbarch "skip_solib_resolver" method.
* fbsd-tdep.h (fbsd_skip_solib_resolver): New prototype.
* mips-fbsd-tdep.c (mips_fbsd_skip_solib_resolver): New function.
(mips_fbsd_init_abi): Install gdbarch "skip_solib_resolver"
method.
|
|
gdb/ChangeLog
2020-06-28 Ludovic Courtès <ludo@gnu.org>
* guile/scm-math.c (vlscm_integer_fits_p): Use 'uintmax_t'
and 'intmax_t' instead of 'scm_t_uintmax' and 'scm_t_intmax',
which are deprecated in Guile 3.0.
* configure.ac (try_guile_versions): Add "guile-3.0".
* configure (try_guile_versions): Regenerate.
* NEWS: Update entry.
gdb/testsuite/ChangeLog
2020-06-28 Ludovic Courtès <ludo@gnu.org>
* gdb.guile/source2.scm: Add #f first argument to 'format'.
* gdb.guile/types-module.exp: Remove "ERROR:" from
regexps since Guile 3.0 no longer prints that.
gdb/doc/ChangeLog
2020-06-28 Ludovic Courtès <ludo@gnu.org>
* doc/guile.texi (Guile Introduction): Mention Guile 3.0.
Change-Id: Iff116c2e40f334e4e0ca4e759a097bfd23634679
|
|
This primarily updates code that uses the I/O port API of Guile.
gdb/ChangeLog
2020-06-28 Ludovic Courtès <ludo@gnu.org>
Doug Evans <dje@google.com>
PR gdb/21104
* guile/scm-ports.c (USING_GUILE_BEFORE_2_2): New macro.
(ioscm_memory_port)[read_buf_size, write_buf_size]: Wrap in #if
USING_GUILE_BEFORE_2_2.
(stdio_port_desc, memory_port_desc) [!USING_GUILE_BEFORE_2_2]:
Change type to 'scm_t_port_type *'.
(natural_buffer_size) [!USING_GUILE_BEFORE_2_2]: New variable.
(ioscm_open_port) [USING_GUILE_BEFORE_2_2]: Add 'stream'
parameter and honor it. Update callers.
(ioscm_open_port) [!USING_GUILE_BEFORE_2_2]: New function.
(ioscm_read_from_port, ioscm_write) [!USING_GUILE_BEFORE_2_2]: New
functions.
(ioscm_fill_input, ioscm_input_waiting, ioscm_flush): Wrap in #if
USING_GUILE_BEFORE_2_2.
(ioscm_init_gdb_stdio_port) [!USING_GUILE_BEFORE_2_2]: Use
'ioscm_read_from_port'. Call 'scm_set_port_read_wait_fd'.
(ioscm_init_stdio_buffers) [!USING_GUILE_BEFORE_2_2]: New function.
(gdbscm_stdio_port_p) [!USING_GUILE_BEFORE_2_2]: Use 'SCM_PORTP'
and 'SCM_PORT_TYPE'.
(gdbscm_memory_port_end_input, gdbscm_memory_port_seek)
(ioscm_reinit_memory_port): Wrap in #if USING_GUILE_BEFORE_2_2.
(gdbscm_memory_port_read, gdbscm_memory_port_write)
(gdbscm_memory_port_seek, gdbscm_memory_port_close)
[!USING_GUILE_BEFORE_2_2]: New functions.
(gdbscm_memory_port_print): Remove use of 'SCM_PTOB_NAME'.
(ioscm_init_memory_port_type) [!USING_GUILE_BEFORE_2_2]: Use
'gdbscm_memory_port_read'.
Wrap 'scm_set_port_end_input', 'scm_set_port_flush', and
'scm_set_port_free' calls in #if USING_GUILE_BEFORE_2_2.
(gdbscm_get_natural_buffer_sizes) [!USING_GUILE_BEFORE_2_2]: New
function.
(ioscm_init_memory_port): Remove.
(ioscm_init_memory_port_stream): New function
(ioscm_init_memory_port_buffers) [USING_GUILE_BEFORE_2_2]: New
function.
(gdbscm_memory_port_read_buffer_size) [!USING_GUILE_BEFORE_2_2]:
Return scm_from_uint (0).
(gdbscm_set_memory_port_read_buffer_size_x)
[!USING_GUILE_BEFORE_2_2]: Call 'scm_setvbuf'.
(gdbscm_memory_port_write_buffer_size) [!USING_GUILE_BEFORE_2_2]:
Return scm_from_uint (0).
(gdbscm_set_memory_port_write_buffer_size_x)
[!USING_GUILE_BEFORE_2_2]: Call 'scm_setvbuf'.
* configure.ac (try_guile_versions): Add "guile-2.2".
* configure: Regenerate.
* NEWS: Add entry.
gdb/testsuite/ChangeLog
2020-06-28 Ludovic Courtès <ludo@gnu.org>
* gdb.guile/scm-error.exp ("source $remote_guile_file_1"): Relax
error regexp to match on Guile 2.2.
gdb/doc/ChangeLog
2020-06-28 Ludovic Courtès <ludo@gnu.org>
* guile.texi (Memory Ports in Guile): Mark
'memory-port-read-buffer-size',
'set-memory-port-read-buffer-size!',
'memory-port-write-buffer-size',
'set-memory-port-read-buffer-size!' as deprecated.
* doc/guile.texi (Guile Introduction): Clarify which Guile
versions are supported.
Change-Id: Ib119b10a2787446e0ae482a5e1b36d809c44bb31
|
|
As an extension, GCC allows void pointer arithmetic, with sizeof(void)
and alignof(void) both 1. GDB supports this extension, but clang does
not, and fails to compile the generated output of gdb.cp/align.exp
with the following error:
gdb compile failed, /gdbtest/build/gdb/testsuite/outputs/gdb.cp/align/align.cc:28:23:
error: invalid application of 'alignof' to an incomplete type 'void'
unsigned a_void = alignof (void);
^ ~~~~~~
1 error generated.
This commit adds preprocessor conditionals to the generated output, to
omit the unsupported code when using clang, and supplies the expected
value so the test can complete.
gdb/testsuite/ChangeLog:
* gdb.cp/align.exp: Fix "alignof (void)" tests when compiling
with clang.
|
|
In openmp test-case gdb.threads/omp-par-scope.exp we xfail and kfail dependent
on omp_get_thread_num (). Since execution order of the threads can vary from
execution to execution, this can cause changes in test results.
F.i., we can see this difference between two test runs:
...
-KFAIL: single_scope: first thread: print i3 (PRMS: gdb/22214)
+PASS: single_scope: first thread: print i3
-PASS: single_scope: second thread: print i3
+KFAIL: single_scope: second thread: print i3 (PRMS: gdb/22214)
...
In both cases, the KFAIL is for omp_get_thread_num () == 1, but in one case
that corresponds to the first thread executing that bit of code, and in the
other case to the second thread.
Get rid of this difference by stabilizing execution order.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-07-20 Tom de Vries <tdevries@suse.de>
* gdb.threads/omp-par-scope.c (lock, lock2): New variable.
(omp_set_lock_in_order): New function.
(single_scope, multi_scope, nested_func, nested_parallel): Use
omp_set_lock_in_order and omp_unset_lock.
(main): Init and destroy lock and lock2.
|
|
When running test-case gdb.base/valgrind-infcall-2.exp on a system without
libc debug info installed, I run into:
...
(gdb) p printf ("bla")^M
'printf' has unknown return type; cast the call to its declared return type^M
(gdb) FAIL: gdb.base/valgrind-infcall-2.exp: do printf
...
Fix this by casting the result of the printf call to int.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-07-20 Tom de Vries <tdevries@suse.de>
* gdb.base/valgrind-infcall-2.exp: Handle printf unknown return type.
|
|
gdb.threads/attach-slow-waitpid.exp
When building gdb using CFLAGS/CXXFLAGS+=-fsanitizer=address and
LDFLAGS+=-lasan, and running test-case gdb.threads/attach-slow-waitpid.exp,
we get:
...
spawn gdb -nw -nx -data-directory data-directory^M
==16079==ASan runtime does not come first in initial library list; \
you should either link runtime to your application or manually preload \
it with LD_PRELOAD.^M
ERROR: (eof) GDB never initialized.
ERROR: : spawn id exp10 not open
while executing
"expect {
-i exp10 -timeout 120
-re "Kill the program being debugged. .y or n. $" {
send_gdb "y\n" answer
verbose "\t\tKilling previous pro..."
("uplevel" body line 1)
invoked from within
"uplevel $body" NONE : spawn id exp10 not open
WARNING: remote_expect statement without a default case
ERROR: : spawn id exp10 not open
while executing
"expect {
-i exp10 -timeout 120
-re "Reading symbols from.*LZMA support was disabled.*$gdb_prompt $" {
verbose "\t\tLoaded $arg into $GDB; .gnu_..."
("uplevel" body line 1)
invoked from within
"uplevel $body" NONE : spawn id exp10 not open
ERROR: Couldn't load attach-slow-waitpid into GDB (eof).
ERROR: Couldn't send attach 16070 to GDB.
UNRESOLVED: gdb.threads/attach-slow-waitpid.exp: attach to target
...
Bail out at the first ERROR, such that we have instead:
...
ERROR: (eof) GDB never initialized.
UNTESTED: gdb.threads/attach-slow-waitpid.exp: \
Couldn't start GDB with preloaded lib
...
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-07-20 Tom de Vries <tdevries@suse.de>
* gdb.threads/attach-slow-waitpid.exp: Bail out if gdb_start fails.
|
|
The "linux_multi_process" is initialized but never modified. I
discussed this with Pedro on irc, and he said that, while it was
useful when developing this feature, it is now no longer needed. So,
this removes it.
gdb/ChangeLog
2020-07-18 Tom Tromey <tom@tromey.com>
* linux-nat.c (linux_multi_process): Remove.
(linux_nat_target::supports_multi_process): Return true.
|
|
It was pointed out on IRC that the RISC-V target allocates target
descriptions and stores them in a global map, and doesn't delete these
target descriptions when GDB shuts down.
This isn't a particular problem, the total number of target
descriptions we can create is very limited so creating these on demand
and holding them for the entire run on GDB seems reasonable.
However, not deleting these objects on GDB exit means extra warnings
are printed from tools like valgrind, and the address sanitiser,
making it harder to spot real issues. As it's reasonably easy to have
GDB correctly delete these objects on exit, lets just do that.
I started by noticing that we already have a target_desc_up type, a
wrapper around unique_ptr that calls a function that will correctly
delete target descriptions, so I want to use that, but....
...that type is declared in gdb/target-descriptions.h. If I try to
include that file in gdb/arch/riscv.c I run into a problem, that file
is compiled into both GDB and GDBServer.
OK, I could guard the include with #ifdef, but surely we can do
better.
So then I decided to move the target_desc_up type into
gdbsupport/tdesc.h, this is the interface file for generic code shared
between GDB and GDBserver (relating to target descriptions). The
actual implementation for the delete function still lives in
gdb/target-description.c, but now gdb/arch/riscv.c can see the
declaration. Problem solved....
... but, though RISC-V doesn't use it I've now exposed the
target_desc_up type to gdbserver, so in future someone _might_ start
using it, which is fine, except right now there's no definition of the
delete function - remember the delete I used is only defined in GDB
code.
No problem, I add an implementation of the delete operator into
gdbserver/tdesc.cc, and all is good..... except....
I start getting this error from GCC:
tdesc.cc:109:10: error: deleting object of polymorphic class type ‘target_desc’ which has non-virtual destructor might cause undefined behavior [-Werror=delete-non-virtual-dtor]
Which is caused because gdbserver's target_desc type inherits from
tdesc_element which has a virtual method, and so GCC worries that
target_desc might be used as a base class.
The solution is to declare gdbserver's target_desc class as final.
This is fine so long as we never intent to inherit from
target_desc (in gdbserver). But if we did then we'd want to make
target_desc's destructor virtual anyway, so the error above would be
resolved, and there wouldn't be an issue.
gdb/ChangeLog:
* arch/riscv.c (riscv_tdesc_cache): Change map type.
(riscv_lookup_target_description): Return pointer out of
unique_ptr.
* target-descriptions.c (allocate_target_description): Add
comment.
(target_desc_deleter::operator()): Likewise.
* target-descriptions.h (struct target_desc_deleter): Moved to
gdbsupport/tdesc.h.
(target_desc_up): Likewise.
gdbserver/ChangeLog:
* tdesc.cc (allocate_target_description): Add header comment.
(target_desc_deleter::operator()): New function.
* tdesc.h (struct target_desc): Declare as final.
gdbsupport/ChangeLog:
* tdesc.h (struct target_desc_deleter): Moved here
from gdb/target-descriptions.h, extend comment.
(target_desc_up): Likewise.
|
|
In commit ee3c5f8968 "Fix GDB crash when registers cannot be modified", we
fix a GDB crash:
...
$ valgrind /usr/bin/sleep 10000
==31595== Memcheck, a memory error detector
==31595== Command: /usr/bin/sleep 10000
==31595==
$ gdb /usr/bin/sleep
(gdb) target remote | vgdb --pid=31595
Remote debugging using | vgdb --pid=31595
...
$hex in __GI___nanosleep () at nanosleep.c:27
27 return SYSCALL_CANCEL (nanosleep, requested_time, remaining);
(gdb) p printf ("bla")
terminate called after throwing an instance of 'gdb_exception_error'
Aborted (core dumped)
...
This patch adds a test-case for it.
Unfortunately, I was not able to trigger the error condition using a regular
vgdb_start, so I've added a parameter active_at_startup, and when set to 0
this causes valgrind to be started without --vgdb-error=0.
Tested on x86_64-linux.
Tested with the commit mentioned above reverted, resulting in:
...
(gdb) p printf ("bla")^M
terminate called after throwing an instance of 'gdb_exception_error'^M
ERROR: GDB process no longer exists
GDB process exited with wait status 6152 exp10 0 0 CHILDKILLED SIGABRT SIGABRT
UNRESOLVED: gdb.base/valgrind-infcall-2.exp: do printf
...
gdb/testsuite/ChangeLog:
2020-07-17 Tom de Vries <tdevries@suse.de>
* gdb.base/valgrind-infcall-2.c: New test.
* gdb.base/valgrind-infcall-2.exp: New file.
* lib/valgrind.exp (vgdb_start): Add and handle active_at_startup.
|
|
I noticed a couple of spots in linux-nat.c that use 0/1 where boolean
literals would be more idiomatic. This patch makes this change.
gdb/ChangeLog
2020-07-17 Tom Tromey <tromey@adacore.com>
* linux-nat.c (linux_nat_target::supports_non_stop)
(linux_nat_target::always_non_stop_p): Use "true".
(linux_nat_target::supports_disable_randomization): Use "true" and
"false".
|
|
Use dwarf assembly procs MACRO_AT_func and MACRO_AT_range in test-cases where
that's appropriate.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-07-17 Tom de Vries <tdevries@suse.de>
* gdb.dlang/circular.c (found): Use found_label as label name.
* gdb.dwarf2/arr-subrange.c (main): Use main_label as label name.
* gdb.dwarf2/comp-unit-lang.c (func): Use func_label as label name.
* gdb.dlang/circular.exp: Use MACRO_AT_func and MACRO_AT_range.
* gdb.dwarf2/ada-linkage-name.exp: Same.
* gdb.dwarf2/arr-subrange.exp: Same.
* gdb.dwarf2/atomic-type.exp: Same.
* gdb.dwarf2/comp-unit-lang.exp: Same.
* gdb.dwarf2/cpp-linkage-name.exp: Same.
* gdb.dwarf2/dw2-bad-mips-linkage-name.exp: Same.
* gdb.dwarf2/dw2-lexical-block-bare.exp: Same.
* gdb.dwarf2/dw2-regno-invalid.exp: Same.
* gdb.dwarf2/implptr-64bit.exp: Same.
* gdb.dwarf2/imported-unit-abstract-const-value.exp: Same.
* gdb.dwarf2/imported-unit-runto-main.exp: Same.
* gdb.dwarf2/imported-unit.exp: Same.
* gdb.dwarf2/main-subprogram.exp: Same.
* gdb.dwarf2/missing-type-name.exp: Same.
* gdb.dwarf2/nonvar-access.exp: Same.
* gdb.dwarf2/struct-with-sig.exp: Same.
* gdb.dwarf2/typedef-void-finish.exp: Same.
* gdb.dwarf2/void-type.exp: Same.
|
|
The dwarf assembly procs MACRO_AT_func and MACRO_AT_range have a src
parameter, which is set to $srcdir/$subdir/$srcfile in every single call.
Drop the src parameter and hardcode usage of $srcdir/$subdir/$srcfile in the
procs.
Build and reg-tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-07-17 Tom de Vries <tdevries@suse.de>
* lib/dwarf.exp (Dwarf::MACRO_AT_func, Dwarf::MACRO_AT_range): Drop
src parameter.
* gdb.dlang/watch-loc.exp: Update MACRO_AT_{func,range} calls.
* gdb.dwarf2/bitfield-parent-optimized-out.exp: Same.
* gdb.dwarf2/dw2-ifort-parameter.exp: Same.
* gdb.dwarf2/dw2-opt-structptr.exp: Same.
* gdb.dwarf2/dwz.exp: Same.
* gdb.dwarf2/implptr-optimized-out.exp: Same.
* gdb.dwarf2/implref-array.exp: Same.
* gdb.dwarf2/implref-const.exp: Same.
* gdb.dwarf2/implref-global.exp: Same.
* gdb.dwarf2/implref-struct.exp: Same.
* gdb.dwarf2/info-locals-optimized-out.exp: Same.
* gdb.dwarf2/opaque-type-lookup.exp: Same.
* gdb.dwarf2/var-access.exp: Same.
* gdb.dwarf2/varval.exp: Same.
* gdb.trace/entry-values.exp: Same.
|
