public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
* [Bug rust/31079] New: Rustc test not hitting bp as expected for 1.73 or greater versions
@ 2023-11-21  8:21 abdul.basitijaz at gmail dot com
  2023-11-21 22:41 ` [Bug rust/31079] " tromey at sourceware dot org
  2023-11-21 22:41 ` sam at gentoo dot org
  0 siblings, 2 replies; 3+ messages in thread
From: abdul.basitijaz at gmail dot com @ 2023-11-21  8:21 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=31079

            Bug ID: 31079
           Summary: Rustc test not hitting bp as expected for 1.73 or
                    greater versions
           Product: gdb
           Version: HEAD
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: rust
          Assignee: unassigned at sourceware dot org
          Reporter: abdul.basitijaz at gmail dot com
  Target Milestone: ---

For the RUSTC program given below it is not hitting the breakpoint as expected
and also not showing the expected local value when using Fedora 37 which has
rustc version "Fedora 1.73.0-1.fc37" while it works fine for Ubuntu22 which has
version "1.66.1". Suspected issue might be some rustc compile option needed in
gdb testsuite compilation function or otherwise rustc compiler issue.

Reproducer:
Set a breakpoint at line # 4 and 3 then after running it instead of hitting
breakpoint first at line 3 it hits the line 4. So "info local _x" should have
shown _x value 12 at line # 4 but instead 0 is shown.

1: fn main() {
2:     let _x = 5;
3:     let _x = _x + 7;
4:     let _y = 8;       // set breakpoint here
5: }

Compilation command:
rustc var_reuse.rs -C debuginfo=0 -C opt-level=0 -g -o var_reuse

Failed GDB output from Fedora 37:
(gdb) b 3
Breakpoint 1 at 0x8654: file var_reuse.rs, line 3.
(gdb) b 4
Breakpoint 2 at 0x864c: file var_reuse.rs, line 4.
(gdb) r
Starting program: var_reuse

Breakpoint 2, var_reuse::main () at var_reuse.rs:4
4           let _y = 8;       // set breakpoint here
(gdb) info local _x
_x = 0
(gdb) c
Continuing.
Breakpoint 1, var_reuse::main () at var_reuse.rs:3
3           let _x = _x + 7;
(gdb) c
Continuing.
[Inferior 1 (process 228527) exited normally]

Expected Output from Ubuntu22:

(gdb) b 3
Breakpoint 1 at 0x83ab: file var_reuse.rs, line 3.
(gdb) b 4
Breakpoint 2 at 0x83b3: file var_reuse.rs, line 4.
(gdb) r
Starting program: var_reuse
...
Breakpoint 1, var_reuse::main () at var_reuse.rs:3
3           let _x = _x + 7;
(gdb) info local _x
_x = 5
(gdb) c
Continuing.

Breakpoint 2, var_reuse::main () at var_reuse.rs:4
4           let _y = 8;       // set breakpoint here
(gdb) info local _x
_x = 12
(gdb) c
Continuing.
[Inferior 1 (process 5898) exited normally]

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Bug rust/31079] Rustc test not hitting bp as expected for 1.73 or greater versions
  2023-11-21  8:21 [Bug rust/31079] New: Rustc test not hitting bp as expected for 1.73 or greater versions abdul.basitijaz at gmail dot com
@ 2023-11-21 22:41 ` tromey at sourceware dot org
  2023-11-21 22:41 ` sam at gentoo dot org
  1 sibling, 0 replies; 3+ messages in thread
From: tromey at sourceware dot org @ 2023-11-21 22:41 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=31079

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org

--- Comment #1 from Tom Tromey <tromey at sourceware dot org> ---
With git master, info locals shows both variables:

(gdb) info local _x
_x = 0
_x = 5

"_x = 0" is wrong but at the same time, gdb is just using
the location expression the compiler gave it.

I see rustc now emits lexical blocks to try to explain
the shadowing.  However, in this simple of a test case,
they end up all having the same range.

disassemble/s also shows the lines are reordered, even
with 'opt-level=0'.  Not sure what is up there, but often
these very simple tests aren't the best view into what
the compiler is doing.

FWIW normally if two different compilers exhibit different
behavior in the same version of gdb, that points to a compiler
issue.  gdb is normally at the mercy of the debuginfo that
the compiler creates.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Bug rust/31079] Rustc test not hitting bp as expected for 1.73 or greater versions
  2023-11-21  8:21 [Bug rust/31079] New: Rustc test not hitting bp as expected for 1.73 or greater versions abdul.basitijaz at gmail dot com
  2023-11-21 22:41 ` [Bug rust/31079] " tromey at sourceware dot org
@ 2023-11-21 22:41 ` sam at gentoo dot org
  1 sibling, 0 replies; 3+ messages in thread
From: sam at gentoo dot org @ 2023-11-21 22:41 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=31079

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.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2023-11-21 22:41 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-11-21  8:21 [Bug rust/31079] New: Rustc test not hitting bp as expected for 1.73 or greater versions abdul.basitijaz at gmail dot com
2023-11-21 22:41 ` [Bug rust/31079] " tromey at sourceware dot org
2023-11-21 22:41 ` sam at gentoo dot org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).