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.
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()
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.
The next Fedora GDB update will come with the fix.
gdb-6.8-17.fc9 has been submitted as an update for Fedora 9
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.
FYI this patch is going to be dropped as it is no longer reproducible with Fedora 31 tools. Tested by Kevin Buettner.
https://src.fedoraproject.org/rpms/gdb/blob/master/f/gdb-6.8-bz436037-reg-no-longer-active.patch