Author Topic: new gcc toolchain  (Read 1818 times)

kerravon

  • Jr. Member
  • **
  • Posts: 50
  • Karma: +0/-0
    • View Profile
new gcc toolchain
« on: March 14, 2024, 03:46:07 pm »
I spent a lot of effort making the GCC 3.2.3 source code
C90-compliant instead of being riddled with POSIX stuff,
in order to allow the compiler to be hosted on the IBM mainframe.

I have now created a makefile for OS/2 that uses itself
to build itself. But it's quite simple to modify if you want
to use some other compiler in order to bootstrap from
source. I created such a makefile for Watcom and
Microsoft C for Windows, but don't have anything for
OS/2 currently (but you can bootstrap on Windows
from source if you want, and then use that to continue
over to OS/2).

Also in the chain are two assemblers (pdas and as86).
Note that as86 is a subset of Microsoft MASM unlike
most other assemblers available (including pdas) that
require some other syntax.

So with standard C90 and standard MASM you can
build everything required. The object code produced
is coff, but the pdld linker will take coff input and
produce an LX binary.

If you are interested, get pdoso.zip from http://pdos.org
and because I don't know how to make parted (see
\devel\parted on the disk) produce a VHD that can be
mounted in Virtualbox for use by OS/2 (I use 128
sector as the starting sector (for 4k alignment), but I
tried changing it to 504 (for both 63 sector multiple and
4k alignment), but that wasn't accepted either. But I
just realized now that maybe it needs me to specify 0C
instead of 0B:

< parted --boot devel\pdos\src\mbr.com mkpart 0x80,0x0b,504,956416 ..\pdos.vhd
---
> parted --boot devel\pdos\src\mbr.com mkpart 0x80,0x0b,128,956416 ..\pdos.vhd

given that it is FAT32.

So on Windows or Linux you need to mount a VHD that
is acceptable to OS/2 and then copy the contents of
pdoso.vhd across.

After that, let's say the new disk is the P drive, you can do:

path %path%;p:\dos
cd \devel\pdos\pdpclib
pdmake -f makefile.sos
(run pdptest abc def if you want)

cd \devel
unzip \misc\custom gcc-stage*
unzip gcc-stage*
del gcc-stage*

cd gcc\gcc
copy config\i386\genfiles (don't forget this step)
pdmake -f os2.mak

I see that "fc" is missing, but no problem, you can:

cd \devel\pdos\pdpclib
ren pdptest.c pdptest.bak
copy ..\util\fc.c pdptest.c
pdmake -f makefile.sos
copy pdptest.exe \dos\fc.exe

cd \devel\gcc\gcc
fc /b \dos\gccwin.exe gcc-new.exe

and have a byte-identical copy of the compiler.

Note that gccwin.exe is a historical name
(EDIT: for this OS/2 LX executable).
I'm planning
on renaming it to gcc386.exe in the future.

Note that I have only compiled the essential binaries
needed to be able to compile anything else you may need.
ie the other stuff in \dos are Windows executables mostly,
so "need" to be replaced, eventually.

I am hoping to replace gccwin.exe with SubC anyway.

Is anyone interested in compilers such that they would
like to assist with this?

A build error (will be fixed next drop) is preventing this
from working:

[P:\devel\pdos\world]pdmake -f worldos2.mak
pdcc -E -D__SUBC__ -U__WIN32__ -D__OS2__ -D__32BIT__ -Dunsigned= -Dlong=int -Dsh
ort=int -Dconst= -Ddouble=int -I ../pdpclib -o world.i world.c
sccwin -S world.i
rm -f world.i
pdas -o world.obj --oformat coff world.s
rm -f world.s
pdld -s --no-insert-timestamp -nostdlib --oformat lx  --stub ../pdpclib/needpdos
.exe -o world.exe ../pdpclib/os2strt.obj world.obj ../pdpclib/pdpos2.lib ../pdpc
lib/os2.lib

[P:\devel\pdos\world]world
hello, world

[P:\devel\pdos\world]


Hopefully by then I have a mountable disk too.

Note that I cherish old targets including i370 unlike
others who like to obsolete old targets. YMMV. So
yeah, I have been patiently plugging away at GCC 3.2.3
(including this latest change), for 20 years, instead of
"keeping up with the Joneses". And all source code is
in C90, not Turtle Graphics or whatever "modern" GCC
is written in these days. Except for the minimal
assembler required in the C library.

All clean 32-bit code too (not a single bit of 16-bit in any
executable on the disk except for the MBR, boot sector and
IO.SYS which aren't used if you are running under OS/2),
and all memory allocated with OBJ_ANY.

BFN. Paul.


P.S. gccwin also rebuilds itself on PDOS/386 - which is
what that pdoso.vhd is. PDOS/386 is a sufficient OS/2
mini-clone for that task.

P.P.S. Let me know if you don't know how to mount a
VHD on either Windows or Linux.
« Last Edit: March 14, 2024, 04:23:07 pm by kerravon »

kerravon

  • Jr. Member
  • **
  • Posts: 50
  • Karma: +0/-0
    • View Profile
Re: new gcc toolchain
« Reply #1 on: March 15, 2024, 01:37:52 am »
If you are interested, get pdoso.zip from http://pdos.org
and because I don't know how to make parted (see
\devel\parted on the disk) produce a VHD that can be
mounted in Virtualbox for use by OS/2 (I use 128
sector as the starting sector (for 4k alignment), but I
tried changing it to 504 (for both 63 sector multiple and
4k alignment), but that wasn't accepted either. But I
just realized now that maybe it needs me to specify 0C
instead of 0B:

parted --boot devel\pdos\src\mbr.com mkpart 0x80,0x0c,504,956416 ..\pdos.vhd

Still not accepted by LVMGUI. It says it is free space, but
also can't create a partition in that free space.

Code: [Select]
C:\vbox>hexdump pdoso.vhd 0 512
000000  FA33C08E D88EC0B8 50008ED0 BC0077FB  .3......P.....w.
000010  BE007CBF 0006B900 01F3A5B8 500050B8  ..|.........P.P.
000020  240150CB 0E1F8816 B502BEBE 02B90400  $.P.............
000030  F6048075 0A83C610 E2F6BDBD 01EB6F80  ...u..........o.
000040  7C0400BD D8017466 26C706FE 7D0000B8  |.....tf&...}...
000050  00008EC0 B408BF00 00CD1372 1F80E13F  ...........r...?
000060  B500890E B1028AD6 B60083C2 018916B3  ................
000070  028B4408 8B540AE8 B600EB09 8A74018A  ..D..T.......t..
000080  4C028A6C 03B80000 8EC0BB00 7CE8D300  L..l........|...
000090  26813EFE 7D55AABD 14027512 8A16B502  &.>.}U....u.....
0000A0  8BEEB800 0050B800 7C50CBCD 1045B40E  .....P..|P...E..
0000B0  8A46003C 0075F487 DBFBF4EB FA4E6F20  .F.<.u.......No
0000C0  61637469 76652070 61727469 74696F6E  active partition
0000D0  20666F75 6E642100 41637469 76652070   found!.Active p
0000E0  61727420 68617320 696E7661 6C696420  art has invalid
0000F0  70617274 6974696F 6E207479 70652100  partition type!.
000100  4661696C 65642074 6F207265 61642056  Failed to read V
000110  42522100 56425220 6D697373 696E6720  BR!.VBR missing
000120  61613535 20736967 6E617475 72652100  aa55 signature!.
000130  F736B102 B5008ACA FEC133D2 F736B302  .6........3..6..
000140  8AF2528A F0B00051 B102D3E8 598AE65A  ..R....Q....Y..Z
000150  0BC8C350 528A16B5 02B80000 CD1372F5  ...PR.........r.
000160  5A58C350 53515206 8A16B502 B80102CD  ZX.PSQR.........
000170  137305E8 DDFFEBF0 075A595B 58C35053  .s.......ZY[X.PS
000180  8AC5E80D 008AC1E8 0800B020 E818005B  ........... ...[
000190  58C38AD8 51B104D2 E859E802 008AC324  X...Q....Y.....$
0001A0  0F049027 14402753 BB0000B4 0ECD105B  ...'.@'S.......[
0001B0  C3000000 00000000 5F20DD21 00008008  ........_ .!....
0001C0  01000C0D 0EB4F801 00000098 0E000000  ................
0001D0  00000000 00000000 00000000 00000000  ................
0001E0  00000000 00000000 00000000 00000000  ................
0001F0  00000000 00000000 00000000 000055AA  ..............U.

C:\vbox>

Any ideas? Again - I want to use this (public domain) parted via an automated procedure, not use LVM to create the partition. I'm happy to use LVM after the fact though (it would just be documented what you need to do).

Thanks. Paul.

kerravon

  • Jr. Member
  • **
  • Posts: 50
  • Karma: +0/-0
    • View Profile
Re: new gcc toolchain
« Reply #2 on: March 15, 2024, 02:07:31 am »
Note that I actually use two commands:

parted --boot devel\pdos\src\mbr.com mkpart 0x80,0x0c,504,956416 ..\pdos.vhd

mkdosfs --boot devel\pdos\src\fat32.com --blocks 478208 --offset 504 -F 32 -n "PDOS" ..\pdos.vhd


The second command is also on the same disk:

D:\devel\dosfstools>grep -i mkdosfs Makefile.pdw
makefile.pdw: all: clean mkdosfs.exe mcopy.exe mmd.exe mls.exe
makefile.pdw: mkdosfs.exe: lib.o mkfs.o $(COBJ)
makefile.pdw:   $(LD) -s -o mkdosfs.exe ../pdos/pdpclib/w32start.o lib.o mkfs.o $(COBJ) ../pdos/pdpclib/msvcrt.a
makefile.pdw:   rm -f *.o mkdosfs.exe

D:\devel\dosfstools>


Like parted:

D:\devel\parted>dir parted.c
 Volume in drive D is PDOS
 Volume Serial Number is 2218-141F

 Directory of D:\devel\parted

2024-03-14  01:58 AM            13,130 parted.c


The executables are win32:

D:\DOS>dir parted* mkdosfs*
 Volume in drive D is PDOS
 Volume Serial Number is 2218-141F

 Directory of D:\DOS

2024-03-14  02:02 AM            10,752 parted.exe

 Directory of D:\DOS

2024-03-14  02:02 AM            17,408 mkdosfs.exe


but I can create makefiles for OS/2 LX if that's an issue.

The author of both utilities (Robert Pengelly) is available to make any modifications if there is something specific that is being done incorrectly (or at least, unsuitable for OS/2).

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4811
  • Karma: +100/-1
    • View Profile
Re: new gcc toolchain
« Reply #3 on: March 15, 2024, 02:20:56 am »
Can you zip or 7z pdos.vhd and post it here? Seems an empty vhd should compress very well.

kerravon

  • Jr. Member
  • **
  • Posts: 50
  • Karma: +0/-0
    • View Profile
Re: new gcc toolchain
« Reply #4 on: March 15, 2024, 03:01:11 am »
Can you zip or 7z pdos.vhd and post it here? Seems an empty vhd should compress very well.
Sure. Here it is, empty. I confirmed that lvmgui won't let me create a partition with the free space (not that I want a new partition anyway), and also confirmed that Windows is fine with it.

Andy Willis

  • Sr. Member
  • ****
  • Posts: 294
  • Karma: +7/-0
    • View Profile
Re: new gcc toolchain
« Reply #5 on: March 15, 2024, 03:24:57 am »
It likely is the partition alignment, or maybe less likely the drive geometry:
https://www.arcanoae.com/faqwd/how-can-i-tell-if-my-current-disk-drive-is-compatible-with-arcaos/

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4811
  • Karma: +100/-1
    • View Profile
Re: new gcc toolchain
« Reply #6 on: March 15, 2024, 03:43:15 am »
DFSee has this warning,
Code: [Select]
│Warning: The GEO Head/Sectors fields 16/63 in the bootsector         
│         do NOT match the current disk geometry values 14/63!       
│This may prevent using the partition from some operating systems like
│OS/2, eCS or windows that check this for consistency. The most likely
│cause for this is MOVING or CLONING the partition between different 
│primary locations, or between a primary and logical location. Use the
│FIXPBR command or 'Fix HiddenSectors/Geo value' menu to correct this.

I ran "Fix HiddenSectors/Geo value" on the vhd and attaching it.

kerravon

  • Jr. Member
  • **
  • Posts: 50
  • Karma: +0/-0
    • View Profile
Re: new gcc toolchain
« Reply #7 on: March 15, 2024, 04:41:50 am »
The GEO Head/Sectors fields 16/63 in the bootsector         
do NOT match the current disk geometry values 14/63!
Thanks for that - I'll pass it on to Robert. I tried zapping those values to be correct, but it still didn't change anything.

Quote
I ran "Fix HiddenSectors/Geo value" on the vhd and attaching it.
Thanks. That still doesn't work for me in lvmgui - still says it is free space and still can't create a partition in that alleged free space. But let me try changing the start partition to LBA 14*63*4, which is under 2 MB wastage.
« Last Edit: March 15, 2024, 04:43:49 am by kerravon »

kerravon

  • Jr. Member
  • **
  • Posts: 50
  • Karma: +0/-0
    • View Profile
Re: new gcc toolchain
« Reply #8 on: March 15, 2024, 04:56:40 am »
Thanks. That still doesn't work for me in lvmgui - still says it is free space and still can't create a partition in that alleged free space. But let me try changing the start partition to LBA 14*63*4, which is under 2 MB wastage.
Still no change - but although I zapped the geometry, I didn't change the hidden sectors, so let me first get Robert to decide what he would like to do to resolve the known inconsistency. Will hopefully have an answer overnight. Thanks for all the help.

kerravon

  • Jr. Member
  • **
  • Posts: 50
  • Karma: +0/-0
    • View Profile
Re: new gcc toolchain
« Reply #9 on: March 15, 2024, 10:55:21 pm »
Thanks. That still doesn't work for me in lvmgui - still says it is free space and still can't create a partition in that alleged free space. But let me try changing the start partition to LBA 14*63*4, which is under 2 MB wastage.
Still no change - but although I zapped the geometry, I didn't change the hidden sectors, so let me first get Robert to decide what he would like to do to resolve the known inconsistency. Will hopefully have an answer overnight. Thanks for all the help.

Robert looked at the VHD that was created by parted and said that the boot sector and VHD were consistent - 16 (x'10') as the number of heads, not 14. So I don't know why dfsee is saying 14 (I'm not saying dfsee is wrong - I just don't know where it is getting that from, as there is no x'0E' anywhere - and no x'0D' either in case it is 0-based counting).

He bought ArcaOS so that he could test it for himself, but after a lot of effort couldn't figure out what was happening, and he is at a loss of what to do without documentation. Is there any documentation for LVM?

Although he doesn't strictly need LVM - he only needs to get as far as the partition being accepted by ArcaOS so that LVM info can be added.

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4811
  • Karma: +100/-1
    • View Profile
Re: new gcc toolchain
« Reply #10 on: March 15, 2024, 11:25:00 pm »
Not much. Help lvm for the command line parameters, addendum.inf (toolkit) has the ioctl programming.
DFsee is available at https://dfsee.com, Jan the author, is pretty knowledgeable, I believe there is a mailing list.

kerravon

  • Jr. Member
  • **
  • Posts: 50
  • Karma: +0/-0
    • View Profile
Re: new gcc toolchain
« Reply #11 on: March 15, 2024, 11:29:15 pm »
Not much. Help lvm for the command line parameters, addendum.inf (toolkit) has the ioctl programming.
DFsee is available at https://dfsee.com, Jan the author, is pretty knowledgeable, I believe there is a mailing list.
Ok, thanks. But good news - I was looking in the VBR for an issue, as that is what "boot sector" means to me. I have found an issue with the MBR (high 2 bits of cylinder number not being stored in sector number). I'll report back later.

Tom

  • Full Member
  • ***
  • Posts: 196
  • Karma: +5/-0
    • View Profile
Re: new gcc toolchain
« Reply #12 on: March 15, 2024, 11:48:40 pm »
He bought ArcaOS so that he could test it for himself, but after a lot of effort couldn't figure out what was happening, and he is at a loss of what to do without documentation. Is there any documentation for LVM?

Although he doesn't strictly need LVM - he only needs to get as far as the partition being accepted by ArcaOS so that LVM info can be added.

LVM documentation can be found at Alex Taylor's website: https://altsan.org/os2/toolkits/lvm/index.html

kerravon

  • Jr. Member
  • **
  • Posts: 50
  • Karma: +0/-0
    • View Profile
Re: new gcc toolchain
« Reply #13 on: March 16, 2024, 11:23:07 am »
DFSee has this warning,
Warning: The GEO Head/Sectors fields 16/63 in the bootsector         
do NOT match the current disk geometry values 14/63!

Ok, it's been a hell of a ride, with multiple bugs involved.

Let's go through them.

First, (I believe) that DFSee warning is incorrect. They are right about the bootsector values, but wrong about the geometry having 14 heads. It is correctly set to 16 heads.

Running this batch file on Windows:

C:\vbox\final>type doit.bat
del temp.vhd
del temp*.dat
del pdos.vhd
parted mkpart 0x80,0x0c,63,956416 temp.vhd
zcalc 948*63*16+15*63+1
zfill temp1.dat 489717760
xychop temp.vhd temp2.dat 489717760 489718271
copy /b temp1.dat+temp2.dat pdos.vhd
fc /b temp.vhd pdos.vhd

C:\vbox\final>

produces a VHD footer of:

C:\vbox\final>hexdump temp2.dat
000000  636F6E65 63746978 00000002 00010000  conectix........
000010  FFFFFFFF FFFFFFFF 2D8825AC 77696E20  ........-.%.win
000020  00060001 5769326B 00000000 1D308000  ....Wi2k.....0..
000030  00000000 1D308000 03B4103F 00000002  .....0.....?....
000040  FFFFEA8E 73730D77 04246D1E 46011211  ....ss.w.$m.F...
000050  27221837 00000000 00000000 00000000  '".7............

with offset 3A clearly set to x'10', ie number of heads 16.

You can see the number of cylinders (x'3B4' = 948) and the number of sectors after that (x'3F' = 63).


What the message is probably referring to is one of these fields in the partition entry of the MBR:

0001C0  01010C0D 0EB4

The x'0d' is the end of partition head number, ie head number 13, ie the last cylinder has 14 heads being used (0 to 13), with the last head only partially containing data.

That partial data is the x'0e' - 14 - the 14th sector (1 to 14), out of the 63 available sectors.

That (unfortunate) end CHS is due to the parameters given to parted - I haven't given it enough space to complete that last cylinder. So one bug (sort of a bug) is in my batch file - I need to either increase or decrease the space to get an exact cylinder boundary.

There is another bug (already committed - but the bug fix had another bug - and that has been corrected but not committed yet) - the cylinder number is B4. It should actually be 3B4 and the x'3' needs to be put into the top 2 bits of the sector number that is currently x'0E'.

Anyway, DFSee could be incorrectly reporting either of those values that are "14" as "geometry". It's not. It's either number of heads that have full or partial data in the last cylinder of the partition, or it is the number of sectors in the last track/head of the last cylinder of the partition - either thing requires a DFSee bug fix (unless I've misdiagnosed).

Next bug in next message.

aziz

  • Newbie
  • *
  • Posts: 3
  • Karma: +0/-0
    • View Profile
Re: new gcc toolchain
« Reply #14 on: March 16, 2024, 11:48:25 am »
Before I am looking deeper into it, I have a question:

How does this toolchain handle debugsymbols?

If I was to compile something with gcc -g ... do the debugsymbols end up in the exe file? If so, then what type of debugsymbols and is there a debugger on OS/2 that is compatible with those?