Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.os2.programmer.misc > #1851
| From | Paul Edwards <mutazilah@gmail.com> |
|---|---|
| Newsgroups | comp.os.os2.programmer.misc |
| Subject | Re: loader |
| Date | 2024-02-24 15:24 +0800 |
| Organization | A noiseless patient Spider |
| Message-ID | <urc5jb$12sfb$1@dont-email.me> (permalink) |
| References | <ur1mqi$2ddfu$1@dont-email.me> |
On 20/02/24 16:10, Paul Edwards wrote:
Ok, another crack at that data.
> 0008 68 00 00 00 00 push offset L$1
This is the push of the data.
ie this data (L$1):
> Segment: CONST DWORD USE32 0000000A bytes
> 0000 L$1:
> 0000 68 69 0D 0A 61 62 63 0D 0A 00 hi..abc...
And in the executable, that code is:
> 0001C0 EA08444F 5343414C 4C530000 83EC0489 ..DOSCALLS......
> 0001D0 E0506A09 68000002 006A01E8 00000000 .Pj.h....j......
68 and a value of 00020000
That looks like a common starting point for data -
2 * 64k. And code is typically placed at 1 * 64k.
Unless relocation information is available and
applied, in which case you can correct all these
values.
Which is a good point - I don't use virtual memory
in PDOS/386 so that address can't possibly stand,
unless it is relative. I doubt that it is a relative
address, but I'm not sufficiently familiar with
x86 opcodes.
Regardless, now would be a good time to find out if
I can find a relocation fixup pointing to that address,
ie offset 9 in the code section.
I don't see such a thing:
D:\devel\pdos_minimal\xxx>hexdump os2test.exe | grep 09
000040 0E1FB409 BA1000CD 21B001B4 4CCD2100 ........!...L.!.
000090 00020000 02000000 01000000 00000000 ................
0001D0 E0506A09 68000002 006A01E8 00000000 .Pj.h....j......
D:\devel\pdos_minimal\xxx>
Maybe the reference is to 1cc+9 or more likely, 14c+9 = 155
D:\devel\pdos_minimal\xxx>hexdump os2test.exe | grep 55
D:\devel\pdos_minimal\xxx>
Nope.
Let me see if there is a wlink option to add relocatable
information.
Nothing stands out with "wlink /?".
Windows executables built by Watcom are (now - just
fixed unrelated issues) working fine under PDOS/386
which means they should contain relocations.
Let me see if the documentation gives any hints.
Offsets 30h, 68h and 6ch are the most likely.
> 0000B0 23000000 00000000 64000000 00000000 #.......d.......
23 as a size is an odd number.
> 0000E0 00000000 00000000 28010000 34010000 ........(...4...
0128 as an offset to something, 0134 as an
offset to something else. So what's there?
> 000190 27000000 27000000 0A000000 076F7332 '...'........os2
> 0001A0 74657374 00000000 00000000 0D000000 test............
> 0001B0 0D000000 08011000 011A0108 811C0001 ................
So 1A8 (128 + 80) is 0 and a D and another D.
And 1B4 (134 + 80) is looking like that thing
I documented before with the external names.
I hope OS/2 isn't a system that relies on
virtual memory and doesn't have relocation
capability.
The thing I documented before was:
> I can see that first at 0x1b9.
> 0001B0 0D000000 08011000 011A0108 811C0001 ................
And indeed - 1B4 is where a DLL fixup is being done.
Fixing up DLL entries is a different concept to
providing relocation information for a module
that has been relocated.
So first thing I need to know is - do OS/2 modules
have a concept of relocation information?
MSDOS 16-bit had that.
From memory NE executables had it too.
Yes, here is some of the NE code I wrote:
fread(numreloc, sizeof numreloc, 1, fp);
nr = numreloc[0] | (numreloc[1] << 8);
/* printf("nr is %d\n", nr); */
for (x = 0; x < nr; x++)
{
/* 2 is segment, 3 is a far address,
5 is an offset */
fread(reloc, sizeof reloc, 1, fp);
if ((reloc[0] != 2)
Is it known by a different name in LX, or is it
non-existent?
This looks interesting:
2.12.5 - Internal Chaining Fixups
Internal chaining fixups are 32-bit offset fixups (source type 07h) to
internal references (target types 00h and
03h) where the first fixup in the chain is a record in the Fixup Record
Table and the remaining fixups are
located in the page referenced by the first fixup rather than as records
in the Fixup Record Table
Looks exactly what I need.
NE is a chain too.
So - where are these?
And it seems to be associated with this:
2.12.4 Internal Entry Table Fixup Record
And probably this:
2.12.1 - Internal Fixup Record
And:
2.12 - Fixup Record Table
which has something I saw earlier:
07h = 32-bit Offset fixup (32-bits).
So - what points to this "Fixup Record Table"?
That's the x'6c' - where I was before.
And as before - I'm missing something that would
allow me to zap that offset.
Either I'm missing relocations in the executable,
or I'm incorrectly thinking that a fixup is needed
in this situation (ie maybe it is relative and the
distance to the data section needs to remain fixed),
or I'm missing some other concept of some sort.
What are all these other numbers anyway?
> 000130 00000000 00000000 00000000 00000000 ................
> 000140 00000000 28000000 00000100 05200000 ....(........ ..
> 000150 01000000 01000000 00000000 0C000000 ................
> 000160 00000200 03200000 02000000 01000000 ..... ..........
> 000170 00000000 00080000 00000300 03200000 ............. ..
> 000180 03000000 00000000 00000000 00000000 ................
> 000190 27000000 27000000 0A000000 076F7332 '...'........os2
Can I see something in the header that points
to them? That would be offset x'B0' to x'120'.
> 000080 4C580000 00000000 02000100 00000000 LX..............
> 000090 00020000 02000000 01000000 00000000 ................
> 0000A0 03000000 00080000 00100000 00000000 ................
> 0000B0 23000000 00000000 64000000 00000000 #.......d.......
> 0000C0 C4000000 03000000 0C010000 00000000 ................
> 0000D0 1C010000 00000000 1C010000 27010000 ............'...
> 0000E0 00000000 00000000 28010000 34010000 ........(...4...
> 0000F0 41010000 01000000 4A010000 00000000 A.......J.......
> 000100 CC010000 00000000 00000000 00000000 ................
> 000110 00000000 02000000 00000000 00000000 ................
> 000120 00000000 00000000 00000000 00080000 ................
I see a x'00c4' in that range. Nothing else.
That's at C0 = 40, ie object table offset.
number of objects being 3. Not sure what that
3 represents. But let's go to offset C4, ie
144 in the hexdump.
> 000130 00000000 00000000 00000000 00000000 ................
> 000140 00000000 28000000 00000100 05200000 ....(........ ..
> 000150 01000000 01000000 00000000 0C000000 ................
> 000160 00000200 03200000 02000000 01000000 ..... ..........
> 000170 00000000 00080000 00000300 03200000 ............. ..
> 000180 03000000 00000000 00000000 00000000 ................
> 000190 27000000 27000000 0A000000 076F7332 '...'........os2
Before that is all NULs, so could be padding.
And there should be 3 "objects", whatever that is.
Let's see if I can match it to some documentation.
First bit of data is x'28'.
Looks like each entry is x'18' bytes.
And the x'28' is a length - so presumably the length
of the code. That's very close to correct. It should
be x'27' - unless it is size in memory.
And base address is 010000 - reasonable.
Next we have a length of x'c', and a base address of
020000. I'm only expecting 10 bytes of data - so again,
this could be the size when placed in memory, rounded
to a 4-byte boundary.
All very reasonable. What on earth could the 3rd one be?
A length of x'800' - gotta be the stack. Located at x'30000'.
And that covers all the unknowns except:
> 000190 27000000 27000000 0A000000 076F7332 '...'........os2
The x'27' is the actual length of the code. Not
sure why it would be listed twice. And x'0a' is
the actual length of the data. That is likely
referenced earlier. Maybe page sizes?
Oh, I missed a bit.
> 000180 00000000 ................
> 000190 27000000 27000000 0A000000 076F7332 '...'........os2
So offset 0, length 27, and flags.
Then offset 27, length A, and flags.
That is "2.5 Object Page Table".
And that's everything I think. I'm missing the
"internal fixups". Not sure if I missed a wlink
option or something.
BFN. Paul.
Back to comp.os.os2.programmer.misc | Previous | Next — Previous in thread | Next in thread | Find similar
loader Paul Edwards <mutazilah@gmail.com> - 2024-02-20 16:10 +0800
Re: loader Peter Flass <peter_flass@yahoo.com> - 2024-02-20 17:45 -0700
Re: loader Paul Edwards <mutazilah@gmail.com> - 2024-02-21 10:51 +0800
Re: loader Paul Edwards <mutazilah@gmail.com> - 2024-02-24 06:14 +0800
Re: loader Paul Edwards <mutazilah@gmail.com> - 2024-02-24 11:38 +0800
Re: loader Paul Edwards <mutazilah@gmail.com> - 2024-02-24 15:24 +0800
Re: loader Paul Edwards <mutazilah@gmail.com> - 2024-02-24 15:46 +0800
Re: loader Paul Edwards <mutazilah@gmail.com> - 2024-02-24 16:30 +0800
Re: loader Paul Edwards <mutazilah@gmail.com> - 2024-02-24 23:30 +0800
Re: loader Paul Edwards <mutazilah@gmail.com> - 2024-02-24 23:28 +0800
Re: loader Paul Edwards <mutazilah@gmail.com> - 2024-02-26 06:56 +0800
Re: loader Peter Flass <peter_flass@yahoo.com> - 2024-02-27 15:41 -0700
Re: loader Paul Edwards <mutazilah@gmail.com> - 2024-02-28 12:50 +0800
Re: loader Dave Yeo <dave.r.yeo@gmail.com> - 2024-02-28 14:04 -0800
Re: loader Paul Edwards <mutazilah@gmail.com> - 2024-02-29 06:56 +0800
Re: loader Dave Yeo <dave.r.yeo@gmail.com> - 2024-02-28 19:11 -0800
Re: loader Paul Edwards <mutazilah@gmail.com> - 2024-02-29 11:46 +0800
Re: loader Dave Yeo <dave.r.yeo@gmail.com> - 2024-02-28 23:02 -0800
Re: loader Paul Edwards <mutazilah@gmail.com> - 2024-03-01 07:15 +0800
Re: loader Dave Yeo <dave.r.yeo@gmail.com> - 2024-02-28 14:20 -0800
Re: loader Dave Yeo <dave.r.yeo@gmail.com> - 2024-02-28 13:52 -0800
Re: loader Peter Flass <peter_flass@yahoo.com> - 2024-02-28 17:43 -0700
csiph-web