Bug 78670 - Using gdb to set the ar.rnat doesn't affect the program
Using gdb to set the ar.rnat doesn't affect the program
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
ia64 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2002-11-27 10:25 EST by John Kacur
Modified: 2008-08-01 12:22 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-30 11:40:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description John Kacur 2002-11-27 10:25:21 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.7 [en] (WinNT; U)

Description of problem:
I have a simple program to read the ar.rnat register. In order to test this, I use gdb to set ar.rnat to a value.
Although printing the contents of ar.rnat from gdb indicates that the value was changed, the program output shows that the ar.rnat was not changes, 
and still reads as 0

Version-Release number of selected component (if applicable):
Fails with both gdb-5.1-1 or gdb-5.2-2

How reproducible:

Steps to Reproduce:
1.      .file "get_rnat.asm"
      .align 16
      .global get_rnat#
      .proc get_rnat#
// Function Prototype is uint64_t get_rnat(void)
      mov r2=ar.rsc           // preserve ar.rsc in r2
      mov r14=0x3;;           // bits zero and one
      andcm r3=r2,r14;; // r3 = r2 & ~r14
      mov ar.rsc=r3;;         // ar.rsc = enforced lazy mode
      mov r8=ar.rnat;;        // return value of ar.rnat
      mov ar.rsc=r2;;           // restore previous mode to ar.rsc

      .endp get_rnat#
You can assemble the above with as -o get_rnat.o get_rnat.asm
2. Here is a simple program to utilize the above.
/* file: try.c */
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>

extern uint64_t get_rnat(void);

int main(void)
      uint64_t rnat = get_rnat();
      printf("ar.rnat = %#lx\n", rnat);

Note: I use gcc3.04
gcc -o try try.c get_rnat.o -W -Wall -g
3. Use gdb to set rnat
Now, inorder to test this, I want to use the debugger to force ar.rnat to
have a value, so I do the following.
gdb try
(gdb)br main
Breakpoint 1, 0x4000000000000692 in main ()
Then the debugger stops at the breakpoint, and I do
(gdb) print $rnat=32
(gdb) c
ar.rnat = 0

Program exited normally.
(gdb) quit
My program reported ar.rnat as 0, even though I used gdb to force the value
to 32

If I put another breakpoint before the exit and do "info register $rnat,
then it is still 32,", but my program reports 0.
Furthermore, If I  force $rnat to a value through some asm code, and then
call get_rnat(), it works correctly.

Actual Results:  My program reported ar.rnat as 0, even though I used gdb to force the value
to 32

Expected Results:  The program should have output
ar.rnat = 0x20

Additional info:
Comment 1 Jeff Johnston 2004-08-26 16:02:54 EDT
Problem exists with PTRACE.  Gdb is writing to 0x860 which is the
glibc supplied location to write to the rnat register.  It also reads
the location back and this works within the confines of gdb (i.e. read
of the data produces the previously written value).  This value is not
being used for the rnat register value when accessed via user
assembler code.

Kernel help is required to debug this problem.  Either the published
address of PT_RNAT_ADDR is wrong in /usr/include/asm/ptrace_offsets.h,
the value should not be used for accessing/modifying the rnat
register, or there is a bug translating writes to modify the register.

358	      ptrace (PT_WRITE_U, tid, (PTRACE_TYPE_ARG3) addr, buf[i]);
(outer) p/x buf[0]
$2 = 0x20
(outer) next
359	      if (errno != 0)
363	      addr += sizeof (PTRACE_TYPE_RET);
Comment 2 Bugzilla owner 2004-09-30 11:40:15 EDT
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/

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