Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  nodelist  faq  login

Avoid strange women and temporary variables.


programming / comp.lang.asm.x86 / Re: Referring to a segment

SubjectAuthor
* Referring to a segmentLars Erdmann
+- Re: Referring to a segmentrick.c.hodgin
`* Re: Referring to a segmentwolfgang kern
 `- Re: Referring to a segmentLars Erdmann

1
Subject: Referring to a segment
From: Lars Erdmann
Newsgroups: comp.lang.asm.x86
Organization: solani.org
Date: Mon, 17 Aug 2020 17:11 UTC
Path: i2pn2.org!i2pn.org!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: lars.erd...@nospicedham.arcor.de (Lars Erdmann)
Newsgroups: comp.lang.asm.x86
Subject: Referring to a segment
Date: Mon, 17 Aug 2020 19:11:28 +0200
Organization: solani.org
Lines: 67
Approved: fbkotler@myfairpoint.net - comp.lang.asm.x86 moderation team.
Message-ID: <rhedo1$liv$1@solani.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: reader02.eternal-september.org; posting-host="21a3d8e66bff8ac9544e5740995de452";
logging-data="9175"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18HjMe7RVyYDPhpki7CZvKn0mEgs9VV8rE="
User-Agent: Mozilla/5.0 (OS/2; Warp 4.5; rv:45.0) Gecko/20100101
Thunderbird/45.8.0
Cancel-Lock: sha1:K5/ZGR5mEp6Bv0Py5cdx0lvQdjE=
View all headers
Hallo,

I have a question that might be os specific or maybe also linker/loader specific to a certain extent but I don't know of any better place to ask:

I am developing for OS/2 which, for the most part, is a 32-bit protected mode OS.
However, due to its heritage, device drivers are still 16-bit (even though protected mode) and still consist of multiple code and data segments.
Each segment is reflected by a descriptor table entry (as always in protected mode) and, this might be OS specific, is assigned a dedicated GDT selector.
It is possible to build drivers that not only contain 16-bit segments but also 32-bit segments. Still, these additional 32-bit segments get assigned a GDT selector and the descriptor entry only encompasses the start address and size of the combined 32-bit code of that 32-bit segment.

Finally, there exists a FLAT GDT code selector and the descriptor it points to defines the whole 4 GB of memory address space as the segment (start address 0, limit = 4GB-1).



Here is the question:
In a device driver, from 16-bit code, I need to get to the selector of a 32-bit segment of the same driver.
I was using IBM's alp.exe assembler and this worked in the following way:

one module, defining all segments (to make them known to linker):
KEECode segment dword public uses16 'CODE'
KEECode ends
.... other segments ...
CODE32 segment public dword use32 'CODE'
CODE32 ends


another module:
CODE32 segment public dword use32 'CODE'
CODE32 ends

KEECode segment dword public uses16 'CODE'
....
mov ax,CODE32 ; loads the GDT sel. for the 32-bit code segment into ax
....
KEECode ends


On loading the driver, this was resolved by the loader to load the static GDT selector of the 32-bit code segment ("CODE32") into ax.


Now, I am forced to move to the Watcom WASM.EXE assembler.
I did the very same as above, but this time, instead of loading the GDT selector for the 32-bit code segment, it is always the FLAT selector that is loaded into ax once the driver is loaded in memory.

What is the proper way to reference this 32-bit code segment so that the proper GDT selector (and not the FLAT selector) is loaded into ax ?
Is this an assembler issue, a linker issue or even both ?


Lars







