32-bit real mode loader

[[e-mail]]

Rather than require the IA16 GCC target to
work to my satisfaction so that I can produce
my IO.SYS, for PDOS/386, it seems to me that
I can actually make IO.SYS itself a 32-bit
80386 real mode program.

I'll need to run it through a relocation program
before placing it on the hard disk, so that it
can be loaded at a fixed address in memory.

It might be appropriate to make IO.SYS handle
BIOS calls (as happens now anyway), and use
Smaller C to do that, but use normal GCC 3.2.3
80386 target for both the OS and all applications
that I have source for.

But Smaller C can sort of be a "bridge", and
MSDOS programs can still be run.

I would expect all my 80386 programs to be
relocated (by PDOS) and have cs/ds/es set
to 0.

It's still a bit of a muddle.

BFN. Paul.

[Scott Lurndal]

Post by ***@gmail.com
Rather than require the IA16 GCC target to
work to my satisfaction so that I can produce
my IO.SYS, for PDOS/386, it seems to me that
I can actually make IO.SYS itself a 32-bit
80386 real mode program.
I'll need to run it through a relocation program
before placing it on the hard disk, so that it
can be loaded at a fixed address in memory.

https://en.wikipedia.org/wiki/Position-independent_code

[[e-mail]]

Post by Scott Lurndal

Post by ***@gmail.com
I'll need to run it through a relocation program
before placing it on the hard disk, so that it
can be loaded at a fixed address in memory.

https://en.wikipedia.org/wiki/Position-independent_code

That link says (for Windows DLLs):

this triggers copy-on-write of a memory page containing such global variable

I'm talking about IO.SYS - this is loaded by the boot sector,
so there is no support from anything. So it's unclear to me
whether the 80386 has the instructions required to be
loaded anywhere.

The boot sector is loading it to a fixed location anyway,
so I'm not really concerned about running it through a
relocation program in advance.

BFN. Paul.

[Scott Lurndal]

Post by ***@gmail.com

Post by Scott Lurndal

Post by ***@gmail.com
I'll need to run it through a relocation program
before placing it on the hard disk, so that it
can be loaded at a fixed address in memory.

https://en.wikipedia.org/wiki/Position-independent_code

this triggers copy-on-write of a memory page containing such global variable

Position independent code is generated by the compiler
and linker. It has no run-time impact on any rational
system.

There's no reason that you can't use your gcc with -fPIC to
generate position independent code. Or even write your own
position independent code in assembler.

The entire windows DLL section is specific to the implementation
of windows DLLs and has nothing to do with position independent
code.

Compile your IOSYS.c with -fPIC -ffreestanding.

[[e-mail]]

Post by Scott Lurndal
Compile your IOSYS.c with -fPIC -ffreestanding.

Standard gcc for Windows and my own version both
think that is odd:

