| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
If a header file defining a static function is included in multiple source
files, each calling the function, and GDB is asked to jump to a line inside
that function, there would be multiple locations matching the target. The
solution in this commit is to select the location in the current symtab.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
This patch augments the DAP launch request with some optional new
parameters that let the client control the command-line arguments and
the environment of the inferior.
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
This adds two new attributes and three new methods to gdb.Inferior.
The attributes let Python code see the command-line arguments and the
name of "main". Argument setting is also supported.
The methods let Python code manipulate the inferior's environment
variables.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
|
|
It's not worth avoiding an fseek to the same position, and can cause
problems if the linker's output file (which is opened "w+") is read,
because that can result in writing, reading, then writing again.
POSIX.1-2017 (IEEE Std 1003.1) says of fopen:
"When a file is opened with update mode ('+' as the second or third
character in the mode argument), both input and output may be
performed on the associated stream. However, the application shall
ensure that output is not directly followed by input without an
intervening call to fflush() or to a file positioning function
(fseek(), fsetpos(), or rewind()), and input is not directly followed
by output without an intervening call to a file positioning function,
unless the input operation encounters end-of-file."
* bfdio.c (bfd_seek): Always call iovec->bseek.
|
|
|
|
DAP specifies that if an evaluate request does not have a frameID
parameter, then the expression is evaluated in the global scope.
|
|
This adds a 'global_context' parse_and_eval to gdb.parse_and_eval.
This lets users request a parse that is done at "global scope".
I considered letting callers pass in a block instead, with None
meaning "global" -- but then there didn't seem to be a clean way to
express the default for this parameter.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
This adds a flags parameter to parse_and_eval.
|
|
This adds a PARSER_LEAVE_BLOCK_ALONE flag, and changes the parse API
to respect it. This flag lets callers avoid any change to the
passed-in block and expression PC, letting them specify the context
exactly. In particular, now nullptr can be used to indicate that the
parse should not examine any local variables.
|
|
This adds a new PARSER_DEBUG constant and changes the parser code to
use it. This lets us make the 'parser_debug' global 'static'.
|
|
This patch mildly rearranges parser_state, moving all the bool fields
together.
|
|
parser_state::comma_terminates ought to be boolean, and changing it
does not require any other changes.
|
|
This simplifies the parser_state constructor by having it accept a
parser_flags parameter.
|
|
This patch adds a new parser_flags type and changes the parser APIs to
use it rather than a collection of 'int' and 'bool'. More flags will
be added in subsquent patches.
|
|
I think parser-defs.h should hold declarations that can be used by
parser implementations, whereas expression.h should hold declarations
that are used by code that wants to call a parser. Following this
logic, this patch moves innermost_block_tracker to expression.h.
|
|
This minorly rearranges parse.c to avoid the need for a forward
declaration.
|
|
This implements the DAP loadedSources request, using gdb.execute_mi to
avoid having to write another custom Python API.
|
|
This adds a new Python function, gdb.execute_mi, that can be used to
invoke an MI command but get the output as a Python object, rather
than a string. This is done by implementing a new ui_out subclass
that builds a Python object.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=11688
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
This adds a second mi_parse constructor. This constructor takes a
command name and vector of arguments, and does not do any escape
processing. This also changes mi_parse::args to handle parse objects
created this new way.
|
|
This introduces some helper methods for mi_parse that handle some of
the details of parsing. This approach lets us reuse them later.
|
|
Change the mi_parse function to be a static method of mi_parse. This
lets us remove the 'set_args' setter function.
|
|
This changes mi_parse_argv to be a method of mi_parse. This is just a
minor cleanup.
|
|
This changes mi_parse::args to be a private member, retrieved via
accessor. It also changes this member to be a std::string. This
makes it simpler for a subsequent patch to implement different
behavior for argument parsing.
|
|
This changes mi_parse to use member initializers rather than a
constructor. This is easier to follow.
|
|
If an MI command written in Python includes a number in its output,
currently that is simply emitted as a string. However, it's
convenient for a later patch if these are emitted using field_signed.
This does not make a difference to ordinary MI clients.
|
|
clear_current_line overwrites the current line with chars_per_line
blank spaces. Printing the final space triggers a condition in
pager_file::puts that causes lines_printed to be incremented. If
lines_printed becomes greater than or equal to lines_allowed, the
pagination prompt will appear if enabled.
In this case the prompt is unnecessary since after printing the final
space clear_current_line immediately moves the cursor to the beginning
of the line with '\r'. A new line isn't actually started, so the prompt
ends up being spurious.
Additionally it's possible for gdb to crash during this pagination prompt.
Answering the prompt with 'q' throws an exception intended to bring gdb
back to the main event loop. But since commit 0fea10f32746,
clear_current_line may be called under the progress_update destructor.
The exception will try to propagate through the destructor, causing an abort.
To fix this, pagination is disabled for the duration for clear_current_line.
clear_current_line is also renamed to clear_progress_notify to help
indicate that it is a special purpose function intended for use with
do_progress_notify.
Acked-by: Eli Zaretskii <eliz@gnu.org>
|
|
normally RELA relocs in BFD should not consider the contents of the
relocated place. The aarch64 psABI is even stricter, it specifies
(section 5.7.16) that all RELA relocs _must_ be idempotent.
Since the inception of the aarch64 BFD backend all the relocs have a
non-zero src_mask, and hence break this invariant. It's normally not
a very visible problem as one can see it only when the relocated place
already contains a non-zero value, which usually only happens sometimes
when using 'ld -r' (or as in the testcase when jumping through hoops to
generate the relocations). Or with alternative toolchains that do encode
stuff in the relocated places with the assumption that a relocation
to that place ignores whatever is there (as they can according to
the psABI).
Golang is such a toolchain and https://github.com/golang/go/issues/39927
is ultimately caused by this problem: the testcase testGCData failing
is caused by the garbage collection data-structure to describe a type
containing pointers to be wrong. It's wrong because a field that's
supposed to contain a file-relative offset (to some gcbits) has a
relocation applied and that relocation has an addend which also is
already part of the go-produced object file (so the addend is
implicitely applied twice).
bfd/
PR ld/30437
* elfnn-aarch64.c (elfNN_aarch64_howto_table): Clear src_mask
if all relocation descriptors.
ld/
* testsuite/ld-aarch64/rela-idempotent.s: New testcase.
* testsuite/ld-aarch64/rela-idempotent.d: New.
* testsuite/ld-aarch64/aarch64-elf.exp: Run it.
|
|
|
|
When testing gdb.arch/disp-step-insn-reloc.exp with clang in an x86_64
machine, the compiled test case would segfault when returning from
the function can_relocate_call, with a suggestion of a broken stack.
The example assembly in the commment was the following:
f:
MOV $1, %[ok]
JMP end
set_point0:
CALL f ; tracepoint here.
end:
And the segmentation fault happening at the final "ret" instruction of
can_relocate_call. Looking at the disassembled version of the later
half of the important function, we see:
Clang version (f starting at 11a4):
00000000000011ae <set_point0>:
11ae: e8 f1 ff ff ff callq 11a4 <can_relocate_call+0x14>
11b3: 89 45 fc mov %eax,-0x4(%rbp)
11b6: 83 7d fc 01 cmpl $0x1,-0x4(%rbp)
11ba: 0f 85 0a 00 00 00 jne 11ca <set_point0+0x1c>
11c0: e8 5b 00 00 00 callq 1220 <pass>
11c5: e9 05 00 00 00 jmpq 11cf <set_point0+0x21>
11ca: e8 61 00 00 00 callq 1230 <fail>
11cf: 48 83 c4 10 add $0x10,%rsp
11d3: 5d pop %rbp
11d4: c3 retq
11d5: 66 66 2e 0f 1f 84 00 data16 nopw %cs:0x0(%rax,%rax,1)
11dc: 00 00 00 00
gcc version (f starting at 401125):
000000000040112c <set_point0>:
40112c: e8 f4 ff ff ff callq 401125 <can_relocate_call+0x11>
401131: 89 45 fc mov %eax,-0x4(%rbp)
401134: 83 7d fc 01 cmpl $0x1,-0x4(%rbp)
401138: 75 07 jne 401141 <set_point0+0x15>
40113a: e8 c7 ff ff ff callq 401106 <pass>
40113f: eb 05 jmp 401146 <set_point0+0x1a>
401141: e8 c7 ff ff ff callq 40110d <fail>
401146: 90 nop
401147: c9 leaveq
401148: c3 retq
The epilogue of set_point0 (11cf for clang, 401146 for gcc) is the main
difference: GCC's version uses the leaveq instruction, which resets rsp
based on rbp, while clang adds the same constant to rsp that it
subtracted in the prologue. Clang fails because the return address that
is added by the "call f" instruction isn't accounted for.
This commit fixes that by adding a return instruction to f, which leaves
the rsp as the compilers would expect.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
If in a "word ptr <address>" or alike construct the "ptr" part is
double-quoted, it shouldn't be recognized as the specific keyword we're
looking for (just like we don't recognize double-quoted operator or
register names anymore). Be careful though to tell closing from opening
double-quotes, as a quoted symbol may follow right afterwards.
|
|
The concept of quoted symbols names was introduced pretty late. Utilize
it to allow access to symbols with names matching that of a register (or,
in Intel syntax, also an identifier-like operator).
This is primarily to aid gcc when generating Intel syntax output; see
their bug target/53929.
|
|
gas/ChangeLog:
* NEWS: Support Intel FRED LKGS.
* config/tc-i386.c: Add fred lkgs
* doc/c-i386.texi: Document .fred, .lkgs.
* testsuite/gas/i386/i386.exp: Add FRED LKGS tests
* testsuite/gas/i386/x86-64-fred-intel.d: Ditto.
* testsuite/gas/i386/x86-64-fred.d: Ditto.
* testsuite/gas/i386/x86-64-fred.s: Ditto.
* testsuite/gas/i386/x86-64-lkgs-intel.d: Ditto.
* testsuite/gas/i386/x86-64-lkgs-inval.l: Ditto.
* testsuite/gas/i386/x86-64-lkgs-inval.s: Ditto.
* testsuite/gas/i386/x86-64-lkgs.d: Ditto.
* testsuite/gas/i386/x86-64-lkgs.s: Ditto.
opcodes/ChangeLog:
* i386-dis.c: New entry for fred, lkgs.
* i386-gen.c: Add CPU_FRED CPU_LKGS.
* i386-init.h : Regenerated.
* i386-mnem.h : Regenerated.
* i386-opc.h: Add fred, lkgs.
* i386-opc.tbl: Add FRED, LKGS instructions.
* i386-tbl.h: Regenerated.
|
|
This reverts commit e5a497fe38e0ab19e16bdd9e4b4ed5e4d0056478.
|
|
gas/ChangeLog:
* NEWS: Support Intel FRED LKGS.
* config/tc-i386.c: Add fred lkgs
* doc/c-i386.texi: Document .fred, .lkgs.
* testsuite/gas/i386/i386.exp: Add FRED LKGS tests
* testsuite/gas/i386/x86-64-fred-intel.d: Ditto.
* testsuite/gas/i386/x86-64-fred.d: Ditto.
* testsuite/gas/i386/x86-64-fred.s: Ditto.
* testsuite/gas/i386/x86-64-lkgs-intel.d: Ditto.
* testsuite/gas/i386/x86-64-lkgs-inval.l: Ditto.
* testsuite/gas/i386/x86-64-lkgs-inval.s: Ditto.
* testsuite/gas/i386/x86-64-lkgs.d: Ditto.
* testsuite/gas/i386/x86-64-lkgs.s: Ditto.
opcodes/ChangeLog:
* i386-dis.c: New entry for fred, lkgs.
* i386-gen.c: Add CPU_FRED CPU_LKGS.
* i386-init.h : Regenerated.
* i386-mnem.h : Regenerated.
* i386-opc.h: Add fred, lkgs.
* i386-opc.tbl: Add FRED, LKGS instructions.
* i386-tbl.h: Regenerated.
|
|
|
|
I noticed a buglet in tui_update_variables:
...
entry = translate (tui_border_kind, tui_border_kind_translate_lrcorner);
if (tui_border_lrcorner != (chtype) entry->value)
{
tui_border_lrcorner = (entry->value < 0) ? ACS_LRCORNER : entry->value;
...
When assigning the new value to tui_border_lrcorner, an entry->value of -1 is
taken into account, but not when comparing to the current value of
tui_border_lrcorner.
Fix this by introducing:
...
int val = (entry->value < 0) ? ACS_LRCORNER : entry->value;
...
and using this in both comparison and assignment.
Tested on x86_64-linux.
|
|
I recently added a 'dap' component to bugzilla, and I filed a few bugs
there. This patch removes the corresponding FIXME comments.
A few such comments still exist. In at least one case, I have a fix
I'll be submitting eventually; in others I think I need to do a bit of
investigation to properly file a bug report.
|
|
|
|
Add a new proc Term::get_line_with_attrs, similar to Term::get_line, that
annotates a tuiterm line with the active attributes.
For instance, the line representing the TUI status window with attribute mode
standout looks like this with Term::get_line:
...
exec No process In: ... L?? PC: ??
...
but like this with Term::get_line_with_attrs:
...
<reverse:1>exec No process In: ... L?? PC: ?? <reverse:0>
...
Also add Term::dump_screen_with_attrs, a Term::dump_screen variant that uses
Term::get_line_with_attrs instead of Term::get_line.
Tested by re-running the TUI test-cases (gdb.tui/*.exp and gdb.python/tui*.exp)
on x86_64-linux.
|
|
Factor out new proc Term::_reset_attrs.
Tested by re-running the TUI test-cases (gdb.tui/*.exp and gdb.python/tui*.exp)
on x86_64-linux.
|
|
Revert value of DT_ENCODING to as it was before commit a7fd118627, and
adjust readelf.
include/
* elf/common.h (DT_ENCODING): Set back to 32.
binutils/
* readelf.c (struct filedata): Don't size dynamic_info array
using DT_ENCODING.
|
|
As a developer it is sometimes useful to know how many times stubs
have been resized. Report the count for users too, in ld --stats.
|
|
|
|
|
|
The fix for pr23686 had a hole in the reloc address sanity check,
the calculation could overflow. Note that stabsize is known to be a
non-zero multiple of 12 so stabsize - 4 can't underflow.
PR 23686
* syms.c (_bfd_stab_section_find_nearest_line): Correct
r->address sanity check.
|
|
I started down the path of attempting to fix
https://sourceware.org/pipermail/binutils/2023-April/127263.html but
decided after a while that I didn't want to mess with this code..
This patch is a just a few things that I thought worth doing, the main
one being reporting of errors up the call chain. The while loop to
for loop change is shamelessly stolen from Oleg.
* coffcode.h (handle_COMDAT): Return bool. Make sec_flags a
flagword*, and adjust to suit. Replace while loop with for
loop. Check isym.n_numaux before reading aux entries. Alloc
coff_comdat_info and name in one call to bfd_alloc. Remove
goto breakloop.
(styp_to_sec_flags): Adjust handle_COMDAT call.
|
|
The tic54x backend provides its own coff_set_arch_mach, but wants to
use the standard coff_set_section_contents. BFD_JUMP_TABLE_WRITE
defines both of these functions, so the code also provides a wrapper
for coff_set_section_contents. This is all quite OK, but I was on a
mission to remove unnecessary declarations in coffcode.h, and on
deleting the one for coff_set_arch_mach ran into a warning about the
function being unused. I could have kept that declaration with its
ATTRIBUTE_UNUSED or written "static bool ATTRIBUTE_UNUSED" on the
definition but the latter is not usual and looks odd to me. So I
had a closer look at tic54x_set_arch_mach and decided the function is
very likely wrong to allow bfd_arch_unknown. Thus the backend should
be using the standard coff_set_arch_mach.
* coff-tic54x.c: Use BFD_JUMP_TABLE_WRITE (coff) in target vecs.
(tic54x_coff_set_arch_mach): Delete.
(tic54x_set_section_contents): Delete.
* coffcode.h: Delete unnecessary forward declarations.
|
|
|
|
I noticed that Frame.older and Frame.newer don't document that they
return None at the ends of the stack. This patch updates the
documentation, and also fixes a somewhat related typo in a comment
that I noticed while digging into this.
Approved-By: Eli Zaretskii <eliz@gnu.org>
|
