It's sometimes useful to temporarily set some gdb parameter from
Python. Now that the 'endian' crash is fixed, and now that the
current language is no longer captured by the Python layer, it seems
reasonable to add a helper function for this situation.
This adds a new gdb.with_parameter function. This creates a context
manager which temporarily sets some parameter to a specified value.
The old value is restored when the context is exited. This is most
useful with the Python "with" statement:
with gdb.with_parameter('language', 'ada'):
... do Ada stuff
This also adds a simple function to set a parameter,
gdb.set_parameter, as suggested by Andrew.
This is PR python/10790.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=10790
While looking into the language-capturing issue, I found another way
to crash gdb using parameters from Python:
(gdb) python print(gdb.parameter('endian'))
(This is related to PR python/12188, though this patch isn't going to
fix what that bug is really about.)
The problem here is that the global variable that underlies the
"endian" parameter is initialized to NULL. However, that's not a
valid value for an "enum" set/show parameter.
My understanding is that, in gdb, an "enum" parameter's underlying
variable must have a value that is "==" (not just strcmp-equal) to one
of the values coming from the enum array. This invariant is relied on
in various places.
I started this patch by fixing the problem with "endian". Then I
added some assertions to add_setshow_enum_cmd to try to catch other
problems of the same type.
This patch fixes all the problems that I found. I also looked at all
the calls to add_setshow_enum_cmd to ensure that they were all
included in the gdb I tested. I think they are: there are no calls in
nat-* files, or in remote-sim.c; and I was trying a build with all
targets, Python, and Guile enabled.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=12188
Currently, gdb's Python layer captures the current architecture and
language when "entering" Python code. This has some undesirable
effects, and so this series changes how this is handled.
First, there is code like this:
gdbpy_enter enter_py (python_gdbarch, python_language);
This is incorrect, because both of these are NULL when not otherwise
assigned. This can cause crashes in some cases -- I've added one to
the test suite. (Note that this crasher is just an example, other
ones along the same lines are possible.)
Second, when the language is captured in this way, it means that
Python code cannot affect the current language for its own purposes.
It's reasonable to want to write code like this:
gdb.execute('set language mumble')
... stuff using the current language
gdb.execute('set language previous-value')
However, this won't actually work, because the language is captured on
entry. I've added a test to show this as well.
This patch changes gdb to try to avoid capturing the current values.
The Python concept of the current gdbarch is only set in those few
cases where a non-default value is computed or needed; and the
language is not captured at all -- instead, in the cases where it's
required, the current language is temporarily changed.
Make bfd.stamp depend on source bfd.texi to avoid regenerating
doc/bfd.info for each make run.
PR binutils/28807
* Makefile.in: Regenerate.
* doc/local.mk (%D%/bfd.stamp): Depend on $(srcdir)/%D%/bfd.texi.
1. Compute the desired PT_GNU_RELRO segment base and find the maximum
section alignment of sections starting from the PT_GNU_RELRO segment.
2. Find the first preceding load section.
3. Don't add the 1-page gap between the first preceding load section and
the relro segment if the maximum page size >= the maximum section
alignment. Align the PT_GNU_RELRO segment first. Subtract the maximum
page size if therer is still a 1-page gap.
PR ld/28743
PR ld/28819
* ldlang.c (lang_size_relro_segment_1): Rewrite.
* testsuite/ld-x86-64/pr28743-1.d: New file.
* testsuite/ld-x86-64/pr28743-1.s: Likewise.
* testsuite/ld-x86-64/x86-64.exp: Run pr28743-1.
When running the testsuite, I have lines similar to the following in the
gdb.sum file:
~~~
PASS: gdb.base/break-interp.exp: ldprelink=NO: ldsepdebug=NO: first backtrace: p /x 0x7f283d2f0fd1
...
PASS: gdb.base/break-interp.exp: ldprelink=NO: ldsepdebug=NO: binprelink=NO: binsepdebug=NO: binpie=NO: INNER: first backtrace: p /x 0x7f00de0317a5
...
~~~
The address part of the command might change between execution of the
test, which adds noise to a diff between two .sum files.
This patch changes to test name to "p /x $pc" in order to have constant
test name.
Tested on x86_64-Linux.
Change-Id: I973c1237a084dd6d424276443cbf0920533c9a21
linux-thread-db.c has a bit of unusual code that unconditionally
prints a message, but decides whether to print to gdb_stdout or
gdb_stdlog based on a debug flag. It seems better to me to simply
always print this; and this is the only spot in gdb where we
conditionally pass gdb_stdout to one of the f*_unfiltered functions.
In an earlier version of the pager rewrite series, it was important to
audit unfiltered output calls to see which were truly necessary.
This is no longer necessary, but it still seems like a decent cleanup
to change calls to avoid explicitly passing gdb_stdout. That is,
rather than using something like fprintf_unfiltered with gdb_stdout,
the code ought to use plain printf_unfiltered instead.
This patch makes this change. I went ahead and converted all the
_filtered calls I could find, as well, for the same clarity.
This changes the time / space / symtab per-command statistics code to
send its output to gdb_stdlog rather than gdb_stdout. This seems
slightly more correct to me.
The gold subdir doesn't actually have a manual, so this hack doesn't
do anything. Plus the automake cygnus option was removed years ago
by Simon in d0ac1c4488 ("Bump to autoconf 2.69 and
automake 1.15.1"). So delete it here.
This was needed when gas was using the automake cygnus option, but
this was removed years ago by Simon in d0ac1c4488
("Bump to autoconf 2.69 and automake 1.15.1"). So delete it here.
The info pages are already & still installed by default w/out it.
The description of the Window.click method doesn't mention where the
coordinates are anchored (it's the top left corner).
This minor tweak just mentions this point.
A few Rust operations do a bit of work in their 'evaluate' functions
and then call another function -- but are also the only caller. This
patch simplifies this code by removing the extra layer.
Tested on x86-64 Fedora 34. I'm checking this in.
Rename bfdlib_LTLIBRARIES and bfdinclude_HEADERS to lib_LTLIBRARIES and
include_HEADERS to fix the missing installed library and header files in
bfd caused by
commit bd32be01c9
Author: Mike Frysinger <vapier@gentoo.org>
Date: Fri Dec 3 00:23:20 2021 -0500
bfd: merge doc subdir up a level
PR binutils/28807
* Makefile.am (bfdlib_LTLIBRARIES): Renamed to ...
(lib_LTLIBRARIES): This.
(bfdinclude_HEADERS): Renamed to ...
(include_HEADERS): This.
* Makefile.in: Regenerate.
* doc/local.mk (install): Removed.
This is a generated file name from a correspondingly named C file.
Rename it to avoid unique build rules since there's no difference
to the generated manual.
PR 28793:
The alignment may be removed in linker. We need to create new frag after
alignment to prevent the assembler from computing static offsets.
gas/
* config/tc-riscv.c (riscv_frag_align_code): Create new frag.
Fixes:
CXX ser-mingw.o
/home/simark/src/binutils-gdb/gdb/ser-mingw.c: In function ‘int pipe_windows_open(serial*, const char*)’:
/home/simark/src/binutils-gdb/gdb/ser-mingw.c:870:3: error: ‘gdb_argv’ was not declared in this scope
870 | gdb_argv argv (name);
| ^~~~~~~~
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28802
Change-Id: I7f3e8ec5f9ca8582d587545fdf6b69901259f199
I noticed two places in the docs where we appear to be missing @r.
makeinfo seems to do the correct things despite these being
missing (at least, I couldn't see any difference in the pdf or info
output), but it doesn't hurt to have the @r in place.
We found a case where --gc-sections can cause gdb to set an invalid
breakpoint. In the included test case, gdb will set a breakpoint with
two locations, one of which is 0x0.
The code in lnp_state_machine::check_line_address is intended to
filter out this sort of problem, but in this case, the entire CU is
empty, causing unrelocated_lowpc==0x0 -- which circumvents the check.
It seems to me that if a CU is empty like this, then it is ok to
simply ignore the line table, as there won't be any locations anyway.
Add `set print array-indexes' handling for Fortran arrays. Currently
the setting is ignored and indices are never shown.
Keep track of the most recent index handled so that any outstanding
repeated elements printed when the limit set by `set print elements' is
hit have the correct index shown.
Output now looks like:
(gdb) set print array-indexes on
(gdb) print array_1d
$1 = ((-2) = 1, (-1) = 1, (0) = 1, (1) = 1, (2) = 1)
(gdb) set print repeats 4
(gdb) set print elements 12
(gdb) print array_2d
$2 = ((-2) = ((-2) = 2, <repeats 5 times>) (-1) = ((-2) = 2, <repeats 5 times>) (0) = ((-2) = 2, (-1) = 2, ...) ...)
(gdb)
for a 5-element vector and a 5 by 5 array filled with the value of 2.
Add `set print repeats' tests for C/C++ arrays, complementing one for
Fortran arrays and covering the different interpretation of the `set
print elements' setting in particular where the per-dimension count of
the elements handled is matched against the trigger rather than the
total element count as with Fortran arrays.
Implement `set print repeats' handling for Fortran arrays. Currently
the setting is ignored and always treated as if no limit was set.
Unlike the generic array walker implemented decades ago the Fortran one
is a proper C++ class. Rather than trying to mimic the old walker then,
which turned out a bit of a challenge where interacting with the `set
print elements' setting, write it entirely from scratch, by adding an
extra specialization handler method for processing dimensions other than
the innermost one and letting the specialization class call the `walk_1'
method from the handler as it sees fit. This way repeats can be tracked
and the next inner dimension recursed into as a need arises only, or
unconditionally in the base class.
Keep track of the dimension number being handled in the class rather as
a parameter to the walker so that it does not have to be passed across
by the specialization class.
Use per-dimension element count tracking, needed to terminate processing
early when the limit set by `set print elements' is hit. This requires
extra care too where the limit triggers exactly where another element
that is a subarray begins. In that case rather than recursing we need
to terminate processing or lone `(...)' would be printed. Additionally
if the skipped element is the last one in the current dimension we need
to print `...' by hand, because `continue_walking' won't print it at the
upper level, because it can see the last element has already been taken
care of.
Preserve the existing semantics of `set print elements' where the total
count of the elements handled is matched against the trigger level which
is unlike with the C/C++ array printer where the per-dimension element
count is used instead.
Output now looks like:
(gdb) set print repeats 4
(gdb) print array_2d
$1 = ((2, <repeats 5 times>) <repeats 5 times>)
(gdb) set print elements 12
(gdb) print array_2d
$2 = ((2, <repeats 5 times>) (2, <repeats 5 times>) (2, 2, ...) ...)
(gdb)
for a 5 by 5 array filled with the value of 2.
Amend existing test cases accordingly that rely on the current incorrect
behavior and explicitly request that there be no limit for printing
repeated elements there.
Add suitable test cases as well covering sliced arrays in particular.
Co-Authored-By: Andrew Burgess <andrew.burgess@embecosm.com>
