https://sourceware.org/bugzilla/show_bug.cgi?id=31524 Tom Tromey <tromey at sourceware dot org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Target Milestone|--- |15.1 Resolution|--- |FIXED --- Comment #15 from Tom Tromey <tromey at sourceware dot org> --- Fixed. -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=31524 --- Comment #14 from Sourceware Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Tom Tromey <tromey@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=edada1692cc4558138756eea99532d83b7b894e0 commit edada1692cc4558138756eea99532d83b7b894e0 Author: Tom Tromey <tom@tromey.com> Date: Wed Mar 27 10:34:46 2024 -0600 Make pascal_language::print_type handle varstring==nullptr PR gdb/31524 points out a crash when pascal_language::print_type is called with varstring==nullptr. This crash is a regression arising from the printf/pager rewrite -- that indirectly removed a NULL check from gdb's "puts". This patch instead fixes the problem by adding a check to print_type. Passing nullptr here seems to be expected in other places (e.g., there is a call to type_print like this in expprint.c), and other implementations of this method (or related helpers) explicitly check for NULL. I didn't write a test case for this because it seemed like overkill for a Pascal bug that only occurs with -i=mi. However, if you want one, let me know and I will do it. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31524 Approved-By: John Baldwin <jhb@FreeBSD.org> -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=31522 --- Comment #14 from Tom Tromey <tromey at sourceware dot org> --- (In reply to Pedro Alves from comment #3) > > This seems reasonable to me, but maybe it is a change if > > you exit the TUI and then re-enter it in some scenario. > > Personally I'm not too concerned about this. > > I do that frequently with c-x,a. I'll be debugging gdb, and > stepping/nexting with the TUI enabled, then decide I'm at the right spot the > program that I want to inspect variables or run a command [...] What I meant here is that I was wondering if there are cases where "tui disable" + "tui enable" would preserve the state of the source window, even if there were changes (like stepping, whatever) in between. I tend to think that it is fine for "tui enable" to just recenter the selected frame's line -- but is that ok with you? -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=31522 --- Comment #13 from Pedro Alves <pedro at palves dot net> --- Filed PR tui/31570 for those. -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=31570 Bug ID: 31570 Summary: The TUI should center highlighted source line in more cases Product: gdb Version: unknown Status: NEW Severity: normal Priority: P2 Component: tui Assignee: unassigned at sourceware dot org Reporter: pedro at palves dot net Target Milestone: --- Forking from PR tui/31522: Tom de Vries wrote: > Pedro Alves wrote: > > IMO, it would be nice if we centered in more cases, like after "frame", for > > example, or before running the program and you enable the TUI (TUI shows > > main), but those are not regressions AFAICT. > > Agreed. I played a bit with 'gdb -q a.out -tui' vs 'gdb -q -a.out -ex "tui > enable"', where there's also a difference in behaviour. -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=31522 Tom de Vries <vries at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |NEW --- Comment #12 from Tom de Vries <vries at gcc dot gnu.org> --- (In reply to Pedro Alves from comment #8) > Thanks! Indeed, I played a bit with that patch, and the centering seems to > work just like it did before, in all the use cases I threw at it. Tromey's > change is also needed for the highlight. > Thanks for trying it out (maybe consider adding a tested-by tag to the submitted patch?). > The old code did: > > - if (deprecated_safe_get_selected_frame ()) > - tui_show_frame_info (deprecated_safe_get_selected_frame ()); > - else > - tui_display_main (); > > and I wondered whether we need that tui_display_main call, but I couldn't > spot a behavior difference without it. I tried enabling the TUI before > starting the program, with and without using "list foo" to move the current > source position elsewhere. > Ok, understood. > IMO, it would be nice if we centered in more cases, like after "frame", for > example, or before running the program and you enable the TUI (TUI shows > main), but those are not regressions AFAICT. Agreed. I played a bit with 'gdb -q a.out -tui' vs 'gdb -q -a.out -ex "tui enable"', where there's also a difference in behaviour. Anyway, since this is a regression fix, I went with this minimal fix, and added a comment at the fix that we could try to improve the fix. -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=31522 Tom de Vries <vries at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|FIXED |--- Status|RESOLVED |REOPENED --- Comment #11 from Tom de Vries <vries at gcc dot gnu.org> --- Oops, didn't mean to close it. -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=31522 Tom de Vries <vries at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Tom de Vries <vries at gcc dot gnu.org> --- https://sourceware.org/pipermail/gdb-patches/2024-March/207641.html -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=31569 Bug ID: 31569 Summary: "finish" command loses typedef Product: gdb Version: HEAD Status: NEW Severity: normal Priority: P2 Component: gdb Assignee: unassigned at sourceware dot org Reporter: tromey at sourceware dot org Target Milestone: --- gcc has a "tree" typedef and a pretty-printer that recognizes it. While debugging gcc, I used "finish" and got: (gdb) fini Run till exit from #0 get_global_context () at ../../gcc/gcc/ada/gcc-interface/utils.cc:812 0x0000000001b0e800 in gnat_push_namespace (ns=<namespace_decl 0x7fffe9c32980 pck>) at ../../gcc/gcc/ada/gcc-interface/utils.cc:820 Value returned is $26 = (tree_node *) 0x7fffe9c0c168 However, this function is actually defined as: static tree get_global_context (void) { ... If I cast that value back to a tree, I get the pretty-printer output: (gdb) p (tree) $ $28 = <translation_unit_decl 0x7fffe9c0c168 pck.ads> I think this is a bug -- "finish" should result in a value that uses the function's declared return type, so that pretty-printers can see what they expect. Arguably I guess this is a bug in gcc as well, since it should probably recognize the underlying type and not the typedef. -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=31568 Bug ID: 31568 Summary: GDB fails with raw clone syscalls Product: gdb Version: 12.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: threads Assignee: unassigned at sourceware dot org Reporter: rvansa at azul dot com Target Milestone: --- I am trying to debug into CRIU (https://criu.org/), though I have seen this problem in other instances where the clone/clone3 syscall is invoked directly. When this is executed GDB prints ``` Cannot find user-level thread for LWP 341734: generic error ``` After this, `info thread` won't show the new thread. It is marked as being traced (but I guess that all threads from traced process show that). ``` $ cat /proc/341519/task/341734/status Name: java Umask: 0002 State: t (tracing stop) Tgid: 341519 Ngid: 0 Pid: 341734 PPid: 341503 TracerPid: 341503 ... ``` I can switch back to the original thread using `thread 1` but is is marked as running and I cannot interrupt it (neither using ctrl+C nor with signal SIGINT). -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=31522 --- Comment #9 from Tom de Vries <vries at gcc dot gnu.org> --- Created attachment 15440 --> https://sourceware.org/bugzilla/attachment.cgi?id=15440&action=edit tentative patch including test-case -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=31522 --- Comment #8 from Pedro Alves <pedro at palves dot net> --- Thanks! Indeed, I played a bit with that patch, and the centering seems to work just like it did before, in all the use cases I threw at it. Tromey's change is also needed for the highlight. The old code did: - if (deprecated_safe_get_selected_frame ()) - tui_show_frame_info (deprecated_safe_get_selected_frame ()); - else - tui_display_main (); and I wondered whether we need that tui_display_main call, but I couldn't spot a behavior difference without it. I tried enabling the TUI before starting the program, with and without using "list foo" to move the current source position elsewhere. IMO, it would be nice if we centered in more cases, like after "frame", for example, or before running the program and you enable the TUI (TUI shows main), but those are not regressions AFAICT. -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=31522 --- Comment #7 from Tom de Vries <vries at gcc dot gnu.org> --- I investigated a bit, by setting a breakpoint on tui_source_window::set_contents, and observing what sal.line is used. With commit ee1e9bbb513^, we have (for the "tui enable" command): - sal.line == 6 (set by tui_source_window_base::rerender) - sal.line == 0 (set by tui_update_source_windows_with_addr) - sal.line == 2 (set by tui_source_window::maybe_update) With commit ee1e9bbb513 (as well as with the fix of comment 4), we have: - sal.line == 6 (set by tui_source_window_base::rerender) The desired behaviour of centering on a source line is only present in tui_source_window::maybe_update. Duplicating that functionality in tui_source_window_base::rerender: ... diff --git a/gdb/tui/tui-winsource.c b/gdb/tui/tui-winsource.c index 52c0b5b69a4..c140e9053be 100644 --- a/gdb/tui/tui-winsource.c +++ b/gdb/tui/tui-winsource.c @@ -482,6 +482,10 @@ tui_source_window_base::rerender () struct symtab *s = find_pc_line_symtab (get_frame_pc (frame)); if (this != TUI_SRC_WIN) find_line_pc (s, cursal.line, &cursal.pc); + int start_line = (cursal.line - ((height - box_size ()) / 2)) + 1; + if (start_line <= 0) + start_line = 1; + cursal.line = start_line; update_source_window (gdbarch, cursal); } else ... gives us the desired centering. It passes the TUI tests. -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=31450 Tom de Vries <vries at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |15.1 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> --- Fixed. -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=31451 Tom de Vries <vries at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |15.1 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> --- Fixed. -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=31450 --- Comment #2 from Sourceware Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Tom de Vries <vries@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=4ef6173d2dfeafd33deedf7ce0d384cfbcf1170d commit 4ef6173d2dfeafd33deedf7ce0d384cfbcf1170d Author: Tom de Vries <tdevries@suse.de> Date: Thu Mar 28 08:26:31 2024 +0100 [gdb/testsuite] Fix gdb.base/ending-run.exp on manjaro linux On aarch64-linux, using the manjaro linux distro, I run into: ... (gdb) next^M 32 }^M (gdb) next^M 0x0000fffff7d67b80 in ?? () from /usr/lib/libc.so.6^M (gdb) FAIL: gdb.base/ending-run.exp: step out of main ... What happens here is described in detail in this clause: ... -re "0x.*\\?\\? \\(\\) from /lib/powerpc.*$gdb_prompt $" { # This case occurs on Powerpc when gdb steps out of main and the # needed debug info files are not loaded on the system, preventing # GDB to determine which function it reached (__libc_start_call_main). # Ideally, the target system would have the necessary debugging # information, but in its absence, GDB's behavior is as expected. ... } ... but the clause only matches for powerpc. Fix this by: - making the regexp generic enough to also match /usr/lib/libc.so.6, and - updating the comment to not mention powerpc. Tested on aarch64-linux. PR testsuite/31450 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31450 -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=31451 --- Comment #2 from Sourceware Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Tom de Vries <vries@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=a26b7d06eb20bf8c83c9204a398c3444b5c28ddb commit a26b7d06eb20bf8c83c9204a398c3444b5c28ddb Author: Tom de Vries <tdevries@suse.de> Date: Thu Mar 28 08:26:31 2024 +0100 [gdb/testsuite] Fix test-case gdb.threads/attach-stopped.exp on manjaro linux When running test-case gdb.threads/attach-stopped.exp on aarch64-linux, using the manjaro linux distro, I get: ... (gdb) thread apply all bt^M ^M Thread 2 (Thread 0xffff8d8af120 (LWP 278116) "attach-stopped"):^M #0 0x0000ffff8d964864 in clock_nanosleep () from /usr/lib/libc.so.6^M #1 0x0000ffff8d969cac in nanosleep () from /usr/lib/libc.so.6^M #2 0x0000ffff8d969b68 in sleep () from /usr/lib/libc.so.6^M #3 0x0000aaaade370828 in func (arg=0x0) at attach-stopped.c:29^M #4 0x0000ffff8d930aec in ?? () from /usr/lib/libc.so.6^M #5 0x0000ffff8d99a5dc in ?? () from /usr/lib/libc.so.6^M ^M Thread 1 (Thread 0xffff8db62020 (LWP 278111) "attach-stopped"):^M #0 0x0000ffff8d92d2d8 in ?? () from /usr/lib/libc.so.6^M #1 0x0000ffff8d9324b8 in ?? () from /usr/lib/libc.so.6^M #2 0x0000aaaade37086c in main () at attach-stopped.c:45^M (gdb) FAIL: gdb.threads/attach-stopped.exp: threaded: attach2 to stopped bt ... The problem is that the test-case expects to see start_thread: ... gdb_test "thread apply all bt" ".*sleep.*start_thread.*" \ "$threadtype: attach2 to stopped bt" ... but lack of symbols makes that impossible. Fix this by allowing " in ?? () from " as well. Tested on aarch64-linux. PR testsuite/31451 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31451 -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=17934 Sam James <sam at gentoo dot org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sam at gentoo dot org -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=8684 Sam James <sam at gentoo dot org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sam at gentoo dot org -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=31522 --- Comment #6 from Tom Tromey <tromey at sourceware dot org> --- Thank you for bisecting that. I was hoping the commit would be a bit more enlightening than it turned out to be, like I don't immediately see the connection. -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=31566 --- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> --- I also saw: ... # Return 1 if this target is an aarch64, either lp64 or ilp32. proc is_aarch64_target {} { if { ![istarget "aarch64*-*-*"] } { return 0 } return [expr ![is_aarch32_target]] } ... I wonder what config.guess prints on an aarch64 ilp32 target. Debian seems to have a port ( https://wiki.debian.org/Arm64ilp32Port ). -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=31566 --- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> --- (In reply to Tom de Vries from comment #2) > (In reply to Tom de Vries from comment #1) > > I'll try to run this in an armhf container on an aarch64-linux system. > > Turns out that one identifies as armv8l-unknown-linux-gnueabihf. > > Which means that is_aarch32_target returns true because istarget "arm*-*-*" > matches. So, is_aarch32_target could be simplified to: ... diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp index d48ea37c0cc..46f8e36ef4d 100644 --- a/gdb/testsuite/lib/gdb.exp +++ b/gdb/testsuite/lib/gdb.exp @@ -3647,21 +3647,8 @@ proc is_x86_64_m64_target {} { # Return 1 if this target is an arm or aarch32 on aarch64. gdb_caching_proc is_aarch32_target {} { - if { [istarget "arm*-*-*"] } { - return 1 - } - - if { ![istarget "aarch64*-*-*"] } { - return 0 - } - - set list {} - foreach reg \ - {r0 r1 r2 r3} { - lappend list "\tmov $reg, $reg" - } - - return [gdb_can_simple_compile aarch32 [join $list \n]] + # Aarch32 on aarch64 is classified as armv8l. + return [istarget "arm*-*-*"] } # Return 1 if this target is an aarch64, either lp64 or ilp32. ... -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=31565 Tom Tromey <tromey at sourceware dot org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|unassigned at sourceware dot org |tromey at sourceware dot org Last reconfirmed| |2024-03-27 CC| |tromey at sourceware dot org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Tom Tromey <tromey at sourceware dot org> --- I am testing a patch. -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=31524 Tom Tromey <tromey at sourceware dot org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|unassigned at sourceware dot org |tromey at sourceware dot org --- Comment #13 from Tom Tromey <tromey at sourceware dot org> --- https://sourceware.org/pipermail/gdb-patches/2024-March/207606.html -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=31566 Tom de Vries <vries at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|[gdb/testsuite] |[gdb/testsuite] |is_aarch32_target return |is_aarch32_target contains |false on aarch32 |dead code -- You are receiving this mail because: You are on the CC list for the bug.