Subject: Re: Referring to a segment
From: rick.c.h...@nospicedham.gmail.com
Newsgroups: comp.lang.asm.x86
Organization: A noiseless patient Spider
Date: Tue, 18 Aug 2020 00:55 UTC
References: 1
Path: i2pn2.org!i2pn.org!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: rick.c.h...@nospicedham.gmail.com
Newsgroups: comp.lang.asm.x86
Subject: Re: Referring to a segment
Date: Mon, 17 Aug 2020 17:55:27 -0700 (PDT)
Organization: A noiseless patient Spider
Lines: 80
Approved: fbkotler@myfairpoint.net - comp.lang.asm.x86 moderation team.
Message-ID: <3e6bc8d5-fefe-4e69-81e4-5018f140cb84o@googlegroups.com>
References: <rhedo1$liv$1@solani.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Injection-Date: Tue, 18 Aug 2020 00:55:27 +0000
Injection-Info: reader02.eternal-september.org; posting-host="21a3d8e66bff8ac9544e5740995de452";
logging-data="29727"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18FUhiHgsjab5gCXAD4pXtiAaFvucwc+eU="
User-Agent: G2/1.0
Cancel-Lock: sha1:hJHIU2EZnPJZ0tMsMzxpEtjTpuY=
View all headers
On Monday, August 17, 2020 at 7:44:17 PM UTC-4, Lars Erdmann wrote:
Hallo,

I have a question that might be os specific or maybe also linker/loader
specific to a certain extent but I don't know of any better place to ask:

I am developing for OS/2 which, for the most part, is a 32-bit protected
mode OS.
However, due to its heritage, device drivers are still 16-bit (even
though protected mode) and still consist of multiple code and data segments.
Each segment is reflected by a descriptor table entry (as always in
protected mode) and, this might be OS specific, is assigned a dedicated
GDT selector.
It is possible to build drivers that not only contain 16-bit segments
but also 32-bit segments. Still, these additional 32-bit segments get
assigned a GDT selector and the descriptor entry only encompasses the
start address and size of the combined 32-bit code of that 32-bit segment.

Finally, there exists a FLAT GDT code selector and the descriptor it
points to defines the whole 4 GB of memory address space as the segment
(start address 0, limit = 4GB-1).



Here is the question:
In a device driver, from 16-bit code, I need to get to the selector of a
32-bit segment of the same driver.
I was using IBM's alp.exe assembler and this worked in the following way:

one module, defining all segments (to make them known to linker):
KEECode segment dword public uses16 'CODE'
KEECode ends
... other segments ...
CODE32 segment public dword use32 'CODE'
CODE32 ends


another module:
CODE32 segment public dword use32 'CODE'
CODE32 ends

KEECode segment dword public uses16 'CODE'
...
mov ax,CODE32 ; loads the GDT sel. for the 32-bit code segment into ax
...
KEECode ends


On loading the driver, this was resolved by the loader to load the
static GDT selector of the 32-bit code segment ("CODE32") into ax.


Now, I am forced to move to the Watcom WASM.EXE assembler.
I did the very same as above, but this time, instead of loading the GDT
selector for the 32-bit code segment, it is always the FLAT selector
that is loaded into ax once the driver is loaded in memory.

What is the proper way to reference this 32-bit code segment so that the
proper GDT selector (and not the FLAT selector) is loaded into ax ?
Is this an assembler issue, a linker issue or even both ?


Lars

Hi Lars!

Here's a reference to an installible file system driver that demonstrates
how to work with 16-bit and 32-bit facets:

    Search Hobbes for "driver source code" and you'll find others.
    https://hobbes.nmsu.edu/

    https://hobbes.nmsu.edu/?detail=%2Fpub%2Fos2%2Fdev%2Fdrivers%2FWatcom_IFS_2005-08-28.zip

Also, check out https://www.os2world.com and ask some of the developers
there.  They still have a very active OS/2 community.

--
Rick C. Hodgin



Subject: Re: Referring to a segment
From: wolfgang kern
Newsgroups: comp.lang.asm.x86
Organization: KESYS-development
Date: Tue, 18 Aug 2020 02:19 UTC
References: 1
Path: i2pn2.org!i2pn.org!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: nowh...@nospicedham.never.at (wolfgang kern)
Newsgroups: comp.lang.asm.x86
Subject: Re: Referring to a segment
Date: Tue, 18 Aug 2020 04:19:34 +0200
Organization: KESYS-development
Lines: 19
Approved: fbkotler@myfairpoint.net - comp.lang.asm.x86 moderation team.
Message-ID: <rhfdrl$fsc$1@gioia.aioe.org>
References: <rhedo1$liv$1@solani.org>
Reply-To: nowhere@never.at
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: reader02.eternal-september.org; posting-host="21a3d8e66bff8ac9544e5740995de452";
logging-data="22095"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1870SdN/fgCajWwy7biXG6xkgbJBAX4zOA="
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.1.1
Cancel-Lock: sha1:W9gm0eH8dl8p81XTZy7IJuyinVY=
View all headers
On 17.08.2020 19:11, Lars Erdmann wrote:
Hallo,
Hi,
[...]
What is the proper way to reference this 32-bit code segment so that the proper GDT selector (and not the FLAT selector) is loaded into ax ?
Is this an assembler issue, a linker issue or even both ?

