Bug 436037 - gdb remote fails qemu: "Value being assigned to is no longer active"
gdb remote fails qemu: "Value being assigned to is no longer active"
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: gdb (Show other bugs)
8
i386 Linux
low Severity low
: ---
: ---
Assigned To: Jan Kratochvil
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-04 17:27 EST by John Reiser
Modified: 2008-08-07 19:53 EDT (History)
1 user (show)

See Also:
Fixed In Version: gdb-6.8-16.fc9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-08-01 10:32:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Fix (985 bytes, patch)
2008-07-31 10:32 EDT, Denys Vlasenko
no flags Details | Diff

  None (edit)
Description John Reiser 2008-03-04 17:27:55 EST
Description of problem: When using the remote target facility to debug kernel
startup using qemu, gdb cannot change register values, including the $pc.  In
particular, it is impossible to step over an 'icebp' [opcode 0xf1, which always
stops qemu, therefore is a handy explicit breakpoint.]


Version-Release number of selected component (if applicable):
gdb-6.6-43.fc8


How reproducible: Always.


Steps to Reproduce:
1. qemu -S -s -kernel /boot/vmlinuz-2.6.23.15-137.fc8 -nographic -hda
<filesys_image>
2. In another shell: gdb
3. (gdb) target remote localhost:1234
   (gdb) set $pc+=1
  
Actual results:
-----qemu
Could not configure '/dev/rtc' to have a 1024 Hz timer. This is not a fatal
error, but for better emulation accuracy either use a 2.6 host Linux kernel or
type 'echo 1024 > /proc/sys/dev/rtc/max-user-freq' as root.
Could not open '/dev/kqemu' - QEMU acceleration layer not activated
(qemu)    ### this is normal so far
-----

-----gdb
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
0x0000fff0 in ?? ()
(gdb) set $pc+=1
Value being assigned to is no longer active.
-----

(gdb) set $pc+=1
Value being assigned to is no longer active.


Expected results:
$pc incremented with no complaint

Additional info: qemu-0.9.0-7.fc8
This works in Fedora 7 with gdb-6.6-23.fc7 and qemu-0.9.0-3.fc7.
Comment 1 Denys Vlasenko 2008-07-31 10:32:44 EDT
Created attachment 313103 [details]
Fix

<jkratoch> as frame_find_by_id() should have returned current_Frame itself
<jkratoch> and the question is why it did not do so.
<dvlasenk> i actually took the idea from there
<dvlasenk> a comment says "should be return  get_current_frame () instead?"
<jkratoch> But so far it should be run through the testsuite regressions test
(you can run it locally for x86_64+i386) and sure it would be great at least
for Rawhide.
<dvlasenk> but OTOH: what if some user of frame_find_by_id() does NOT want this
behavior?
<jkratoch> It is all a mess now.
<jkratoch> Then the caller of it should be changed...
<dvlasenk> It's better to return NULL, and whoever wants get_current_frame ()
can trivially do "f = frame_find_by_id() ? : get_current_frame ()"
<jkratoch> That is the problem, that the code currently have different
expectations at different places so the fix of it all is a lot of changes, this
is the reason why it is still not fixed up.
<jkratoch> So each caller of frame_find_by_id() should do this hack?
<jkratoch> Why frame_find_by_id() should not return the right value in the
first place
<jkratoch> and rather to fix those who have the wrong NULL value expectations?
<dvlasenk> if there are many callers which want this, we can wrap it into
frame_find_by_id_or_get_current()
Comment 2 Denys Vlasenko 2008-07-31 10:50:23 EDT
No testsuite regressions on x86_64 machine.

The regression, if there is an undetected one, would look like this: instead of
refusing to touch a value of an expression which is out of scope, a value of the
same expression in bottom-most frame is modified.
Comment 3 Jan Kratochvil 2008-08-01 10:32:56 EDT
The next Fedora GDB update will come with the fix.
Comment 4 Fedora Update System 2008-08-04 01:20:30 EDT
gdb-6.8-17.fc9 has been submitted as an update for Fedora 9
Comment 5 Fedora Update System 2008-08-07 19:53:10 EDT
gdb-6.8-17.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.