Bug 250024

Summary: cannot set CPU register value
Product: [Fedora] Fedora Reporter: John Reiser <jreiser>
Component: gdbAssignee: Jan Kratochvil <jan.kratochvil>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 9CC: dvlasenk, triage
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-08-11 17:52:10 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Fix - port of the amd64 frameless handling for i386. none

Description John Reiser 2007-07-29 18:13:56 UTC
Description of problem: gdb cannot set the contents of a CPU register:
  (gdb) set $eax=3
  Value being assigned to is no longer active.
  (gdb) p $eax
  $1 = 0x0


Version-Release number of selected component (if applicable):
GNU gdb Red Hat Linux (6.6-15.fc7rh)

How reproducible: always


Steps to Reproduce:
1. Try to change register value, for instance with "set $eax = 3"
2.
3.
  
Actual results:
"Value being assigned to is no longer active." and the register value does not
change.

Expected results: The contents of the register changes to the new value.


Additional info:
Here is a short test program:
----- ps.S
#include <asm/unistd.h>

_start: .globl _start
        sub %ebx,%ebx
        int3
        jnz good
        incl %ebx
good:
        movl $__NR_exit,%eax
        int $0x80
-----

$ gcc -o ps -nostartfiles -nostdlib ps.S
$ gdb ps
(gdb) run

Program received signal SIGTRAP, Trace/breakpoint trap.
0x08048057 in _start ()
(gdb) set $eax = 3
Value being assigned to is no longer active.
(gdb)

Comment 1 Jan Kratochvil 2007-07-29 23:10:05 UTC
Created attachment 160208 [details]
Fix - port of the amd64 frameless handling for i386.

It affects only artifical code / functions with broken stack frames.
For a normal C code you can set the registers even on i386.
Testing RPM is now being built at:
  http://koji.fedoraproject.org/koji/taskinfo?taskID=81273
Thanks for the report, regressions check / integration / upstream post to be
done.

Comment 2 John Reiser 2007-07-30 02:02:21 UTC
gdb-6.6-23.fc7.i386.rpm works for me.  Thank you.


Comment 3 Jan Kratochvil 2007-07-30 08:42:16 UTC
Posted upstream:
http://sources.redhat.com/ml/gdb-patches/2007-07/msg00307.html


Comment 4 Jan Kratochvil 2007-07-30 12:04:43 UTC
Comment on attachment 160208 [details]
Fix - port of the amd64 frameless handling for i386.

My patch is wrong, though.
More info in the upstream mailing list.

Comment 5 Bug Zapper 2008-05-14 13:44:40 UTC
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 6 John Reiser 2008-05-14 15:22:09 UTC
This problem persists in Fedora 9, gdb-6.8-5.fc9.i386.  I updated the header of
this bugzilla report to say Version 9.


Comment 7 Denys Vlasenko 2008-08-11 15:29:04 UTC
Works for me:

# gcc -o ps -nostartfiles -nostdlib ps.S
# gdb ps
GNU gdb Fedora (6.8-12.fc9)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu"...
(no debugging symbols found)
(gdb) run
Starting program: /tmp/ps
(no debugging symbols found)

Program received signal SIGTRAP, Trace/breakpoint trap.
0x00000000004000d7 in _start ()
(gdb) set $eax = 3
(gdb) quit
The program is running.  Exit anyway? (y or n) y



Version, arch:

# gdb --version
GNU gdb Fedora (6.8-12.fc9)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".

Comment 8 John Reiser 2008-08-11 17:52:10 UTC
gdb-6.8-17.fc9 also works for me.  So -17 and -12 work, but -5 still had the problem.  I hope it continues to work.  I changed Status to Closed - Current Release.

This looks to be strongly related to bug #436037, "gdb remote fails qemu: Value being assigned to is no longer active".  One theme seems to be keeping hardware registers fully active regardless of the status of other pieces of the environment, such as symbol tables, stack traces, etc.