| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
... instead of an operand one: There's only ever one operand here
anyway.
|
|
|
|
|
|
| |
... instead of an operand one. Which operand it applies to can be
determined from other operand properties, but as it turns out the only
place it is actually used at doesn't even need further qualification.
|
|
|
|
|
|
| |
The CMPS test case derivation from their MOVS counterparts I did in
d241b91073 ("x86/Intel: correct MOVSD and CMPSD handling") ended up
with misplaced closing parentheses in som regexps. Correct this.
|
|
|
|
| |
This is still in the context of PR/gas 25167.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
valgrind reports a leak when a breakpoint is created then deleted:
==1313== 40 bytes in 1 blocks are definitely lost in loss record 1,115 of 8,596
==1313== at 0x4835753: malloc (vg_replace_malloc.c:307)
==1313== by 0x6E05BC: _PyObject_New (object.c:255)
==1313== by 0x470E4B: gdbpy_breakpoint_created(breakpoint*) (py-breakpoint.c:1023)
==1313== by 0x2946D9: operator() (std_function.h:687)
==1313== by 0x2946D9: notify (observable.h:106)
==1313== by 0x2946D9: install_breakpoint(int, std::unique_ptr<breakpoint, std::default_delete<breakpoint> >&&, int) (breakpoint.c:8136)
==1313== by 0x295BCA: create_breakpoint_sal (breakpoint.c:8878)
==1313== by 0x295BCA: create_breakpoints_sal (breakpoint.c:8919)
==1313== by 0x295BCA: create_breakpoints_sal_default (breakpoint.c:13671)
...
The leak is due to a superfluous Py_INCREF when the python object
is allocated inside gdbpy_breakpoint_created, when the python object
is allocated locally: this object has already a refcount of 1, and
the only reference is the reference from the C breakpoint object.
The Py_INCREF is however needed when the python object was created from
python: the python object was stored in bppy_pending_object, and
gdbpy_breakpoint_created creates a new reference to this object.
Solve the leak by calling 'Py_INCREF (newbp);' only in the bppy_pending_object
case.
Regression tested on debian/amd64 natively and under valgrind on centos/amd64.
Before the patch, 795 tests have a definite leak.
After the patch, 197 have a definite leak.
Thanks to Tom, that helped on irc with the python refcount logic.
gdb/ChangeLog
2019-11-14 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* python/py-finishbreakpoint.c (gdbpy_breakpoint_created):
only call Py_INCREF (newbp) in the bppy_pending_object case.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit 3573abe1d added static asserts to ensure that symbol sizes
don't vary. However, this failed to build on Windows, on at least one
ARM platform (see PR build/25182) and internally at AdaCore for PPC.
So, I think it is probably best to just remove these assertions,
effectively reverting 3573abe1d.
gdb/ChangeLog
2019-11-13 Tom Tromey <tromey@adacore.com>
PR build/25182:
* psympriv.h (partial_symbol): Remove static assert.
* symtab.h (general_symbol_info, symbol): Remove static assert.
Change-Id: I51940fb2240c474838b48494b5072081701789bb
|
|
|
|
|
| |
PR 2587
* Makefile.am: Fix rule to build .c files from .m files.
|
|
|
|
|
|
|
|
|
|
|
|
| |
I don't know why this path is what it is but it is clearly wrong.
gnulib/ChangeLog:
2019-11-12 Christian Biesinger <cbiesinger@google.com>
* Makefile.in: Fix path to say import/ instead of gnulib/.
Change-Id: Ib7f6a319ee764d20072e38911766ca7032d6ca8e
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have to enable the f extension through -march or ELF attribute if we use the
FPR in .insn directive. The behavior is same as the riscv_opcodes.
2019-11-12 Nelson Chu <nelson.chu@sifive.com>
opcodes/
* riscv-opc.c (riscv_insn_types): Replace the INSN_CLASS_I with
INSN_CLASS_F and the INSN_CLASS_C with INSN_CLASS_F_AND_C if we
use the floating point register (FPR).
gas/
* testsuite/gas/riscv/insn.d: Add the f extension to -march option.
Change-Id: I4f59d04c82673ef84c56ecd2659ad8ce164dd626
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make _bfd_riscv_relax_call handle section alignment padding same as
the _bfd_riscv_relax_lui and _bfd_riscv_relax_pc functions already
do. Use the max section alignment if section boundaries are crossed,
otherwise the alignment of the containing section.
bfd/
PR 25181
* elfnn-riscv.c (_bfd_riscv_relax_call): Always add max_alignment to
foff. If sym_sec->output_section and sec->output_section are the same
and not *ABS* then set max_alignment to that section's alignment.
ld/
PR 25181
* testsuite/ld-riscv-elf/call-relax-0.s: New file.
* testsuite/ld-riscv-elf/call-relax-1.s: New file.
* testsuite/ld-riscv-elf/call-relax-2.s: New file.
* testsuite/ld-riscv-elf/call-relax-3.s: New file.
* testsuite/ld-riscv-elf/call-relax.d: New test.
* testsuite/ld-riscv-elf/ld-riscv-elf.exp: Run call-relax test.
Change-Id: Iaf65cee52345abf1955f36e8e72c4f6cc0db8d9a
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The gdb format mechanism doesn't currently support the 'z' size
modifier, there are a few places in GDB where this is used. Instead
of removing these uses lets just add support to GDB for using 'z'.
I found this issue when trying to use some of the debug output.
Before this commit:
(gdb) set debug dwarf-line 9
(gdb) file test
Reading symbols from test...
Unrecognized format specifier 'z' in printf
(No debugging symbols found in test)
(gdb)
After this commit:
(gdb) set debug dwarf-line 9
(gdb) file test
Reading symbols from test...
Adding dir 1: /usr/include
Adding file 1: test.c
Adding file 2: stdc-predef.h
Processing actual line 3: file 1, address 0x4004a0, is_stmt 1, discrim 0
Processing actual line 4: file 1, address 0x4004a0, is_stmt 1, discrim 0
.... lots of debug output ...
Processing actual line 10: file 1, address 0x4003b7, is_stmt 0, discrim 0
(gdb)
I've added a self test to cover the integer format size modifiers,
including the 'z' modifier.
gdb/ChangeLog:
* gdbsupport/format.c (format_pieces::format_pieces): Support
printf 'z' size modifier.
* gdbsupport/format.h (enum argclass): Add size_t_arg.
* printcmd.c (ui_printf): Handle size_t_arg.
* ui-out.c (ui_out::vmessage): Likewise.
* unittests/format_pieces-selftests.c (test_format_int_sizes): New
function.
(run_tests): Call test_format_int_sizes.
gdb/gdbserver/ChangeLog:
* ax.c (ax_printf): Handle size_t_arg.
Change-Id: Ib6c44d88aa5bce265d757e4c0698881803dd186f
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since this is now no longer a POD, also give it a constructor that
initializes all fields. (I have considered overloading operator new
to zero-initialize the memory instead; let me know if you prefer that)
gdb/ChangeLog:
2019-11-12 Christian Biesinger <cbiesinger@google.com>
* ada-exp.y (write_ambiguous_var): Update.
* buildsym.c (add_symbol_to_list): Update.
* dwarf2read.c (read_variable): Update.
(new_symbol): Update.
* jit.c (finalize_symtab): Update.
* language.c (language_alloc_type_symbol): Update.
* symtab.c (fixup_symbol_section): Update.
(initialize_objfile_symbol_1): Move code to...
(initialize_objfile_symbol): ...here. Remove now-unnecessary memset.
(allocate_symbol): Update.
(allocate_template_symbol): Update.
(get_symbol_address): Update.
* symtab.h (struct symbol): Inherit from general_symbol_info instead
of having as a field, and add a constructor.
(SYMBOL_VALUE): Update.
(SYMBOL_VALUE_ADDRESS): Update.
(SET_SYMBOL_VALUE_ADDRESS): Update.
(SYMBOL_VALUE_BYTES): Update.
(SYMBOL_VALUE_COMMON_BLOCK): Update.
(SYMBOL_BLOCK_VALUE): Update.
(SYMBOL_VALUE_CHAIN): Update.
(SYMBOL_LANGUAGE): Update.
(SYMBOL_SECTION): Update.
(SYMBOL_OBJ_SECTION): Update.
(SYMBOL_SET_LANGUAGE): Update.
(SYMBOL_SET_LINKAGE_NAME): Update.
(SYMBOL_SET_NAMES): Update.
(SYMBOL_NATURAL_NAME): Update.
(SYMBOL_LINKAGE_NAME): Update.
(SYMBOL_DEMANGLED_NAME): Update.
(SYMBOL_SEARCH_NAME): Update.
(SYMBOL_MATCHES_SEARCH_NAME): Update.
(struct symbol): Update.
(struct template_symbol): Update.
(struct rust_vtable_symbol): Update.
* xcoffread.c (SYMBOL_DUP): Update.
Change-Id: I05b1628455bcce3efaa101e65ef051708d17eb07
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently several functions in tui-layout.c set current_layout after
their work is done. This moves this assignment to show_layout,
instead.
gdb/ChangeLog
2019-11-12 Tom Tromey <tom@tromey.com>
* tui/tui-layout.c (show_layout): Set current_layout.
(show_source_disasm_command, show_data)
(show_source_or_disasm_and_command): Don't set current_layout.
Change-Id: Id8b23797d68e607f0fcd6d29b8801869d40d1869
|
|
|
|
|
|
|
|
|
|
|
|
| |
This moves _initialize_tui_layout to the end of the file, conforming
to the typical gdb style.
gdb/ChangeLog
2019-11-12 Tom Tromey <tom@tromey.com>
* tui/tui-layout.c (_initialize_tui_layout): Move to end.
Change-Id: I667f741b44b2bc470878a36f093a96d89fa31893
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As Sergio pointed out, the TUI resizing tests are flaky. Debugging
this showed three main problems.
1. expect's "stty" command processes its arguments one-by-one. So,
rather than requesting a single resize, it sends two separate resize
requests (one for rows and one for columns). This means gdb sees two
SIGWINCH signals and resizes the terminal twice.
I consider this a bug in expect, but I couldn't readily see how to
report a bug; and anyway the fix wouldn't propagate very quickly.
This patch works around this problem by explicitly doing two separate
resizes (so it will be robust if expect ever does change); and then by
waiting for each resize to complete before continuing.
2. gdb uses curses to drive the console rendering. Currently the test
suite looks for terminal text insertion sequences to decide when a
command has completed. However, it turns out that, sometimes, curses
can output things in non-obvious ways. I didn't debug into curses but
I guess this can happen due to output optimizations. No matter the
reason, sometimes the current approach of only tracking text
insertions is not enough to detect that gdb has finished rendering.
This patch fixes this problem by arranging to detect the termination
output after any curses command, not just insertion.
3. Detecting when a resize has completed is tricky. In fact, I could
not find a way to reliably do this.
This patch fixes this problem by adding a special maint
"tui-resize-message" setting to gdb. When this is enabled, gdb will
print a message after each SIGWINCH has been fully processed. The
test suite enables this mode and then waits for the message in order
to know when control can be returned to the calling test.
This patch also adds a timeout, to avoid the situation where the
terminal code fails to notice a change for some reason. This lets the
test at least try to continue.
gdb/ChangeLog
2019-11-12 Tom Tromey <tom@tromey.com>
* tui/tui-win.c (resize_message): New global.
(show_tui_resize_message): New function.
(tui_async_resize_screen): Print message if requested.
(_initialize_tui_win): Add tui-resize-message setting.
* NEWS: Add entry for new commands.
gdb/doc/ChangeLog
2019-11-12 Tom Tromey <tom@tromey.com>
* gdb.texinfo (Maintenance Commands): Document new command.
gdb/testsuite/ChangeLog
2019-11-12 Tom Tromey <tom@tromey.com>
* lib/tuiterm.exp (_accept): Add wait_for parameter. Check output
after any command. Expect prompt after WAIT_FOR is seen.
(enter_tui): Enable resize messages.
(command): Expect command in output.
(get_line): Avoid error when cursor appears to be off-screen.
(dump_screen): Include screen size in title.
(_do_resize): New proc, from "resize".
(resize): Rewrite. Do resize in two steps.
* gdb.tui/empty.exp (layouts): Fix entries.
(check_boxes): Remove xfail.
(check_text): Dump screen on failure.
Change-Id: I420e0259cb99b21adcd28f671b99161eefa7a51d
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch enables a few instructions for Armv8.1-M MVE. Currently VLDM,
VSTM, VSTR, VLDR, VPUSH and VPOP are enabled only when the Armv8-M
Floating-point Extension is enabled. According to the ARMv8.1-M ARM,
section A.1.4.2[1], they can be enabled by having "Armv8-M Floating-point
Extension and/or Armv8.1-M MVE".
[1]https://developer.arm.com/docs/ddi0553/bh/armv81-m-architecture-reference-manual
2019-11-12 Mihail Ionescu <mihail.ionescu@arm.com>
* config/tc-arm.c (do_vfp_nsyn_push): Move in order to enable it for
both fpu_vfp_ext_v1xd and mve_ext and add call to the aliased vstm
instruction for mve_ext.
(do_vfp_nsyn_pop): Move in order to enable it for both
fpu_vfp_ext_v1xd and mve_ext and add call to the aliased vldm
instruction for mve_ext.
(do_neon_ldm_stm): Add fpu_vfp_ext_v1 and mve_ext checks.
(insns): Enable vldm, vldmia, vldmdb, vstm, vstmia, vstmdb, vpop,
vpush, and fldd, fstd, flds, fsts for arm_ext_v6t2 instead
of fpu_vfp_ext_v1xd.
* testsuite/gas/arm/v8_1m-mve.s: New.
* testsuite/gas/arm/v8_1m-mve.d: New.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch updates the decoding of the VMOV and VMVN instructions which depend on cmode.
Previously VMOV and VMVN with cmode 1101 were not allowed.
The cmode changes also required updating of the MVE conflict checking.
Now instructions with opcodes 0xef800d50 and 0xef800e70 correctly get decoded as VMOV
and VMVN, respectively.
2019-11-12 Mihail Ionescu <mihail.ionescu@arm.com>
* opcodes/arm-dis.c (mve_opcodes): Enable VMOV imm to vec with
cmode 1101.
(is_mve_encoding_conflict): Update cmode conflict checks for
MVE_VMVN_IMM.
2019-11-12 Mihail Ionescu <mihail.ionescu@arm.com>
* gas/config/tc-arm.c (do_neon_mvn): Allow mve_ext cmode=0xd.
* testsuite/gas/arm/mve-vmov-vmvn-vorr-vbic.s: New test.
* testsuite/gas/arm/mve-vmov-vmvn-vorr-vbic.d: Likewise.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch is fixes the '.fpu' behaviour.
Currently, using '.fpu' resets the previously selected '.fpu' options (by overwriting them),
but does not reset previous FPU options selected by other means (ie. when using
'.arch_extension fp' in conjunction with '.fpu <x>', the FPU is not reset).
Example:
.arch armv8-a @ SET BASE
.arch_extension fp @ ADD FP-ARMV8
.fpu vfpv2 @ ADD (already existing bits, does not reset)
vfms.f32 s0, s1, s2 @ OK
.arch armv8-a @ RESET
.fpu fp-armv8 @ ADD FP-ARMV8
vfms.f32 s0, s1, s2 @ OK
.fpu vfpv2 @ RESET to VFPV2
vfms.f32 s0, s1, s2 @ ERROR
After the patch this becomes:
.arch armv8-a @ SET BASE
.arch_extension fp @ ADD FP-ARMV8
.fpu vfpv2 @ RESET TO VFPV2
vfms.f32 s0, s1, s2 @ ERROR
.arch armv8-a @ RESET
.fpu fp-armv8 @ ADD FP-ARMV8
vfms.f32 s0, s1, s2 @ OK
.fpu vfpv2 @ RESET to VFPV2
vfms.f32 s0, s1, s2 @ ERROR
gas/ChangeLog:
2019-11-11 Mihail Ionescu <mihail.ionescu@arm.com>
* config/tc-arm.c (s_arm_fpu): Clear selected_cpu fpu bits.
(fpu_any): Remove OBJ_ELF guards.
* gas/testsuite/gas/arm/fpu-rst.s: New.
* gas/testsuite/gas/arm/fpu-rst.d: New.
* gas/testsuite/gas/arm/fpu-rst.l: New.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
EsSeg (a per-operand bit) is used with IsString (a per-insn attribute)
only. Extend the attribute to 2 bits, thus allowing to encode
- not a string insn,
- string insn with neither operand requiring use of %es:,
- string insn with 1st operand requiring use of %es:,
- string insn with 2nd operand requiring use of %es:,
which covers all possible cases, allowing to drop EsSeg.
The (transient) need to comment out the OTUnused #define did uncover an
oversight in the earlier OTMax -> OTNum conversion, which is being taken
care of here.
|
|
|
|
|
|
|
|
| |
Drop the remaining instances left in place by commit c3949f432f ("x86:
limit ImmExt abuse), now that we have a way to specify specific GPRs.
Take the opportunity and also introduce proper 16-bit forms of
applicable SVME insns as well as 1-operand forms of CLZERO.
|
|
|
|
|
|
|
|
|
|
|
| |
Special register "class" instances can't be combined with one another
(neither in templates nor in register entries), and hence it is not a
good use of resources (memory as well as execution time) to represent
them as individual bits of a bit field.
Furthermore the generalization becoming possible will allow
improvements to the handling of insns accepting only individual
registers as their operands.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds readline-bindable function names to a few gdb functions that
already had key bindings. This lets users change the bindings.
This also removes the gdb-command function. Due to how this function
is implemented, it doesn't make sense to allow binding it.
Finally, this updates the documentation to reflect these changes.
gdb/ChangeLog
2019-11-11 Tom Tromey <tom@tromey.com>
* tui/tui.c (tui_initialize_readline): Add new bindable readline
functions.
gdb/doc/ChangeLog
2019-11-11 Tom Tromey <tom@tromey.com>
* gdb.texinfo (TUI Keys): Document readline function names.
Change-Id: I2233779b7aefe372f19bd03c8f325733c3385e72
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds some documentation for the operate-and-get-next readline
function that gdb supplies. The text is largely taken from the Bash
manual.
gdb/doc/ChangeLog
2019-11-11 Tom Tromey <tom@tromey.com>
* gdb.texinfo (Editing): Document operate-and-get-next.
Change-Id: I9adb16d9ce84bfbda5fe8a2828f668ea878c080c
|
|
|
|
|
|
|
|
|
|
| |
gdb/ChangeLog:
2019-11-11 Christian Biesinger <cbiesinger@google.com>
* nat/linux-osdata.c (user_from_uid): Use getpwuid_r.
Change-Id: I587359267f8963ef1da6ba0223a1525807a721de
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A user on irc noticed that the remote protocol documentation mentioned
"vFile:write" -- but this is a typo, there is only "vFile:pwrite".
This patch fixes the bug. Tested by rebuilding, committing as
obvious.
gdb/doc/ChangeLog
2019-11-11 Tom Tromey <tromey@adacore.com>
* gdb.texinfo (Host I/O Packets): Fix typo in "vFile:pwrite".
Change-Id: I2f668a691eed7883ba6bc092471739f44c82301b
|
|
|
|
| |
This is just like for their umaxp/uminp and fmaxp/fminp counterparts.
|
|
|
|
|
|
| |
Some old glibc versions have string.h surface "index", which some
compilers then warn about if shadowed by a local variable. Re-use an
existing variable instead.
|
|
|
|
|
|
|
| |
PR 24996
* expression.cc (Trinary_expression::arg2_value): Use correct integer
expression when calling "eval_maybe_dot" method.
(Trinary_expression::arg3_value): Likewise.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If gdb.lookup_static_symbol is going to return a single symbol then it
makes sense (I think) for it to return a context sensitive choice of
symbol, that is the global static symbol that would be visible to the
program at that point.
However, if the user of the python API wants to instead get a
consistent set of global static symbols, no matter where they stop,
then they have to instead consider all global static symbols with a
given name - there could be many. That is what this new API function
offers, it returns a list (possibly empty) of all global static
symbols matching a given name (and optionally a given symbol domain).
gdb/ChangeLog:
* python/py-symbol.c (gdbpy_lookup_static_symbols): New
function.
* python/python-internal.h (gdbpy_lookup_static_symbols):
Declare new function.
* python/python.c (python_GdbMethods): Add
gdb.lookup_static_symbols method.
* NEWS: Mention gdb.lookup_static_symbols.
gdb/testsuite/ChangeLog:
* gdb.python/py-symbol.exp: Add test for
gdb.lookup_static_symbols.
gdb/doc/ChangeLog:
* python.texi (Symbols In Python): Add documentation for
gdb.lookup_static_symbols.
Change-Id: I1153b0ae5bcbc43b3dcf139043c7a48bf791e1a3
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When using gdb.lookup_static_symbol I think that GDB should find
static symbols (global symbol with static linkage) from the current
object file ahead of static symbols from other object files.
This means that if we have two source files f1.c and f2.c, and both
files contains 'static int foo;', then when we are stopped in f1.c a
call to 'gdb.lookup_static_symbol ("foo")' will find f1.c::foo, and if
we are stopped in f2.c we would find 'f2.c::foo'.
Given that gdb.lookup_static_symbol always returns a single symbol,
but there can be multiple static symbols with the same name GDB is
always making a choice about which symbols to return. I think that it
makes sense for the choice GDB makes in this case to match what a user
would get on the command line if they asked to 'print foo'.
gdb/testsuite/ChangeLog:
* gdb.python/py-symbol.c: Declare and call function from new
py-symbol-2.c file.
* gdb.python/py-symbol.exp: Compile both source files, and add new
tests for gdb.lookup_static_symbol.
* gdb.python/py-symbol-2.c: New file.
gdb/doc/ChangeLog:
* python.texi (Symbols In Python): Extend documentation for
gdb.lookup_static_symbol.
gdb/ChangeLog:
* python/py-symbol.c (gdbpy_lookup_static_symbol): Lookup in
static block of current object file first. Also fix typo in
header comment.
Change-Id: Ie55dbeb8806f35577b46015deecde27a0ca2ab64
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In stack.c we currently have a set of static global variables to track
the last displayed symtab and line. This commit moves all of these
into a class and adds an instance of the class to track the same
information.
The API into stack.c is unchanged after this cleanup.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* stack.c (set_last_displayed_sal): Delete.
(last_displayed_sal_valid): Delete.
(last_displayed_pspace): Delete.
(last_displayed_addr): Delete.
(last_displayed_symtab): Delete.
(last_displayed_line): Delete.
(class last_displayed_symtab_info_type): New.
(last_displayed_symtab_info): New static global variable.
(print_frame_info): Call methods on last_displayed_symtab_info.
(clear_last_displayed_sal): Update header comment, and make use of
last_displayed_symtab_info.
(last_displayed_sal_is_valid): Likewise.
(get_last_displayed_pspace): Likewise.
(get_last_displayed_addr): Likewise.
(get_last_displayed_symtab): Likewise.
(get_last_displayed_line): Likewise.
(get_last_displayed_sal): Likewise.
* stack.h (clear_last_displayed_sal): Update header comment.
(last_displayed_sal_is_valid): Likewise.
(get_last_displayed_pspace): Likewise.
(get_last_displayed_addr): Likewise.
(get_last_displayed_symtab): Likewise.
(get_last_displayed_line): Likewise.
(get_last_displayed_sal): Likewise.
Change-Id: Ia3dbfe267feec03108c5c8ed8bd94fc0a030c3ed
|
|
|
|
|
|
|
|
|
|
|
|
| |
Just a clean up, should be no user visible changes after this commit.
gdb/ChangeLog:
* stack.c (frame_show_address): Convert return type to bool.
* stack.h (frame_show_address): Likewise, and update header
comment.
Change-Id: Iaaa9ebd4ff6534db19c5329f1c604932c747bd7f
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While working on another patch I ran into an issue with
unordered_remove (in gdb_vecs.h), where removing the last item of the
vector can cause a self move assign.
When compiling the C++ standard library in debug mode (with
-D_GLIBCXX_DEBUG=1) this causes an error to trigger.
I've fixed the issue in this patch and provided a unit test.
The provided unit test includes an assignment operator which checks
for self move assign, this removes the need to compile with
-D_GLIBCXX_DEBUG=1 in order to spot the bug. If you're keen to see
the error reported from the C++ standard library then remove operator=
from the unit test and recompile GDB with -D_GLIBCXX_DEBUG=1.
gdb/ChangeLog:
* Makefile.in (SUBDIR_UNITTESTS_SRCS): Add new file to the list.
* unittests/vec-utils-selftests.c: New file.
* gdbsupport/gdb_vecs.h (unordered_remove): Avoid self move assign.
Change-Id: I80247b20cd5212038117db7412865f5e6a9257cd
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Each TUI window has a "can_highlight" member. However, this has the
same meaning as "can_box" -- a window can be highlighted if and only
if it can be boxed. So, this patch removes can_highlight in favor of
simply using can_box.
gdb/ChangeLog
2019-11-10 Tom Tromey <tom@tromey.com>
* tui/tui-wingeneral.c (tui_unhighlight_win): Use can_box.
(tui_highlight_win): Likewise.
(tui_win_info::check_and_display_highlight_if_needed): Likewise.
* tui/tui-data.h (struct tui_win_info) <can_highlight>: Remove.
* tui/tui-command.h (struct tui_cmd_window) <tui_cmd_window>:
Don't set can_highlight.
Change-Id: I35916859070efcdfcc6e692c71cc6070956dcfce
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I noticed that cli_style_option declares a constructor that is never
defined. This removes it.
gdb/ChangeLog
2019-11-10 Tom Tromey <tom@tromey.com>
* cli/cli-style.h (class cli_style_option) <cli_style_option>:
Remove unused declaration.
Change-Id: Ic59ec7eab4d7183d9392b58709354b2d4449b7be
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We should check suffix in instruction mnemonic when matching instruction.
In Intel syntax, normally we check for memory operand size. But the same
mnemonic with 2 different encodings can have the same memory operand
size and i.suffix is set to LONG_DOUBLE_MNEM_SUFFIX from memory operand
size in Intel syntax to distinguish them. When there is no suffix in
mnemonic, we check LONG_DOUBLE_MNEM_SUFFIX in i.suffix for mnemonic
suffix.
gas/
PR gas/25167
* config/tc-i386.c (match_template): Don't check instruction
suffix set from operand.
* testsuite/gas/i386/code16.d: New file.
* testsuite/gas/i386/code16.s: Likewise.
* testsuite/gas/i386/i386.exp: Run code16.
* testsuite/gas/i386/x86-64-branch-4.l: Updated.
opcodes/
PR gas/25167
* i386-opc.tbl: Remove IgnoreSize from cmpsd and movsd.
* i386-tbl.h: Regenerated.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changes command_line_input to return a "const char *", which is
appropriate because the memory is owned by command_line_input. Then
it fixes up the users.
I looked at making command_line_input transfer ownership to its caller
instead, but this is complicated due to the way read_next_line is
called, so I decided against it.
Tested by rebuilding.
gdb/ChangeLog
2019-11-08 Tom Tromey <tromey@adacore.com>
* top.c (read_command_file): Update.
(command_line_input): Make return type const.
* python/py-gdb-readline.c: Update.
* linespec.c (decode_line_2): Update.
* defs.h (command_line_input): Make return type const.
* cli/cli-script.c (read_next_line): Make return type const.
* ada-lang.c (get_selections): Update.
Change-Id: I27e6c9477fd1005ab5b16e0d337e4c015b6e6248
|
|
|
|
|
| |
This reverts commit f2aaebdb97977ee7a5c83c02af871e758e7d594b.
My reasons for making that change were just plain wrong.
|
|
|
|
| |
This is to further shrink the operand type representation.
|
|
|
|
| |
This is to further shrink the operand type representation.
|
|
|
|
| |
This is to further shrink the operand type representation.
|
|
|
|
| |
This is to further shrink the operand type representation.
|
|
|
|
|
|
|
| |
Many operand types, in particular the various kinds of registers, can't
be combined with one another (neither in templates nor in register
entries), and hence it is not a good use of resources (memory as well as
execution time) to represent them as individual bits of a bit field.
|
|
|
|
|
| |
PR 25172
* objdump.c (usage): Correct --stop-address description.
|