C:\devel\pdos\src>gcc -fPIC -ffreestanding -S -D__WIN32__ -I ../pdpclib world.c
world.c:1:0: warning: -fPIC ignored for target (all code is position independent) [enabled by default]
/* world.c - print "hello, world".
^

C:\devel\pdos\src>gccwin -fPIC -ffreestanding -S -D__WIN32__ -I ../pdpclib world.c
world.c:0: warning: -fPIC ignored for target (all code is position independent)

But my version targeting a.out did indeed generate
references to a GOT:

C:\devel\pdos\src>gcc386 -fPIC -ffreestanding -S -D__32BIT__ -I ../pdpclib world.c


But while ever I'm dependent on the BIOS, I need to
use Smaller C, not gcc.

One thing I would like to know is how to generate a
Windows executable that is not loaded at a fixed
address.

Rod previously gave me "pie", which works for a
later gcc:

gcc -pie -s world.c

I think this is the proof it worked:

000260 00000000 400030C0 2E72656C 6F630000 ***@.0..reloc..

But I want to replicate that with my own GCC 3.2.3
and binutils.

C:\devel\pdos\src>gccwin -S -pie -s -I ../pdpclib -D__WIN32__ world.c
gccwin: unrecognized option `-pie'

Noting that I want to run "aswin" and "ldwin" as separate steps,
so I don't think it is important that gccwin doesn't recognize
that option, as I think it is the linker that counts to generate
the relocation information.

Even when I try doing it with standard Cygwin, ie:

gcc -pie -S world.c
as -o world.o world.s
ld -r world.o

I can see "rdata" in the executable, but not "reloc".

I'll try to get the Win PE loader working under bios.c today
to see if I can get some insights into these executables.

BFN. Paul.

[[e-mail]]

Post by ***@gmail.com
I'll try to get the Win PE loader working under bios.c today
to see if I can get some insights into these executables.

I have some more information. As noted, all I need for
the current task is for relocations to not be stripped.
"pie" with a GOT is a separate exercise.

I got this to work:

gccwin -S -Os -fno-common -I. -o osworld.s osworld.c
aswin -o osworld.o osworld.s

gccwin -S -Os -fno-common -I. -o genstart.s genstart.c
aswin -o genstart.o genstart.s

gccwin -S -Os -fno-common -I. -o osfunc.s osfunc.c
aswin -o osfunc.o osfunc.s

ld -pie -s -e ___crt0 -o osworld.exe genstart.o osworld.o osfunc.o

(so using my own gccwin/aswin, but using standard
Cygwin "ld")

objdump -p osworld.exe

PE File Base Relocations (interpreted .reloc section contents)

Virtual Address: 00001000 Chunk size 24 (0x18) Number of fixups 8
reloc 0 offset 7 [1007] HIGHLOW
reloc 1 offset f [100f] HIGHLOW

ie it looks good to me.

But any other option I chose with ld, instead of "-pie", such
as --dynamicbase, -r, -q, --embedded-relocs, --disable-auto-image-base
results in:

Characteristics 0x30f
relocations stripped

The reason I'm trying to get rid of "-pie" and replace it
with something else is:

1. I don't think "pie" is what I'm really creating. It's not
using a GOT.

2. I would like to use my ldwin instead of Cygwin ld, and
ldwin doesn't have "-pie" so I need something else.

I can use Cygwin "ld" with "pie" for now though, to do my
BIOS work.

C:\devel\pdos\bios>ldwin --version
GNU ld version 2.14 20030612

C:\devel\pdos\bios>ld --version
GNU ld (GNU Binutils) 2.23.52.20130309

BFN. Paul.

[[e-mail]]

Post by ***@gmail.com
But any other option I chose with ld, instead of "-pie", such
as --dynamicbase, -r, -q, --embedded-relocs, --disable-auto-image-base
Characteristics 0x30f
relocations stripped
The reason I'm trying to get rid of "-pie" and replace it
2. I would like to use my ldwin instead of Cygwin ld, and
ldwin doesn't have "-pie" so I need something else.

I started debugging ldwin because of another problem
and took another look at relocations, and stumbled
across this:

https://insights.sei.cmu.edu/blog/when-aslr-is-not-really-aslr-the-case-of-incorrect-assumptions-and-bad-defaults/

While testing a simple "Hello world" application produced with mingw-w64, the addition of the following line before the main function resulted in an executable file that retained its relocation table:

__declspec(dllexport)


I tried adding that before:
void mainCRTStartup(void)

which all of my C programs get, and voila, relocations
were retained!!!

What is happening?

And ideally I would like the same thing for my a.out
modules, which don't use declspec.

Thanks. Paul.

[[e-mail]]

Post by ***@gmail.com
which all of my C programs get, and voila, relocations
were retained!!!
What is happening?

Here is what is happening (in "ld"), and how I fixed it:

#ifndef PUREISO
/* If we are not building a DLL, when there are no exports
we do not build an export table at all. */
if (!pe_dll_export_everything && pe_def_file->num_exports == 0
&& !(info->shared))
return;
#endif

#ifndef PUREISO
if (pe_def_file->num_exports == 0 && !(info->shared))
return;
#endif

It is bypassing building the relocations just because
there are no exported symbols. Weird.

I was able to hone in on the code by being able to
compare with and without declspec.

Post by ***@gmail.com
And ideally I would like the same thing for my a.out
modules, which don't use declspec.

Now let's see if that leads the way to doing the same
thing for a.out.

BFN. Paul.

[[e-mail]]

Post by ***@gmail.com
Now let's see if that leads the way to doing the same
thing for a.out.

Yep, got it! I was previously under the impression that
binutils 2.14a didn't support relocation, but it does, it's
just being bypassed for some reason.

I'm not sure there's actually any way to say you don't
want a relocatable. Maybe the proper fix is to make
it relocatable by default and wait for someone to
create an option to switch off relocations.

BFN. Paul.



C:\devel\binutils-2.14a\bfd>cvs diff aoutx.h
Index: aoutx.h
===================================================================
RCS file: c:\cvsroot/binutils-2.14a/bfd/aoutx.h,v
retrieving revision 1.1.1.1
diff -r1.1.1.1 aoutx.h
3762c3762
< if (info->relocateable)
---

Post by ***@gmail.com
if (PUREISO || info->relocateable)

3806c3806
< if (info->relocateable)
---

Post by ***@gmail.com
if (PUREISO || info->relocateable)

4791c4791
< if (finfo->info->relocateable && rel_size > 0)
---

Post by ***@gmail.com
if ((PUREISO || finfo->info->relocateable) && rel_size > 0)

4938c4938
< if (relocateable)
---

Post by ***@gmail.com
if (PUREISO || relocateable)

5259c5259
< if (relocateable)
---

Post by ***@gmail.com
if (PUREISO || relocateable)

[Rod Pemberton]

On Fri, 2 Apr 2021 04:43:03 -0700 (PDT)

Post by ***@gmail.com
I can actually make IO.SYS itself a 32-bit
80386 real mode program.

Did I suggest that previously? ...

--