28 Jul
2010
28 Jul
'10
9:06 a.m.
"Jerome H. Fine" <jhfinedp3k at compsys.to> wrote:
Yes, but don't mix questions. Keep the thread of each question intact,
and start a new question when you have something else you wonder about,
or use whatever thread already exists that deal with that specific
topic. And I use "thread" very loosely here. This mail have several
different threads dealing with different topics related to RT-11,
RSTS/E, RTEM and various other issues.
So, for the question on how RSTS/E figures out which RTS a program
should run under should not suddenly be the question on how to copy a
file from an RT-11 media into RSTS/E V10.
Yes. You have a working work-around. Which is good.
Well, not entirely true. You will still take up a lot more space on disk
for the image. And the symbol table is still around in memory even when
not needed. It is true that it does not impact on the speed, nor the
actual physical memory used by the program, since pages are only mapped
in when needed, but there is (as always) more to it than that.
In a way, the same is always true. The symbol table is always outside of
the actual image. Be it in a separate section of the binary, or a
separate file (RSX places the information in a separate file, which is
only created if you ask for it).
But for the optimization, that you cannot avoid. When you want to debug
a program, you do not want the compiler to optimize the code, because
that can, and normally will produce code that is very different from
what you wrote.
No, but it would be a major problem under RSX and RSTS/E, which is why a
similar solution cannot exist for them, despite what you think you read
in the sources of the SD(X).SYS driver for RT-11.
How does the device driver know what symbol table to load? Or is it just
that you can load a symbol table when you are in the debugger, if you
want to? And hopefully you will load the right symbol table at that
point, if you are interested?
Good. So then we can perhaps lay the idea of this SD(X).SYS driver in
any form being available, or even possible, under RSTS/E or RSX to rest. :-)
Johnny
Johnny Billquist wrote:
I'll try. But please try to read, understand, and apply what I write, or
else we'll not get anywhere.
> >> Agreed! The problem is that I have
been unable to locate any
> >> documentation for which RT-11 EMT requests are handled by
> >> the RTEM-11 RTS along with the differences between RT-11
> >> and the RTEM-11 RTS.
>
> *sigh* Still not an RTS... RTEM-11 is a program, not an RTS. There is
> no RTS concept in RSX.
I agree. I forget to use the correct terminology. If you can indulge me
now that I have turned 72 years old, that would be appreciated. > >>
But for RTEM-11, I don't have any documentation at all.
>
> The obvious answer is that this is documented in the manual that came
> with RTEM-11. Now, you just need to find someone who has it... (not me)
Well, since we both agree that it is extremely unlikely that RTEM-11 will
ever be used, ...
> >> I have access to both V7 and V10.1
or RSTS/E. However, I have not
> >> found the
> >> program in V10.1 which copies files from RT-11 files structures to
> >> RSTS/E file
> >> structures.
>
> And this has just about nothing to do with the question on how RSTS/E
> determines which RTS a program runs under, but anyway...
Obviously, but it is difficult to test a program when I can't even "RUN"
it. > As
I've said before, I know about FIT. If DEC replaced FIT with
> something else in RSTS/E V10, then you just have to search around in
> the system. Look at the help files. That's usually a good place to
> start searching. Read the manuals. I think the V10 manuals are online
> somewhere as well.
The work around that I use is to MOUNT DL0: which already has
the files (Having been copied by FIT from DY0: to DL0:). If anyone else is reading this, can you suggest
anything?
I did suggest how you should go about finding the answer yourself. You
are of course free to keep asking if someone else already have the
answer for you, but noone have responded yet...
> And is
still done to this day in RSTS/E and RSX. And while exactly the
> same, something similar is done in Unix systems, Windows systems, VMS
> systems, and any other system I can think of.
> The reason being that for debugging you don't want a compiler to
> optimize things, and you want to include symbol tables in the compiled
> image for debugging purposes, while you do not want that stuff for the
> finished program, since it takes space and makes the program slower
> (symbol table and non-optimization).
Actually, for VMS systems, if my faulty memory is able to remember
correctly, the
compiler builds symbol tables outside of the code and data in a manner which
does not impact at all on the program when debugging is NOT taking place. From what I remember, the FORTRAN compiler set up the
symbol tables for
debugging so that there was no impact on the code when debugging was not
active.
Your view of "impact" is way to narrow.
> Modern
systems however, usually allows the debugger to be dynamically
> attached to a running program so you don't have to include that bit
> already at the link stage.
Under RT-11, the SD(X).SYS device driver traps the BPT instruction when
it is executed no matter what state the hardware is in. Of course, this
also
STOPS ALL other code from executing as well. This is not considered a
problem under RT-11. Under TSX-Plus, the debugger STOPS only the code for
that job on that
terminal from running. There is also a separate debugger for the TSX-Plus
operating system which does stop everything in the system.
Correct me if I'm wrong, but don't TSX more or less provide like a
virtual PDP-11 for each user, so that it appears as if they have all of
a machine for them self, so in essence, it would work just as fine as on
a real RT-11 system?
> >>
However, by V05.04 of RT-11, DEC developed the SD(X).SYS device
> >> driver which allowed a program to have a BPT instruction without the
> >> requirement to include ODT as part of the code. If the user LOADed
> >> SDX.SYS prior to executing the program with the BPT, but without
> >> ODT included, the code in SDX.SYS initialized the required VECTOR
> >> to trap the BPT instruction when SDX.SYS was LOADed. The code
> >> in SDX.SYS then performed all of the functions that ODT supported
> >> (and a few others as well) without adding any extra code to the program
> >> being tested. It is even possible to place a BPT in the monitor code
> >> and test those instructions as well.
>
> Ok. So, no symbol table stuff, and no possibility to add breakpoints,
> watchpoints and other stuff in the program until you hit atleast one
> BPT in the code which cause the code in SDX to be called?
Actually, no! A symbol table is allowed, but I normally never use one
since the listing of the program has always been sufficient. Also, if the
code is already loaded into a known location in memory (e.g. the RT-11
Resident Monitor), it is possible to place a BPT in the desired instruction. > RT11 is a
single user system, where the OS do so much less for you
> that this concept is even possible. For more complex systems, you
> cannot do things this way.
AGREED!!