Bug 78670 - Using gdb to set the ar.rnat doesn't affect the program
Summary: Using gdb to set the ar.rnat doesn't affect the program
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 7.2
Hardware: ia64
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-11-27 15:25 UTC by John Kacur
Modified: 2008-08-01 16:22 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-09-30 15:40:15 UTC
Embargoed:


Attachments (Terms of Use)

Description John Kacur 2002-11-27 15:25:21 UTC
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:
Always

Steps to Reproduce:
1.      .file "get_rnat.asm"
      .text
      .align 16
      .global get_rnat#
      .proc get_rnat#
// Function Prototype is uint64_t get_rnat(void)
get_rnat:
      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);

      exit(0);
}
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 ()
(gdb)run
Then the debugger stops at the breakpoint, and I do
(gdb) print $rnat=32
(gdb) c
Continuing.
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 20:02:54 UTC
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)
(outer) 
363	      addr += sizeof (PTRACE_TYPE_RET);


Comment 2 Bugzilla owner 2004-09-30 15:40:15 UTC
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
persists.

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.