DLPX-92903 gdb-python build fails on Ubuntu 24.04 because of deprecated python3-distutils dependency #4
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
PR testsuite/7142 -- old enough to have been converted from Gnats -- points out that test_list_filename_and_function in gdb.base/list.exp has "fails" that are unmatched with passes. This patch cleans this up a little. Co-authored-by: Tom Tromey <[email protected]> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7142
Joel noticed that if the remote dies unexpectedly during a command --
you can simulate this by using "continue" and then killing gdbserver
-- then the CLI will print a new prompt, but MI will not. Later, we
found out that this was also filed in bugzilla as PR mi/23820.
The output looks something like this:
| (gdb)
| cont
| &"cont\n"
| ~"Continuing.\n"
| ^running
| *running,thread-id="all"
| (gdb)
| [... some output from GDB during program startup...]
| =thread-exited,id="1",group-id="i1"
| =thread-group-exited,id="i1"
| &"Remote connection closed\n"
Now, what about that "(gdb)" in the middle?
That prompt comes from this questionable code in
mi-interp.c:mi_on_resume_1:
/* This is what gdb used to do historically -- printing prompt
even if it cannot actually accept any input. This will be
surely removed for MI3, and may be removed even earlier. */
if (current_ui->prompt_state == PROMPT_BLOCKED)
fputs_unfiltered ("(gdb) \n", mi->raw_stdout);
... which seems like something to remove. But maybe the intent here
is that this prompt is sufficient, and MI clients must be ready to
handle output coming after a prompt. On the other hand, if this code
*is* removed, then nothing would print a prompt in this scenario.
Anyway, the CLI and the TUI handle emitting the prompt here by hooking
into gdb::observers::command_error, but MI doesn't install an observer
here.
This patch adds the missing observer and arranges to show the MI
prompt. Regression tested on x86-64 Fedora 34.
It seems like this area could be improved a bit, by having
start_event_loop call the prompt-displaying code directly, rather than
indirecting through an observer. However, I haven't done this.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23820
This commit adds operator+= and operator+ overloads for adding gdb::unique_xmalloc_ptr<char> to a std::string. I could only find 3 places in GDB where this was useful right now, and these all make use of operator+=. I've also added a self test for gdb::unique_xmalloc_ptr<char>, which makes use of both operator+= and operator+, so they are both getting used/tested. There should be no user visible changes after this commit, except when running 'maint selftest', where the new self test is visible.
gdb-add-index may trigger debuginfod's first-use notice. The notice is misleading in this case. It instructs the user to modify .gdbinit in order to permanently enable/disable debuginfod but gdb-add-index invokes gdb with -nx which ignores .gdbinit. Additionally debuginfod is not needed for gdb-add-index since the symbol file is given as an argument and should already be present locally. Fix this by disabling debuginfod when gdb-add-index invokes gdb.
I came across this problem when testing gdb.base/gdb-sigterm.exp
on a machine with a pre-release version of glib-2.34 installed:
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) Recursive internal problem.
FAIL: gdb.base/gdb-sigterm.exp: expect eof #0 (GDB internal error)
Resyncing due to internal error.
ERROR: : spawn id exp11 not open
while executing
"expect {
-i exp11 -timeout 10
-re "Quit this debugging session\\? \\(y or n\\) $" {
send_gdb "n\n" answer
incr count
}
-re "Create..."
("uplevel" body line 1)
invoked from within
"uplevel $body" NONE : spawn id exp11 not open
ERROR: Could not resync from internal error (timeout)
gdb.base/gdb-sigterm.exp: expect eof #0: stepped 9 times
UNRESOLVED: gdb.base/gdb-sigterm.exp: 50 SIGTERM passes
I don't have a problem with the latter ERROR nor the UNRESOLVED
messages. However the first ERROR regarding the exp11 spawn id
not being open is not especially useful.
This commit handles the "Recursive internal problem" case, avoiding
the problematic ERROR shown above.
With this commit in place, the log messages look like this instead:
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) Recursive internal problem.
FAIL: gdb.base/gdb-sigterm.exp: expect eof #15 (GDB internal error)
Resyncing due to internal error.
ERROR: Could not resync from internal error (recursive internal problem)
gdb.base/gdb-sigterm.exp: expect eof #15: stepped 12 times
UNRESOLVED: gdb.base/gdb-sigterm.exp: 50 SIGTERM passes
gdb/testsuite/ChangeLog:
* lib/gdb.exp (gdb_internal_error_resync): Handle "Recursive
internal problem".
…on is encountered. PR 28886 * config.bfd: Update error message for obsolete configurations.
PR 25713 * bfdio.c (_bfd_real_fopen): Fix handling of parhs longer than 260 characters on Windows hosts.
When running the gdb.fortran tests array-slices.exp and lbound-ubound.exp,
the test suite throws several ERRORs on native-gdbserver/-m{32,64},
and native-extended-gdbsever/-m{32,64}:
[on native-extended-gdbserver/-m64]
Running /home/keiths/work/gdb/branches/testsuite-errors/linux/gdb/testsuite/../../../src/gdb/testsuite/gdb.fortran/array-slices.exp ...
ERROR: failed to extract expected results
ERROR: failed to extract expected results
Running /home/keiths/work/gdb/branches/testsuite-errors/linux/gdb/testsuite/../../../src/gdb/testsuite/gdb.fortran/lbound-ubound.exp ...
ERROR: failed to extract expected results for lbound
This occurs because the tests require inferior I/O which we do not have
access to while using these targets.
This patch skips these tests when running on non-native targets.
This is a snafu that I encountered while implementing the previous patch, which attempted to use gdb_is_target_native. This proc and gdb_is_target_remote both rely on gdb_is_target_1, which actually cannot be called without gdb already running. This patch adds appropriate warning comments to these procs and causes gdb_is_target_1 to issue a Tcl error if it is called without a gdb instance already running. This should prevent unwitting callers from using this at the wrong time.
This adds a new read-only attribute gdb.InferiorThread.details, this attribute contains a string, the results of target_extra_thread_info for the thread, or None, if target_extra_thread_info returns nullptr. As the string returned by target_extra_thread_info is unstructured, this attribute is only really useful for echoing straight through to the user, but, if a user wants to write a command that displays the same, or a similar 'Thread Id' to the one seen in 'info threads', then they need access to this string. Given that the string produced by target_extra_thread_info varies by target, there's only minimal testing of this attribute, I check that the attribute can be accessed, and that the return value is either None, or a string.
In Ada, an enum can contain character literals. GNAT encodes these
values in a special way. For example, the Unicode character U+0178
would be represented as 'QW0178' in the DWARF:
<3><112f>: Abbrev Number: 2 (DW_TAG_enumerator)
<1130> DW_AT_name : (indirect string, offset: 0x19ff): QW0178
<1134> DW_AT_const_value : 2
gdb handles this reasonably well, but failed to handle the 'QWW'
encoding, which is used for characters outside the base plane.
Also, while working on this, I noticed that gdb will print the decimal
value for an enum character constant:
(gdb) print Char_X
$2 = 1 'x'
This is a nice feature, IMO, because in this situation the 'x' enum
constant does not have its usual decimal value -- it has the value
that's assigned based on the enumeration type.
However, gdb did not do this when it decided to print the constant
using the bracket notation:
(gdb) print Char_Thorn
$3 = ["de"]
This patch changes gdb to print the decimal value here as well, and to
put the bracket notation in single quotes -- otherwise gdb will be
printing something that it can't then read. Now it looks like:
(gdb) print Char_Thorn
$3 = 4 '["de"]'
Note that gdb can't read longer bracket notations, like the other ones
printed in this test case:
(gdb) print Char_King
$4 = 3 '["01fa00"]'
While I think this is a bug, I plan to fix it separately.
Finally, in the new test case, the copyright dates are chosen this way
because this all started as a copy of an existing test.
As noted in an earlier patch, the Ada lexer does not handle multi-byte bracket sequences. This patch adds support for these for character literals. gdb does not generally seem to handle the Ada wide string types, so for the time being these continue to be excluded -- but an explicit error is added to make this more clear.
I got this warning from py-infthread.c using the Fedora 34 system GCC: ../../binutils-gdb/gdb/python/py-infthread.c:102:30: warning: ‘extra_info’ may be used uninitialized in this function [-Wmaybe-uninitialized] I think this happens because GDB_PY_HANDLE_EXCEPTION expands to an 'if' whose condition is always true -- but GCC can't know this. This patch avoids the warning by adding a harmless initialization.
I found a few spots where filename styling ought to be applied, but is not.
Running mi-exec-run.exp on native-extended-gdbserver/-m{32,64}
causes several Tcl errors to appear. For example,
(gdb)
ERROR: : spawn id exp20 not open
while executing
"expect {
-i exp11 -timeout 10
-i "$inferior_spawn_id"
-re ".*Cannot exec.*Permission denied" {
set saw_perm_error 1
verbose -log "saw..."
("uplevel" body line 1)
invoked from within
"uplevel $body" NONE : spawn id exp20 not open
UNRESOLVED: gdb.mi/mi-exec-run.exp: inferior-tty=separate: mi=separate: force-fail=1: run failure detected (eof)
This is happening because of the way this test is implemented:
while {1} {
gdb_expect {
-i "$inferior_spawn_id"
-re ".*Cannot exec.*Permission denied" {
set saw_perm_error 1
verbose -log "saw mi error"
}
-i "$gdb_spawn_id"
-re "\\^error,msg=\"During startup program exited with code 127" {
set saw_mi_error 1
verbose -log "saw mi error"
}
# and so on
}
}
The first time this loop is executed, `inferior_spawn_id' is valid. When the
first branch of the expect statement is reached, gdbserver has exited, closing
the spawn_id. Since we haven't seen the gdb-side error yet, the loop is executed
again. The first branch now refers to a non-existent spawn_id, leading to the error.
This can be fixed by using exp_continue to loop in expect instead of looping around
expect, which is the approach I have used[1]. Note I've had to update the expected
message for the "During startup..." error message when running with gdbserver.
One other small change I've made is to add a log entry which spills the values of
the two variables, saw_mi_error and saw_perm_error (and updated the log output
for the later). This should make the log output clearer about why the test failed.
With this patch installed, all the ERRORs disappear, leaving previously masked
FAILs (which I have not attempted to fix).
[1] Anyone know why this test doesn't simply use gdb_test_multiple? I can only
assume that it was intentionally written this way, and I've modified the code with
that assumption. I have tested a version using gdb_test_multiple, and that appears
to work fine, too, if that is preferred. [It still employs exp_continue to fix the
spawn_id errors.]
The patch series "gdb: Add basic support for LoongArch" has been merged into master, list Tiezhu Yang as LoongArch maintainer. Signed-off-by: Tiezhu Yang <[email protected]>
In the current code, there is no test result when execute the following commands: $ make check-gdb TESTS="gdb.base/attach-pie-noexec.exp" RUNTESTFLAGS="--target_board=remote-gdbserver-on-localhost" $ make check-gdb TESTS="gdb.base/attach-pie-noexec.exp" RUNTESTFLAGS="--target_board=native-gdbserver" It is better to print explicit test result in can_spawn_for_attach. Signed-off-by: Tiezhu Yang <[email protected]>
If /proc/sys/kernel/yama/ptrace_scope is 1, when execute the test case
gdb.base/attach-pie-noexec.exp without superuser, the gdb.log shows the
following info:
(gdb) attach 6500
Attaching to process 6500
ptrace: Operation not permitted.
(gdb) PASS: gdb.base/attach-pie-noexec.exp: attach
It is obviously wrong, the expected result should be UNSUPPORTED in such
a case.
It is better to make can_spawn_for_attach to return false for this case.
It would have to setup a small test program, compile it to exec, spawn it
and try to attach to it.
With this patch, we can see "Operation not permitted" in the log info,
and then we can do the following processes to test:
(1) set ptrace_scope as 0
$ echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope
$ make check-gdb TESTS="gdb.base/attach-pie-noexec.exp"
(2) use sudo
$ sudo make check-gdb TESTS="gdb.base/attach-pie-noexec.exp"
Additionally, handle the other cases when test with RUNTESTFLAGS=
"--target_board=native-extended-gdbserver".
Signed-off-by: Tiezhu Yang <[email protected]>
…file with incorrectly set build attributes. PR 28848 PR 28859 * elf32-arm.c (elf32_arm_merge_eabi_attributes): If the first input bfd has a Tag_ABI_HardFP_use set to 3 but does not also have TAG_FP_arch set then reset the TAG_ABI_HardFP_use.
PR 21964 * testsuite/ld-elf/pr21964-1a.c: Fix array comparisons. * testsuite/ld-elf/pr21964-1b.c: Likewise. * testsuite/ld-elf/pr21964-1c.c: Likewise. * testsuite/ld-elf/pr21964-2a.c: Likewise. * testsuite/ld-elf/pr21964-2b.c: Likewise. * testsuite/ld-elf/pr21964-3a.c: Likewise.
This reverts commit 48e3e6a. PR 28929 * archive.c (_bfd_get_elt_at_filepos): Don't check thin archive element file size.
PR 25713 * bfdio.c (_bfd_real_fopen): Fix typo.
PR cli/17332, filed around 8 years ago, points out a typo in the docs -- in one example, the command and its output are obviously out of sync. This patch fixes it. I'm checking this in as obvious. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17332
PR build/12440 points out that "make distclean" is broken in gdb. Most of the breakage comes from other projects in the tree, but we can fix some of the issues, which is what this patch does. Note that the yacc output files, like c-exp.c, are left alone. In a source distribution, these are included in the tarball, and if the user builds in-tree, we would not want to remove them. While that seems a bit obscure, it seems to me that "distclean" is only really useful for in-tree builds anyway -- out-of-tree I simply delete the entire build directory and start over. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=12440
This moves the copyright code from gdbarch.py to a new Python source file, gdbcopyright.py. The function in this file will find the copyright dates by scanning the calling script. This will be reused in a future patch. This involved minor changes to the output of gdbarch.py. Also, I've updated copyright.py to remove the reference to gdbarch.sh. We don't need to mention gdbarch.py there, either.
The following behaviour was observed in GDB: (gdb) show remote X-packet Support for the `p' packet is auto-detected, currently unknown. Note the message mentions the 'p' packet. This is a regression since this commit: commit 8579fd1 Date: Mon Nov 8 14:58:46 2021 +0000 gdb/gdbsupport: make xstrprintf and xstrvprintf return a unique_ptr Before this commit the behaviour was: (gdb) show remote X-packet Support for the `X' packet is auto-detected, currently unknown. The problem was caused by a failed attempt to ensure that some allocated strings were deleted when GDB exits. The code in the above commit attempted to make use of 'static' to solve this problem, however, the solution was just wrong. In this new commit I instead allocate a static vector into which all the allocated strings are stored, this ensures the strings are released when GDB exits (which makes output from tools like valgrind cleaner), but each string within the vector can be unique, which fixes the regression.
After this commit: commit d08cbc5 Date: Wed Dec 22 12:57:44 2021 +0000 gdb: unbuffer all input streams when not using readline Issues were reported with some MS-Windows hosts, see the thread starting here: https://sourceware.org/pipermail/gdb-patches/2022-March/187004.html Filed in bugzilla as: PR mi/29002 The problem seems to be that calling setbuf on terminal file handles is not always acceptable, see this mail for more details: https://sourceware.org/pipermail/gdb-patches/2022-April/187310.html This commit does two things, first moving the setbuf calls out of gdb_readline_no_editing_callback so that we don't end up calling setbuf so often. Then, for MS-Windows hosts, we don't call setbuf for terminals, this appears to resolve the issues that have been reported. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29002
This imports the gnulib patches that were mentioned by Eli. I created the patches from gnulib git, ran them through filterdiff, and then applied them using update-gnulib.sh's patch-applying facility. I think the patches are either obviously Windows-specific or harmless, but I encourage you to look for yourself. I tested by rebuilding on x86-64 Fedora 34, and also using the Fedora mingw cross toolchain.
This commit changes gdb/version.in to 12.1.
If two types share identical pointers, we don't need to check typedefs before comparing the result.
Routine print operations end up getting encoding exceptions since the default encoding is ascii. Most systems are using utf-8 now so let's use that instead. This is a hack and we should be looking at the locale. Signed-off-by: Jeff Mahoney <[email protected]>
The bound_flag_evaluated flag will be set when a dynamic type is evaluated as a static type. If the high range is PROP_UNDEFINED, nothing will be changed when it's evaluated, but the equality check will still fail. This makes it impossible to compare types in Python code if the type contains a zero-length array. Acked-by: Jeff Mahoney <[email protected]>
Acked-by: Jeff Mahoney <[email protected]>
gdbpy_lookup_symbol refuses to perform a lookup without a valid block. If no block is passed, we look up the block using the selected frame. If there is no selected frame, we return an error. Since a frame isn't required to lookup objects like static functions and variables, we should be able to complete the lookup without a block. This patch allows us to accept block=None to proceed with the lookup without a block. This allows us to lookup static symbols directly from python rather than using gdb.eval_and_parse.
gdb.lookup_type already handles an absent block parameter as NULL. It should also accept None as NULL, allowing callers to avoid jumping through hoops to make unqualified lookups in a generic way. Signed-off-by: Jeff Mahoney <[email protected]>
This patch adds a new gdb.MinSymbol object to export the minimal_symbol interface. These objects can be resolved using a new gdb.lookup_minimal_symbol call.
In order for the python target to handle fetch_registers, we'll need access to the register descriptor.
This object will expose an API for providing target operations from a Python Interface object Based on an initial implementation by Kieran Bingham <[email protected]>. Signed-off-by: Jeff Mahoney <[email protected]>
When loading objfile files, it's useful to determine whether the caller needs to locate and load separate debuginfo. Inside gdb, this is keyed off of has_symbols(), so let's export that via Python. Signed-off-by: Jeff Mahoney <[email protected]>
Internally, gdb differentiates between exceptions but those differentiations are lost when crossing into Python code. Client code can make use of the knowledge that a value is unavailable. Signed-off-by: Jeff Mahoney <[email protected]>
Type's richcompare method uses types_deeply_equal which exhaustively compares the type, including through pointers. For projects with large, linked structures this can make the comparison time consuming. Looking at the GDB code, types_equal is called more frequently than types_deeply_equal, so this commit changes the regular tp_richcompare ==/!= comparison to use types_equal and adds a new is_deeply_equal method to gdb.Type.
This target implements some basic semantic debugging that should apply to most kernels. For now it just relocates the kernel and populates the thread list for handling by a derived target written in Python. Things that are slow to do in Python (like iteration of big lists, etc) should be implemented here in helpers.
Reasoning: The copyrights will be included the debian packages and can be scanned on a deployed VM by Delphix's automation.
…p requiring python 3.6 PR URL: https://www.github.com/delphix/gdb-python/pull/4
palash-gandhi
force-pushed
the
dlpx/pr/palash-gandhi/2a493b32-a354-46fc-a090-ded915c47b14
branch
from
37ae452 to
98170cd
Compare
…ed python3-distutils dependency
palash-gandhi
force-pushed
the
dlpx/pr/palash-gandhi/2a493b32-a354-46fc-a090-ded915c47b14
branch
from
135b515 to
a0f6917
Compare
palash-gandhi
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem
Delphix's
gdb-pythonhasn't been updated from upstream since 2019. It's a fork of this repo: https://github.com/crash-python/gdb-python/. Building this old code is revealing compilation failures on 24.04, see my attempts here: https://ops-jenkins.eng-tools-prd.aws.delphixcloud.com/job/linux-pkg/job/os-upgrade/job/build-package/job/gdb-python/job/pre-push/I found that while the
masterbranch of the upstream repo hasn't seen any activity in the last 5 years, https://github.com/crash-python/crash-python references a different branch ofgdb-pythoncalled gdb-12.1-target which has newer code.Solution
I decided to try and build the
gdb-12.1-targetbranch, along with a few Delphix commits on top of that after hitting issues when building the old branch. This is a PR demonstrating the process of updating this repo and will likely require me to force-push.This will help explain the commit log:
As you can see,
gdb-12.1-target's tip isf0c0cb. All commits on top of that are Delphix commits related to Debian packaging except for the latest commit, which I added and that diff can be found here: a0f6917This commit essentially removes the deprecated
python3-distutils, addslibkdumpfile-devas a build dependency, replacesautoconf's version to downgrade it to useautoconf2.69(as required by the package) and also removes a check that fails even after modifying the scripts to useautoconf2.69. I do not think we will update this repo frequently so as long as this code builds & runs, such changes are acceptable.Testing Done
https://ops-jenkins.eng-tools-prd.aws.delphixcloud.com/job/linux-pkg/job/os-upgrade/job/build-package/job/gdb-python/job/pre-push/16/