I always avoided detours with improper tools. Could well be that what you miss doesn't exist. 16 bit equivalent to 32 bit Flat code cannot be except if the 16 bit code seg starts at 0:0 which is a pretty bad idea.

If you need two entries which point to the same memory in the GDT then just create them or copy one existing and modify it as desired.
I use two such 16/32 pairs for both code and data [in the HMA range so this memory is accessible by trueRM16 too].
__
wolfgang



Subject: Re: Referring to a segment
From: Lars Erdmann
Newsgroups: comp.lang.asm.x86
Organization: solani.org
Date: Thu, 20 Aug 2020 22:08 UTC
References: 1 2
Path: i2pn2.org!i2pn.org!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: lars.erd...@nospicedham.arcor.de (Lars Erdmann)
Newsgroups: comp.lang.asm.x86
Subject: Re: Referring to a segment
Date: Fri, 21 Aug 2020 00:08:19 +0200
Organization: solani.org
Lines: 45
Approved: fbkotler@myfairpoint.net - comp.lang.asm.x86 moderation team.
Message-ID: <rhms8k$g0a$1@solani.org>
References: <rhedo1$liv$1@solani.org> <rhfdrl$fsc$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: reader02.eternal-september.org; posting-host="4f155279c09df9186598f40614e98622";
logging-data="22398"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+XOd3saibl0tBRnawv1BnGkoq1qSFWnlk="
User-Agent: Mozilla/5.0 (OS/2; Warp 4.5; rv:45.0) Gecko/20100101
Thunderbird/45.8.0
Cancel-Lock: sha1:2uvyu+uL8VZblZ7ALttbSgkDBS0=
View all headers
On 18.08.20 04.19, wolfgang kern wrote:
On 17.08.2020 19:11, Lars Erdmann wrote:
Hallo,
Hi,
[...]
What is the proper way to reference this 32-bit code segment so that
the proper GDT selector (and not the FLAT selector) is loaded into ax ?
Is this an assembler issue, a linker issue or even both ?

I always avoided detours with improper tools. Could well be that what
you miss doesn't exist. 16 bit equivalent to 32 bit Flat code cannot be
except if the 16 bit code seg starts at 0:0 which is a pretty bad idea.

You misunderstood.
It is a 32-bit segment (the segment defined by using the USE32 directive) that is loaded somewhere in virtual address space, with a linear start address <> 0 and the length of all the combined 32-bit code. It is NOT a flat segment even though it is a 32-bit segment.
And this segment is addressed by a GDT selector (and the descriptor that is points to) that happens to have that linear start address and segment limit. This GDT descriptor is created by the OS loader when the driver is loaded.
The one thing that annoys me is that one assembler creates an object file that will contain a fixup that will eventually be replaced by the proper GDT selector (created by the OS loader) whereas the other assembler creates a fixup that will eventually be replaced by the FLAT selector.
I know too little about the OMF format to understand what these 2 assemblers do differently so that the loader will fail in properly fixing up this selector value.


If you need two entries which point to the same memory in the GDT then
just create them or copy one existing and modify it as desired.
I use two such 16/32 pairs for both code and data [in the HMA range so
this memory is accessible by trueRM16 too].

Yes, it would be possible to dynamically allocate my own GDT descriptor and have that set with the proper linear base address and limit (there are OS kernel functions to do that) but that would create an unnecessary GDT entry that already exists (and GDT entries are a scarce resource for a segmented OS that OS/2 still is).

Lars



1
rocksolid light 0.7.2
clearneti2ptor