| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 3287.1 | Dispatch problem | TAEC::LAVILLAT | | Mon Jul 06 1992 05:15 | 17 |
|
Re .0:
The only reason I know for this error is old (not up to date) dispatch tables.
The Kernel is dispatching your call to an address that is no longer your
MM entry point.
If you enroll again and start your MM with 'r id Y' under dbx, it should
disappear.
BTW are you sure your dbx window is using the correct (expected) dispatch
table file ?
Regards.
Pierre.
|
| 3287.2 | | TOOK::SWIST | Jim Swist LKG2-2/T2 DTN 226-7102 | Wed Jul 08 1992 09:57 | 7 |
| The problem is basically as described in .-1. Other things to look
for are...
MMs in wrong directories. Corrupt MM files, etc.
MCC_MMEXE_LOCATION or MCC_SYS_LOCATION variables set wrong
MMs from mixed releases, bad installation, bad cleanup before
re-install.
|
| 3287.3 | verify dispatch tables? | MICROW::LANG | | Wed Jul 08 1992 12:31 | 7 |
|
Is there any way we can be sure the dispatch is in synch with
the exe? I thought the dispatch tables were part of the image,
that enroll updated them.
thanks,
Bonnie
|
| 3287.4 | | TOOK::SWIST | Jim Swist LKG2-2/T2 DTN 226-7102 | Wed Jul 08 1992 14:39 | 14 |
| Enrollment copies the dispatch tables from the image into the
mcc_dispatch_table.dat file (and integrates them with the other MM
dispatch tables). If you change the dispatch table in the exe
(ANYTIME YOU RELINK THE MM IT IS LIKELY TO CHANGE AS THE ENTRY POINTS
MOVE TO NEW ADDRESSES), you need to re-enroll to update the dispatch
table file.
We never felt the need for a tool since (1) in a production environment
things don't get enrolled and the table never changes, and (2) in
a development environment it is easy enough to re-enroll everything
if you suspect a problem.
|
| 3287.5 | You mean the dispatching isn't really the same on VMS as ULTRIX ? | MOLAR::ROBERTS | Keith Roberts - DECmcc Toolkit Team | Wed Jul 08 1992 16:22 | 13 |
|
Shared image libraries on VMS typically have a jump table at the top
of the image. You link against the jump table. At execution time, the
PC goes to the jump table, which contains another jump to the actual
routine. The actual routine address can change everyday if you want,
but the code which calls the routine always goes to the jump table.
Now - is this to say that on ULTRIX we didn't implement the dispatching
the same way? And why we seem to have to re-enroll every time the MM
is relinked?
/keith
|
| 3287.6 | Enroll ULtrix <> Enroll VMS | TAEC::LAVILLAT | | Thu Jul 09 1992 04:57 | 22 |
| Re .-1:
>
> Now - is this to say that on ULTRIX we didn't implement the dispatching
> the same way? And why we seem to have to re-enroll every time the MM
> is relinked?
>
Seems so. I do not know the internals, but it seems that you have to
re-enroll on Ultrix each time the address of your entry point changes,
so at each link if you do not want to use nm to check that the address
has not changed !
Yes, on VMS this is completely different : you have to re-enroll basically
each time you change your vector.mar.
Anyway, this is only a development issue.
Regards.
Pierre.
|
| 3287.7 | History.... | TOOK::SWIST | Jim Swist LKG2-2/T2 DTN 226-7102 | Thu Jul 09 1992 09:01 | 10 |
| I tried to do it the VMS way but the Ultrix linker is much simpler and
provides very little control over where things go in the image (no
psects or other such things). A jump vector would be just another
object file which could just as easily move around in the .exe as the
entry points themselves. And I suspect I could have very well run
into portability problems with other u**x linkers even if I did find
a way to keep the jump table from moving.
Wasn't worth it.
|
| 3287.8 | Sounds like a documentation problem then | MOLAR::ROBERTS | Keith Roberts - DECmcc Toolkit Team | Thu Jul 09 1992 12:02 | 14 |
| > I tried to do it the VMS way but the Ultrix linker is much simpler and
> provides very little control over where things go in the image (no
> psects or other such things). A jump vector would be just another
> object file which could just as easily move around in the .exe as the
> entry points themselves. And I suspect I could have very well run
> into portability problems with other u**x linkers even if I did find
> a way to keep the jump table from moving.
This sounds like a documentation problem -- For ULTRIX development, we
should tell the developer that you *must* re-enroll your MM after relinking.
Thank you for the explaination
/keith
|