Conference vaxaxp::vmsnotes

    you might want to have a look at the fine manuals...
    
    [Q	- enable quadword mode
    [L	- enable longword mode
    [A	- toggel address mode between longword and quadword mode
    
    /cmos

    But that just toggle's between whether a longword or quadword is
    displayed, it does NOT display an S1 (Extended) address. 
    
    I think the question was:
    
    What display's an FFFFFFFD.######## address?
    
    Manual says the [Q specifies displaying a Quadword, [L a longword.
    That's fine for specifying how MUCH to display:
    
    SDA> sho page FFFFFFFF.80D4E500;1
    
    System page table
    -----------------
     MAPPED ADDRESS      PTE ADDRESS           PTE        TYPE  READ WRIT
    BITS GH PG
    TYP   LOC          BAK       REFCNT  FLINK    BLINK
    
    FFFFFFFF.80D4E000 FFFFFFFD.FFE03538 000004A7.00001351 VALID KE-- K---
    --KA 2 SYS
    TEM  ACTIVE 00000000.00000000 0001 00000000 00000000
    
    
    ...So I want to access the PTE at FFFFFFFD.FFE03538:
    
    ...In DELTA:
    :
    :
    00000001
    FFFFFFFD.FFE03538/00001111
    
    [Q <-- Toggles to display a quadword
    
    FFFFFFFD.FFE03538/07C4085E 00001111 
    [L <-- Toggles to display a longword
    
    FFFFFFFD.FFE03538/00001111
    
    FFFFFFFF.FFE03538/00001111 
    
    00000000.FFE03538/00001111
    
    So FFFFFFFD.FFE03538, FFFFFFFF.FFE03538, and 00000000.FFE03538 all
    display the location FFFFFFFF.FFE03538:
    
    SDA> e ffffffff.FFE03538
    FFFFFFFF.FFE03538:  07C4085E.00001111   "....^.�."
    
    ...Not FFFFFFFD.FFE03538	
    
    SDA> e fffffffd.FFE03538
    FFFFFFFD.FFE03538:  000004A7.00001351   "Q...�..."
    
    ...And after looking at the Delta manaual, I don't have your answer.
    
                       Mark d.   
    

    	XDelta and Delta both let you manipulate 64-bit addresses. I think
    it might be the "." that's confusing it. Try entering a 64-bit address
    as 16 hex digits with no "." or space in the middle. The "." has
    special meaning in XDelta and Delta, representing the current location.
    That might be what's causing the confusion.

     With no . or space, it still gives the wrong location: 
    
    FFFFFFFD.FFE03010/00001111
    
    FFFFFFFDFFE03010/00001111
    
    With a space, it actually gives the location minus FFFFFFFD (Plus 3)
    
    FFFFFFFD FFE03010/1107C407
    
    exit
    $ log
      Process SYSTEM_1 logged out at 25-MAR-1997 13:33:01.00
    SDA> e ffe03013;1
    %SDA-W-UNALIGNED, unaligned address FFE03013; converting to aligned
    address
    07C407A3 00001111 07C407A2 00001111  ....�.�.....�.�.    FFFFFFFF.FFE03010
                   ** ******
                           ^
                           +--- FFE03010+3
    
      
                  Mark d.
    
                 

Re: 298.4

>     With no . or space, it still gives the wrong location: 
>    
>    FFFFFFFD.FFE03010/00001111
>    
>    FFFFFFFDFFE03010/00001111
>    
>    With a space, it actually gives the location minus FFFFFFFD (Plus 3)
>    
>    FFFFFFFD FFE03010/1107C407

So to be consistent with what you entered to SDA, what happens if you
do a:

FFFFFFFFFFE03010/

And what happens with:

IE03010/

"I" is the shortcut for filling all the upper nibbles of the 64-bit address
with ones.

With [A and [Q enabled to display addresses as 64-bits and data as 64-bits,
can you deposit this 64-bit address into a register, then do a ".=" to see
that it's correct, and then "/" or TAB to open it and see if the correct
contents are displayed?

I'm curious where, exactly, this is broken. It was working for eons and must
have broken recently if there's something wrong. And if you're certain it's
doing the wrong thing, you should QAR it. We'll need to resurrect the ghost
of the maintainer to have a look, but I'm sure he's around here somewhere
in a drug-induced stupor.

    Look's like I'll have Karen QAR it and wake up the dead:
    
    [A
    
    [Q
    
    FFFFFFFFFFE03010/07C407AC 00001111
    
    IE03010/07C407AC 00001111
    
       
      Just can't seem to get there from here.
    
                        Mark d.

\                       <<< Note 298.5 by STAR::DIPIRRO >>>
\                             -< More confused... >-
    [...]
\ doing the wrong thing, you should QAR it. We'll need to resurrect the ghost
\ of the maintainer to have a look, but I'm sure he's around here somewhere
\ in a drug-induced stupor.
    
    ! Facility:
    !
    !       Executive - Debugging Tools
    !
    ! Abstract:
    !
    !       XDELTA is the VMS stand-alone debugging tool. It must be physically
    [...]
    !
    ! Author: Steve DiPirro , Creation date: 15-JAN-1990
    !

    	Ah ha! You see? I was right! Actually, now that you mention it, I
    got onto a standalone V7.1 machine the other day and farted around with
    this. I didn't have exactly the same setup, but I also couldn't
    reproduce the problem. DELTA seemed to be doing the right thing with
    the 64-bit addresses I tried to access. I didn't see the behavior of it
    sign-extending the low-order 32-bits of the address. I also didn't
    spend a lot of time with it since I snuck on the standalone machine
    just to try it and hadn't reserved any time.
    	I haven't seen the QAR yet though. So I guess it'll end up in my
    lap one of these days, at which point I'll come back out of that
    drug-induced stupor. For now, it's nap time.....

    QARed in EVMS-RAVEN, #1016

    	By the way, I've been looking at this. I'm not exactly sure what's
    going on yet, but I will say that it has nothing to do with 64-bit
    addresses. DELTA and XDELTA, which share the same code in this area,
    both seem to be handling 64-bit addresses properly. They are not
    sign-extending the low-order 32-bits of an address to form a 64-bit
    address.
    	DELTA just seems to be having problems accessing system space. For
    one thing, what you were trying to do in .0 won't work anyway. When
    you're in DELTA and trying to access an address, it does it from
    whatever mode it's running in at the time. So if you're in DELTA in
    user-mode and try to access a system space address, it will most likely
    fail (with an "Eh?" message). However, I've been trying this in kernel
    mode in DELTA and having the same problem. I'm continuing to look into
    this as I think I know where it's failing.
    	A workaround, if you need one, is to use XDELTA. I booted the
    system with XDELTA. Then I went into SDA, picked a driver and found the
    PTEs in 64-bit address space, then ^P, dep sirr e, cont, and then
    farted around with the PTEs from XDELTA. It's not as easy as what you
    were trying to do, but at least it works.

To read pages that do not have UR protections, use the swapper
to read the data:

00010001:xxxxxxxx.xxxxxxxx

For example:

10001:FFFFFFFF.FFE0C170/00003115 40001319

Until you switch PIDs, all new examines and updates are done
via a kernel AST in SWAPPER context.

OpenVMS (TM) Alpha system analyzer

SDA> ex FFFFFFFF.FFE0C170
FFFFFFFF.FFE0C170:  00003115.40001319   "[email protected].."
SDA> show page FFFFFFFF.FFE0C170;1

System page table
-----------------
 MAPPED ADDRESS      PTE ADDRESS           PTE        TYPE  READ WRIT BITS
GH PG
TYP   LOC          BAK       REFCNT  FLINK    BLINK

FFFFFFFF.FFE0C000 FFFFFFFD.FFFFF830 000001A6.40001139 VALID K--- K--- --KA
1 SPT
(L3) ACTIVE 00000000.00000000 0002 00000000 00000000
SDA>