| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Fix build problem when configuring with guile.
Fix the forgotten copy of ChangeLog info to ChangeLog.
|
|
'thread|frame apply CMD' launches CMD so that CMD output goes to a string_file.
This patch ensures that string_file for such CMD output contains
style escape sequences that 'thread|frame apply' will later on
output on the real terminal, so as to have CMD output properly styled.
The idea is to have the class ui_file having overridable methods
to indicate that the output to this ui_file should be done using
'terminal' behaviour such as styling.
Then these methods are overriden in string_file so that a specially
constructed string_file will get output with style escape sequences.
After this patch, the output of CMD by thread|frame apply CMD is styled
similarly as when CMD is launched directly.
Note that string_file (term_out true) could also support wrapping,
but this is not done (yet?).
Tested on debian/amd64.
gdb/ChangeLog
2019-04-27 Philippe Waroquiers <philippe.waroquiers@skynet.be>
Support style in 'frame|thread apply'
* gdbcmd.h (execute_command_to_string): New term_out parameter.
* record.c (record_start, record_stop): Update callers of
execute_command_to_string with false.
* ui-file.h (class ui_file): New term_out and can_emit_style_escape
methods.
(class string_file): New constructor with term_out parameter.
Override methods term_out and can_emit_style_escape. New member
term_out.
(class stdio_file): Override can_emit_style_escape.
(class tee_file): Override term_out and can_emit_style_escape.
* utils.h (can_emit_style_escape): Remove.
* utils.c (can_emit_style_escape): Likewise.
Update all callers of can_emit_style_escape (SOMESTREAM) to
SOMESTREAM->can_emit_style_escape.
* source-cache.c (source_cache::get_source_lines): Likewise.
* stack.c (frame_apply_command_count): Call execute_command_to_string
passing the term_out characteristic of the current gdb_stdout.
* thread.c (thr_try_catch_cmd): Likewise.
* top.c (execute_command_to_string): pass term_out parameter
to construct the string_file for the command output.
* ui-file.c (term_cli_styling): New function (most code moved
from utils.c can_emit_style_escape).
(string_file::string_file, string_file::can_emit_style_escape,
stdio_file::can_emit_style_escape, tee_file::term_out,
tee_file::can_emit_style_escape): New functions.
|
|
Inferior function calls are powerful but might lead to undesired
results such as crashes when calling nested functions (frequently
used in particular in Ada).
This implements a GDB setting to disable calling inferior functions.
Note: the idea is that if/when the 'slash command' patch is pushed,
that this setting can be changed e.g. by using the shortcut /c.
This is version 2 of the patch. It handles all the received comments,
mostly replace 'can-call' by 'may-call', and avoid using
'inferior function call' in factor of 'calling function in the program'.
2019-04-26 Philippe Waroquiers <philippe.waroquiers@skynet.be>
gdb/ChangeLog
* NEWS: Mention the new set|show may-call-functions.
* infcall.c (may_call_functions_p): New variable.
(show_may_call_functions_p): New function.
(call_function_by_hand_dummy): Throws an error if not
may-call-functions.
(_initialize_infcall): Call add_setshow_boolean_cmd for
may-call-functions.
gdb/testsuite/ChangeLog
* gdb.base/callexit.exp: Test may-call-functions off.
gdb/doc/ChangeLog
* gdb.texinfo (Calling): Document the new
set|show may-call-functions.
|
|
This bug finds another usage where we end up segfaulting while
normalizing user input. inspect_type and replace_type recurse,
attempting to substitute the "real" symbol name for the typedef name.
However, since the both these names are the same, they keep calling
each other until the stack overflows.
A simple reproducer for it is given by
typedef struct foo foo;
int qux (foo *f) { return 0; }
(gdb) b qux(foo*)
Segmentation fault
inspect_type already contains some special handling to prevent a
similar situation from occurring with namespaces. I wonder, however,
whether we need be so pedantic about the exact nature of the substitution.
This patch implements this rather more aggressive assumption that these
substitutions should be avoided whenever the replacement symbol's name is
exactly the same as the one we're trying to substitute. [In the above
example, we're trying to substitute the tyepdef named "foo" with the symbol
named "foo" (a struct).]
gdb/ChangeLog:
PR c++/24367
* cp-support.c (inspect_type): Don't attempt substitutions
of symbol with the same name.
gdb/testsuite/ChangeLog:
PR c++/24367
* gdb.cp/meth-typedefs.cc (incomplete_struct)
(another_incomplete_struct, test_incomplete): New definitions.
(main): Use new definitions.
* gdb.cp/meth-typedefs.exp: Add new tests for `test_incomplete'
functions.
|
|
PR gdb/24475 concerns a memory leak coming from gdb's exception
handling code.
The leak occurs because throw_exception_sjlj does not arrange to
destroy the exception object it is passed. However, because
gdb_exception has a destructor, it's undefined to longjmp in this
situation.
This patch fixes the problem by avoiding the need to run any
destructors in gdb_rl_callback_handler, by making the gdb_exception
"static".
gdb/ChangeLog
2019-04-25 Tom Tromey <tromey@adacore.com>
PR gdb/24475:
* event-top.c (gdb_rl_callback_handler): Make "gdb_rl_expt"
static.
|
|
This makes exception handling more efficient in a few spots, through
the use of const- and rvalue-references.
I wrote this patch by commenting out the gdb_exception copy
constructor and then examining the resulting error messages one by
one, introducing the use of std::move where appropriate.
gdb/ChangeLog
2019-04-25 Tom Tromey <tromey@adacore.com>
* xml-support.c (struct gdb_xml_parser) <set_error>: Take an
rvalue reference.
(gdb_xml_start_element_wrapper, gdb_xml_end_element_wrapper)
(gdb_xml_parser::parse): Use std::move.
* python/python-internal.h (gdbpy_convert_exception): Take a const
reference.
* python/py-value.c (valpy_getitem, valpy_nonzero): Use
std::move.
* python/py-utils.c (gdbpy_convert_exception): Take a const
reference.
* python/py-inferior.c (infpy_write_memory, infpy_search_memory):
Use std::move.
* python/py-breakpoint.c (bppy_set_condition, bppy_set_commands):
Use std::move.
* mi/mi-main.c (mi_print_exception): Take a const reference.
* main.c (handle_command_errors): Take a const reference.
* linespec.c (parse_linespec): Use std::move.
* infcall.c (run_inferior_call): Use std::move.
(call_function_by_hand_dummy): Use std::move.
* exec.c (try_open_exec_file): Use std::move.
* exceptions.h (exception_print, exception_fprintf)
(exception_print_same): Update.
* exceptions.c (print_exception, exception_print)
(exception_fprintf, exception_print_same): Change parameters to
const reference.
* event-top.c (gdb_rl_callback_read_char_wrapper): Update.
* common/new-op.c: Use std::move.
* common/common-exceptions.h (struct gdb_exception): Add move
constructor.
(struct gdb_exception_error, struct gdb_exception_quit, struct
gdb_quit_bad_alloc): Change constructor to move constructor.
(throw_exception): Change parameter to rvalue reference.
* common/common-exceptions.c (throw_exception): Take rvalue
reference.
* cli/cli-interp.c (safe_execute_command): Use std::move.
* breakpoint.c (insert_bp_location, location_to_sals): Use
std::move.
|
|
The Guile code will longjmp (via scm_throw) when an object requiring
destruction is on the stack. This is undefined behavior.
This changes this code to run any destructors in inner scopes, and to
pass a POD to gdbscm_throw_gdb_exception.
gdb/ChangeLog
2019-04-25 Tom Tromey <tromey@adacore.com>
* guile/scm-exception.c (gdbscm_scm_from_gdb_exception)
(gdbscm_throw_gdb_exception): Take a gdbscm_gdb_exception.
* guile/scm-block.c, guile/scm-breakpoint.c, guile/scm-cmd.c,
guile/scm-disasm.c, guile/scm-frame.c, guile/scm-lazy-string.c,
guile/scm-math.c, guile/scm-param.c, guile/scm-ports.c,
guile/scm-symbol.c, guile/scm-symtab.c, guile/scm-type.c,
guile/scm-value.c: Use unpack.
* guile/guile-internal.h (gdbscm_scm_from_gdb_exception): Take a
gdbscm_gdb_exception.
(gdbscm_throw_gdb_exception): Likewise.
(struct gdbscm_gdb_exception): New.
(unpack): New function.
(gdbscm_wrap): Use unpack.
|
|
This changes the SJLJ exception handling code to be a bit more
efficient, by using rvalue references and move assignment when
possible.
Tested by the buildbot.
gdb/ChangeLog
2019-04-25 Tom Tromey <tromey@adacore.com>
* event-top.c (gdb_rl_callback_read_char_wrapper_noexcept)
(gdb_rl_callback_handler): Use std::move.
* common/common-exceptions.h (struct gdb_exception): Add move
assignment operator.
(throw_exception_sjlj): Change "exception" to const reference.
* common/common-exceptions.c (exceptions_state_mc_catch): Update.
(throw_exception_sjlj): Change "exception" to const reference.
|
|
Now that gdb_exception has a constructor, there's no need for
exception_none. This patch removes it.
gdb/ChangeLog
2019-04-25 Tom Tromey <tromey@adacore.com>
* xml-support.c (gdb_xml_parser::gdb_xml_parser): Update.
* python/py-value.c (valpy_getitem, valpy_nonzero): Update.
* python/py-inferior.c (infpy_write_memory, infpy_search_memory):
Update.
* python/py-breakpoint.c (bppy_set_condition, bppy_set_commands):
Update.
* mi/mi-interp.c (mi_interp::exec): Update.
* linespec.c (parse_linespec): Update.
* infcall.c (run_inferior_call): Update.
* guile/scm-value.c (gdbscm_value_to_lazy_string): Update.
* guile/scm-symbol.c (gdbscm_lookup_symbol)
(gdbscm_lookup_global_symbol): Update.
* guile/scm-param.c (gdbscm_parameter_value): Update.
* guile/scm-frame.c (gdbscm_frame_read_register)
(gdbscm_frame_read_var): Update.
* guile/scm-breakpoint.c (gdbscm_register_breakpoint_x): Update.
* exec.c (try_open_exec_file): Update.
* event-top.c (gdb_rl_callback_read_char_wrapper_noexcept)
(gdb_rl_callback_handler): Update.
* common/common-exceptions.h (exception_none): Don't declare.
* common/common-exceptions.c (exception_none): Don't define.
(struct catcher) <exception>: Update.
* cli/cli-interp.c (safe_execute_command): Update.
* breakpoint.c (insert_bp_location, location_to_sals): Update.
|
|
DW_FORM_strx is the new name of DW_FORM_GNU_str_index in the Dwarf 5 standard.
This is a small step towards supporting Dwarf 5 in gdb.
|
|
I forgot to include the ChangeLog entries in the commit
57e5e645010430b3d73f8c6a757d09f48dc8f8d5 ("Implement dump of mappings
with ELF headers by gcore").
|
|
This patch has a long story, but it all started back in 2015, with
commit df8411da087dc05481926f4c4a82deabc5bc3859 ("Implement support
for checking /proc/PID/coredump_filter"). The purpose of that commit
was to bring GDB's corefile generation closer to what the Linux kernel
does. However, back then, I did not implement the full support for
the dumping of memory mappings containing ELF headers (like mappings
of DSOs or executables). These mappings were being dumped most of
time, though, because the default value of /proc/PID/coredump_filter
is 0x33, which would cause anonymous private mappings (DSOs/executable
code mappings have this type) to be dumped. Well, until something
happened on binutils...
A while ago, I noticed something strange was happening with one of our
local testcases on Fedora GDB: it was failing due to some strange
build-id problem. On Fedora GDB, we (unfortunately) carry a bunch of
"local" patches, and some of these patches actually extend upstream's
build-id support in order to generate more useful information for the
user of a Fedora system (for example, when the user loads a corefile
into GDB, we detect whether the executable that generated that
corefile is present, and if it's not we issue a warning suggesting
that it should be installed, while also providing the build-id of the
executable). A while ago, Fedora GDB stopped printing those warnings.
I wanted to investigate this right away, and spent some time trying to
determine what was going on, but other things happened and I got
sidetracked. Meanwhile, the bug started to be noticed by some of our
users, and its priority started changing. Then, someone on IRC also
mentioned the problem, and when I tried helping him, I noticed he
wasn't running Fedora. Hm... So maybe the bug was *also* present
upstream.
After "some" time investigating, and with a lot of help from Keith and
others, I was finally able to determine that yes, the bug is also
present upstream, and that even though it started with a change in ld,
it is indeed a GDB issue.
So, as I said, the problem started with binutils, more specifically
after the following commit was pushed:
commit f6aec96dce1ddbd8961a3aa8a2925db2021719bb
Author: H.J. Lu <hjl.tools@gmail.com>
Date: Tue Feb 27 11:34:20 2018 -0800
ld: Add --enable-separate-code
This commit makes ld use "-z separate-code" by default on x86-64
machines. What this means is that code pages and data pages are now
separated in the binary, which is confusing GDB when it tries to decide
what to dump.
BTW, Fedora 28 binutils doesn't have this code, which means that
Fedora 28 GDB doesn't have the problem. From Fedora 29 on, binutils
was rebased and incorporated the commit above, which started causing
Fedora GDB to fail.
Anyway, the first thing I tried was to pass "-z max-page-size" and
specify a bigger page size (I saw a patch that did this and was
proposed to Linux, so I thought it might help). Obviously, this
didn't work, because the real "problem" is that ld will always use
separate pages for code and data. So I decided to look into how GDB
dumped the pages, and that's where I found the real issue.
What happens is that, because of "-z separate-code", the first two pages
of the ELF binary are (from /proc/PID/smaps):
00400000-00401000 r--p 00000000 fc:01 799548 /file
Size: 4 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Rss: 4 kB
Pss: 4 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 4 kB
Private_Dirty: 0 kB
Referenced: 4 kB
Anonymous: 0 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
Locked: 0 kB
THPeligible: 0
VmFlags: rd mr mw me dw sd
00401000-00402000 r-xp 00001000 fc:01 799548 /file
Size: 4 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Rss: 4 kB
Pss: 4 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 4 kB
Referenced: 4 kB
Anonymous: 4 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
Locked: 0 kB
THPeligible: 0
VmFlags: rd ex mr mw me dw sd
Whereas before, we had only one:
00400000-00401000 r-xp 00000000 fc:01 798593 /file
Size: 4 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Rss: 4 kB
Pss: 4 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 4 kB
Referenced: 4 kB
Anonymous: 4 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
Locked: 0 kB
THPeligible: 0
VmFlags: rd ex mr mw me dw sd
Notice how we have "Anonymous" data mapped into the page. This will be
important.
So, the way GDB decides which pages it should dump has been revamped
by my patch in 2015, and now it takes the contents of
/proc/PID/coredump_filter into account. The default value for Linux
is 0x33, which means:
Dump anonymous private, anonymous shared, ELF headers and HugeTLB
private pages.
Or:
filter_flags filterflags = (COREFILTER_ANON_PRIVATE
| COREFILTER_ANON_SHARED
| COREFILTER_ELF_HEADERS
| COREFILTER_HUGETLB_PRIVATE);
Now, it is important to keep in mind that GDB doesn't always have *all*
of the necessary information to exactly determine the type of a page, so
the whole algorithm is based on heuristics (you can take a look at
linux-tdep.c:dump_mapping_p and
linux-tdep.c:linux_find_memory_regions_full for more info).
Before the patch to make ld use "-z separate-code", the (single) page
containing data and code was being flagged as an anonymous (due to the
non-zero "Anonymous:" field) private (due to the "r-xp" permission),
which means that it was being dumped into the corefile. That's why it
was working fine.
Now, as you can imagine, when "-z separate-code" is used, the *data*
page (which is where the ELF notes are, including the build-id one) now
doesn't have any "Anonymous:" mapping, so the heuristic is flagging it
as file-backed private, which is *not* dumped by default.
The next question I had to answer was: how come a corefile generated by
the Linux kernel was correct? Well, the answer is that GDB, unlike
Linux, doesn't actually implement the COREFILTER_ELF_HEADERS support.
On Linux, even though the data page is also treated as a file-backed
private mapping, it is also checked to see if there are any ELF headers
in the page, and then, because we *do* have ELF headers there, it is
dumped.
So, after more time trying to think of ways to fix this, I was able to
implement an algorithm that reads the first few bytes of the memory
mapping being processed, and checks to see if the ELF magic code is
present. This is basically what Linux does as well, except that, if
it finds the ELF magic code, it just dumps one page to the corefile,
whereas GDB will dump the whole mapping. But I don't think that's a
big issue, to be honest.
It's also important to explain that we *only* perform the ELF magic
code check if:
- The algorithm has decided *not* to dump the mapping so far, and;
- The mapping is private, and;
- The mapping's offset is zero, and;
- The user has requested us to dump mappings with ELF headers.
IOW, we're not going to blindly check every mapping.
As for the testcase, I struggled even more trying to write it. Since
our build-id support on upstream GDB is not very extensive, it's not
really possible to determine whether a corefile contains build-id
information or not just by using GDB. So, after thinking a lot about
the problem, I decided to rely on an external tool, eu-unstrip, in
order to verify whether the dump was successful. I verified the test
here on my machine, and everything seems to work as expected (i.e., it
fails without the patch, and works with the patch applied). We are
working hard to upstream our "local" Fedora GDB patches, and we intend
to submit our build-id extension patches "soon", so hopefully we'll be
able to use GDB itself to perform this verification.
I built and regtested this on the BuildBot, and no problems were
found.
gdb/ChangeLog:
2019-04-25 Sergio Durigan Junior <sergiodj@redhat.com>
PR corefiles/11608
PR corefiles/18187
* linux-tdep.c (dump_mapping_p): Add new parameters ADDR and
OFFSET. Verify if current mapping contains an ELF header.
(linux_find_memory_regions_full): Adjust call to
dump_mapping_p.
gdb/testsuite/ChangeLog:
2019-04-25 Sergio Durigan Junior <sergiodj@redhat.com>
PR corefiles/11608
PR corefiles/18187
* gdb.base/coredump-filter-build-id.exp: New file.
|
|
Add both board option and environment variable which enables gdbserver
debug and sends it to the file gdbserver.debug, located in the output
directory for the current test. Document this.
Add support for the environment variable in the Makefile.
The testsuite can be run with gdbserver debug enabled in the following way:
make check GDBSERVER_DEBUG=all
Disable tspeed.exp when debugging to prevent the log file filling
many gigabytes then timing out.
gdb/testsuite/ChangeLog:
* Makefile.in: Pass through GDBSERVER_DEBUG.
* README (Testsuite Parameters): Add GDBSERVER_DEBUG.
(gdbserver,debug): Add board setting.
* gdb.trace/tspeed.exp: Skip when debugging.
* lib/gdb.exp (gdbserver_debug_enabled): New procedure.
* lib/gdbserver-support.exp: Likewise
|
|
GDB was failing to catch cases where a corrupt ELF or core file
contained an invalid length value in a Dwarf debug frame FDE header.
It was checking for buffer overflow but not cases where the length was
negative or caused pointer wrap-around.
In addition to the additional validity check, this patch cleans up the
multiple signed/unsigned conversions on the length field so that an
unsigned representation is used consistently throughout.
This patch fixes CVE-2017-9778 and PR gdb/21600.
2019-04-25 Sandra Loosemore <sandra@codesourcery.com>
Kang Li <kanglictf@gmail.com>
PR gdb/21600
* dwarf2-frame.c (read_initial_length): Be consistent about using
unsigned representation of length.
(decode_frame_entry_1): Likewise. Check for wraparound of
end pointer as well as buffer overflow.
|
|
This changes the gdb test suite to omit -fno-stack-protector when
compiling Rust code. This makes Rust testing work again.
I think I saw this patch somewhere already, but I couldn't find it
again just now, so I'm checking this version in.
gdb/testsuite/ChangeLog
2019-04-24 Tom Tromey <tromey@adacore.com>
* lib/gdb.exp (gdb_compile): Don't add -fno-stack-protector for
Rust.
|
|
While trying to build GDB on i686, I found the following error:
In file included from ../../gdb/common/common-defs.h:105,
from ../../gdb/defs.h:28,
from ../../gdb/aarch64-tdep.c:21:
../../gdb/aarch64-tdep.c: In function 'gdbarch* aarch64_gdbarch_init(gdbarch_info, gdbarch_list*)':
../../gdb/aarch64-tdep.c:3176:43: error: format '%ld' expects argument of type 'long int', but argument 4 has type 'uint64_t' {aka 'long long unsigned int'} [-Werror=format=]
3176 | internal_error (__FILE__, __LINE__, _("VQ out of bounds: %ld (max %d)"),
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../gdb/common/gdb_locale.h:28:29: note: in definition of macro '_'
28 | # define _(String) gettext (String)
| ^~~~~~
../../gdb/aarch64-tdep.c:3176:64: note: format string is defined here
3176 | internal_error (__FILE__, __LINE__, _("VQ out of bounds: %ld (max %d)"),
| ~~^
| |
| long int
| %lld
This happens because aarch64-tdep.c:aarch64_gdbarch_init prints a
"uint64_t" variable using "%ld". This patch fixes the build by using
"pulongest" instead. As explained in a similar fix (commit
495143533ad95369811391c6e3c6dadd69d7dd67), this should be safe because
if aarch64-tdep.c is included in the build, then ULONGEST must be a
64-bit type.
gdb/ChangeLog:
2019-04-24 Sergio Durigan Junior <sergiodj@redhat.com>
* aarch64-tdep.c (aarch64_gdbarch_init): Use "pulongest" to print
"vq".
|
|
Commit 4aa866af ("Fix AMD64 return value ABI in expression
evaluation") introduced a regression when calling a function with a
structure that contains bitfields.
Because the caller of amd64_has_unaligned_fields handles bitfields
already, it seemed to me that the simplest fix was to ignore bitfields
here.
gdb/ChangeLog
2019-04-24 Tom Tromey <tromey@adacore.com>
* amd64-tdep.c (amd64_has_unaligned_fields): Ignore bitfields.
gdb/testsuite/ChangeLog
2019-04-24 Tom Tromey <tromey@adacore.com>
* gdb.arch/amd64-eval.exp: Test bitfield return.
* gdb.arch/amd64-eval.cc (struct Bitfields): New.
(class Foo) <return_bitfields>: New method.
(main): Call it.
|
|
Make use of the default gdbarch methods for gdbarch_unwind_pc, and
gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* s12z-tdep.c (s12z_unwind_pc): Delete.
(s12z_unwind_sp): Delete.
(s12z_gdbarch_init): Don't register deleted functions with
gdbarch.
|
|
Make use of the default gdbarch method gdbarch_unwind_sp where
possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* rl78-tdep.c (rl78_unwind_sp): Delete.
(rl78_gdbarch_init): Don't register deleted function with gdbarch.
|
|
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* xstormy16-tdep.c (xstormy16_unwind_sp): Delete.
(xstormy16_unwind_pc): Delete.
(xstormy16_dummy_id): Delete.
(xstormy16_gdbarch_init): Don't register deleted functions with
gdbarch.
|
|
Make use of the default gdbarch method gdbarch_unwind_pc where
possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* vax-tdep.c (vax_unwind_pc): Delete.
(vax_gdbarch_init): Don't register deleted function with gdbarch.
|
|
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* v850-tdep.c (v850_unwind_sp): Delete.
(v850_unwind_pc): Delete.
(v850_dummy_id): Delete.
(v850_gdbarch_init): Don't register deleted functions with
gdbarch.
|
|
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* tilegx-tdep.c (tilegx_unwind_sp): Delete.
(tilegx_unwind_pc): Delete.
(tilegx_unwind_dummy_id): Delete.
(tilegx_gdbarch_init): Don't register deleted functions with
gdbarch.
|
|
Make use of the default gdbarch methods for gdbarch_dummy_id, and
gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* tic6x-tdep.c (tic6x_unwind_sp): Delete.
(tic6x_dummy_id): Delete.
(tic6x_gdbarch_init): Don't register deleted functions with
gdbarch.
|
|
Make use of the default gdbarch method gdbarch_unwind_pc where
possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* sparc-tdep.c (sparc_unwind_pc): Delete.
(sparc32_gdbarch_init): Don't register deleted function with
gdbarch.
|
|
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* sh-tdep.c (sh_unwind_sp): Delete.
(sh_unwind_pc): Delete.
(sh_dummy_id): Delete.
(sh_gdbarch_init): Don't register deleted functions with
gdbarch.
|
|
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* score-tdep.c (score_unwind_sp): Delete.
(score_unwind_pc): Delete.
(score_dummy_id): Delete.
(score_gdbarch_init): Don't register deleted functions with
gdbarch.
|
|
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* rx-tdep.c (rx_unwind_pc): Delete.
(rx_unwind_sp): Delete.
(rx_dummy_id): Delete.
(rx_gdbarch_init): Don't register deleted functions with
gdbarch. Update comment.
|
|
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* rs6000-tdep.c (rs6000_unwind_pc): Delete.
(rs6000_dummy_id): Delete.
(rs6000_gdbarch_init): Don't register deleted functions with
gdbarch.
|
|
Make use of the default gdbarch method gdbarch_dummy_id where
possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
This commit leaves or1k_unwind_sp and or1k_unwind_pc in place. These
functions do match the default methods except that they add additional
debugging code. In order to preserve the debug I have left these
functions unchanged.
gdb/ChangeLog:
* or1k-tdep.c (or1k_dummy_id): Delete.
(or1k_gdbarch_init): Don't register deleted function with gdbarch.
|
|
Make use of the default gdbarch methods for gdbarch_dummy_id, and
gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* nios2-tdep.c (nios2_dummy_id): Delete.
(nios2_unwind_sp): Delete.
(nios2_gdbarch_init): Don't register deleted functions with
gdbarch.
|
|
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* nds32-tdep.c (nds32_dummy_id): Delete.
(nds32_unwind_pc): Delete.
(nds32_unwind_sp): Delete.
(nds32_gdbarch_init): Don't register deleted functions with
gdbarch.
|
|
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* msp430-tdep.c (msp430_unwind_pc): Delete.
(msp430_unwind_sp): Delete.
(msp430_dummy_id): Delete.
(msp430_gdbarch_init): Don't register deleted functions with
gdbarch.
|
|
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* moxie-tdep.c (moxie_unwind_sp): Delete.
(moxie_unwind_pc): Delete.
(moxie_dummy_id): Delete.
(moxie_gdbarch_init): Don't register deleted functions with
gdbarch.
|
|
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* mn10300-tdep.c (mn10300_dummy_id): Delete.
(mn10300_unwind_pc): Delete.
(mn10300_unwind_sp): Delete.
(mn10300_push_dummy_call): Use gdbarch_unwind_sp not
mn10300_unwind_sp.
(mn10300_frame_unwind_init): Don't register deleted functions with
gdbarch.
|
|
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* mep-tdep.c (mep_unwind_pc): Delete.
(mep_unwind_sp): Delete.
(mep_dummy_id): Delete.
(mep_gdbarch_init): Don't register deleted functions with
gdbarch.
|
|
Make use of the default gdbarch methods for gdbarch_unwind_pc, and
gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* m68hc11-tdep.c (m68hc11_unwind_pc): Delete.
(m68hc11_unwind_sp): Delete.
(m68hc11_gdbarch_init): Don't register deleted functions with
gdbarch.
|
|
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* m32r-tdep.c (m32r_unwind_sp): Delete.
(m32r_unwind_pc): Delete.
(m32r_dummy_id): Delete.
(m32r_gdbarch_init): Don't register deleted functions with
gdbarch.
|
|
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* m32c-tdep.c (m32c_unwind_pc): Delete.
(m32c_unwind_sp): Delete.
(m32c_dummy_id): Delete.
(m32c_gdbarch_init): Don't register deleted functions with
gdbarch.
|
|
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* gdb/lm32-tdep.c (lm32_unwind_sp): Delete.
(lm32_unwind_pc): Delete.
(lm32_dummy_id): Delete.
(lm32_gdbarch_init): Don't register deleted functions with
gdbarch.
|
|
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* gdb/iq2000-tdep.c (iq2000_unwind_sp): Delete.
(iq2000_unwind_pc): Delete.
(iq2000_dummy_id): Delete.
(iq2000_gdbarch_init): Don't register deleted functions with
gdbarch.
|
|
The general type_align method should be a suitable alternative to
nds32_type_align, so switch to use that.
The only change this will introduce is related to static fields in a
struct or union, the existing code doesn't take account of static
fields when computing the alignment for structs of unions, though this
is probably a bug - which would probably be exposed by the test case
gdb.cp/many-args.exp, though I don't have any way to test this target
right now.
gdb/ChangeLog:
* nds32-tdep.c (nds32_type_align): Delete.
(nds32_push_dummy_call): Use type_align instead.
|
|
Replaces use of arm_type_align with common type_align function.
Doing this fixes a bug in arm_type_align where static fields are
considered as part of the alignment calculation of a struct, which
results in arguments passed on the stack being misaligned, this bug
was causing a failure in gdb.cp/many-args.exp.
Part of the old arm_type_align is retained and used as the gdbarch
type align callback in order to correctly align vectors.
gdb/ChangeLog:
* arm-tdep.c (arm_type_align): Only handle vector override case.
(arm_push_dummy_call): Use type_align.
(arm_gdbarch_init): Register arm_type_align gdbarch function.
|
|
Replaces use of aarch64_type_align with common type_align function.
Doing this fixes a bug in aarch64_type_align where static fields are
considered as part of the alignment calculation of a struct, which
results in arguments passed on the stack being misaligned. This bug
is exposed in the new test gdb.cp/many-args.exp.
Part of the old aarch64_type_align is retained and used as the gdbarch
type align callback in order to correctly align vectors.
gdb/ChangeLog:
* aarch64-tdep.c (aarch64_type_align): Only handle vector override
case.
(pass_on_stack): Use type_align.
(aarch64_gdbarch_init): Register aarch64_type_align gdbarch
function.
gdb/testsuite/ChangeLog:
* gdb.cp/many-args.cc: New file.
* gdb.cp/many-args.exp: New file.
|
|
I noticed that one of the overloads of line_header::file_name_at is
unused. This patch removes it.
gdb/ChangeLog
2019-04-23 Tom Tromey <tromey@adacore.com>
* dwarf2read.c (line_header::file_name_at): Remove unused
overload.
|
|
When running gdb.btrace/reconnect.exp with native-gdbserver, we run into:
...
FAIL: gdb.btrace/reconnect.exp: first: stepi 19
...
due to the fact that we're trying to match:
...
stepi 19^M
0x00007ffff7dd8b57 in _dl_start () from /lib64/ld-linux-x86-64.so.2^M
...
using pattern:
...
gdb_test "stepi 19" "0x.* in .* from target.*"
...
Fix this by changing the pattern to:
...
gdb_test "stepi 19" "0x.* in .* from .*"
...
Tested on x86_64-linux with native and native-gdbserver.
gdb/testsuite/ChangeLog:
2019-04-23 Tom de Vries <tdevries@suse.de>
PR gdb/24433
* gdb.btrace/reconnect.exp: Fix stepi 19 pattern.
|
|
cc-with-tweaks.sh
The -m option of cc-with-tweaks.sh sets want_multi to true, invoking dwz like
this:
...
elif [ "$want_multi" = true ]; then
cp $output_file ${output_file}.alt
$DWZ -m ${output_file}.dwz "$output_file" ${output_file}.alt \
> /dev/null 2>&1
fi
...
The problem that is being solved here, is that we want to test dwz in
multifile mode, which requires more than one input file, while we only have
(at the scope of cc-with-tweaks.sh) one executable. We handle this by copying
the executable and offering this as a second input (and using a copy has the
additional benefit that it maximally enables dwz transformation).
However, after the dwz invocation, the copy is no longer used, and the
presence of the file actually causes a test regression:
...
FAIL: gdb.base/jit-so.exp: test jit-reader-load filename completion
...
Fix this by removing the superflous copy after dwz invocation.
Tested on x86_64-linux.
gdb/ChangeLog:
2019-04-23 Tom de Vries <tdevries@suse.de>
PR gdb/24438
* contrib/cc-with-tweaks.sh: Remove superfluous .alt file after dwz
invocation.
|
|
Ubuntu/Debian defaults PIE to enabled. This causes the trace tests
to fall over due to variables being returned as "unavailable". The
tests were never designed to work with pie.
Simply ensure the nopie flag is always used for the failing tests.
This removes 100+ failures when running native-gdbserver on Ubuntu 18.04.
gdb/testsuite/ChangeLog:
* gdb.trace/backtrace.exp: Use nopie flag.
* gdb.trace/circ.exp: Likewise.
* gdb.trace/collection.exp: Likewise.
* gdb.trace/ftrace.exp: Likewise.
* gdb.trace/mi-trace-unavailable.exp: Likewise.
* gdb.trace/mi-traceframe-changed.exp: Likewise.
* gdb.trace/qtro.exp: Likewise.
* gdb.trace/read-memory.exp: Likewise.
* gdb.trace/report.exp: Likewise.
* gdb.trace/tfile.exp: Likewise.
* gdb.trace/tfind.exp: Likewise.
* gdb.trace/unavailable.exp: Likewise.
|
|
DW_OP_addrx is the new name of DW_OP_GNU_addr_index, and DW_FORM_addrx
is the name of DW_FORM_addr_index in the Dwarf 5 standard. This is a small
step towards supporting Dwarf 5 in gdb.
Note: I could not find any tests specifically for *_GNU_addr_index, and
I did not add any new tests, please advise.
|
|
|
