Author Topic: new gcc toolchain  (Read 3088 times)

kerravon

  • Jr. Member
  • **
  • Posts: 50
  • Karma: +0/-0
    • View Profile
Re: new gcc toolchain
« Reply #15 on: March 16, 2024, 12:10:39 pm »
Next bug in next message.
As promised, here it is.

Using that previous batch file, which creates a blank disk with 16 heads per cylinder and 63 sectors per track, I hop into lvmgui and it is happy to create a partition. I choose to do "start of free space" and "primary partition". That creates final1.vhd in the attached. Later on I create a non-bootable compatible volume (final2.vhd) and later on I format it as FAT32 (final3.vhd).

The only change in the MBR between final1 and final3 is the partition type is changed from 06 (FAT16) to 0C (FAT32 using - ironically - LBA). The start/end partition values remain unchanged.

So here is final3.vhd:

C:\vbox>hexdump final3.vhd 0x1b0 80
0001B0  00000000 00000000 00000000 33CC8001  ............3...
0001C0  01000C0F FFB23F00 00009190 0E000000  ......?.........
0001D0  00000000 00000000 00000000 00000000  ................
0001E0  00000000 00000000 00000000 00000000  ................
0001F0  00000000 00000000 00000000 000055AA  ..............U.

Now we can see the x'0c' (FAT32) at 0x1C2 followed by the partition end head number (15 - ie maximum), the FF is sector 63 (x'3f') plus the 2 high bits set for the cylinder number (so B2 becomes 3B2).

So that means that cylinder 3B2 is completely maxed out - as is reasonable - giving cylinder alignment (although note that the starting LBA (after the x'b2') is 3F, so zero based means 40 sectors, ie it starts on head/track 1, sector 1. ie ArcaOS only needs track alignment, not cylinder alignment.

But regardless, the end of the partition is cylinder-aligned, meaning counting from the beginning of the disk (cylinder 0) to the end of the full cylinder 3B2 (946), we have a total of 947 cylinders with various stuff on it (starting with the MBR) or at least, assigned. 947 * 16 * 63 = 954576 sectors "in use". LBA is 0-based counting, so that means 0 to 954575 is "in use". With LBA 954575 being the end sector (inclusive).

That is hex e90cf

But ArcaOS has put an end LBA of e9091

That means if another system tries to use this disk to create the next partition, and uses LBA, as is normal, it will start at x'e9092', potentially trashing data in the first partition.

What is it out by?

cf-91 = decimal 62

So there's the ArcaOS bug - unless I have misdiagnosed.

And that's all the bugs I know of at the moment.

kerravon

  • Jr. Member
  • **
  • Posts: 50
  • Karma: +0/-0
    • View Profile
Re: new gcc toolchain
« Reply #16 on: March 16, 2024, 12:14:07 pm »
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?

Sorry - this is just meant to be a starter system.

I don't think there is any debugging capability. I always use printfs to debug. Except when there is a crash and I get the EIP and match it to the link map and assembler listings, and I read the assembler code and match it to the C code.

And I'm always doing optimized compiles where debugging isn't available anyway as far as I know.

kerravon

  • Jr. Member
  • **
  • Posts: 50
  • Karma: +0/-0
    • View Profile
Re: new gcc toolchain
« Reply #17 on: March 16, 2024, 05:34:53 pm »

So there's the ArcaOS bug - unless I have misdiagnosed.


I think I have misdiagnosed and it is parted that is wrong.

That's supposed to be number of sectors, not end LBA.

Will get back when confirmed.

kerravon

  • Jr. Member
  • **
  • Posts: 50
  • Karma: +0/-0
    • View Profile
Re: new gcc toolchain
« Reply #18 on: March 16, 2024, 06:18:15 pm »
Unrelated to the previous message, I have (hopefully temporarily) given up 4k alignment to produce a pdoso.zip that is acceptable to ArcaOS. Available at pdos.org

And independent of that, there is now ELF support under PDOS/386 via makefile.lnp (pdos.zip not pdoso.zip) which will hopefully evolve to be the same as pdoso.zip for OS/2.


kerravon

  • Jr. Member
  • **
  • Posts: 50
  • Karma: +0/-0
    • View Profile
Re: new gcc toolchain
« Reply #19 on: March 17, 2024, 02:10:25 am »

I think I have misdiagnosed and it is parted that is wrong.

That's supposed to be number of sectors, not end LBA.

Will get back when confirmed.

A hell of a ride.

Both Robert and I had confusion/misunderstandings about different things and that caused numerous emails back and forth, each insisting the numbers proved something the other wouldn't accept.

So when I saw in Wikipedia that the last value was meant to be a count, not the end LBA address - and having previously calculated that the end CHS matched the end LBA which made me think parted was correct - I was confident that the sector count was wrong, and the end CHS was likely correct.

Turns out that it was a correct count all along, and that the end CHS had similarly been implemented as an "offset" rather than an absolute value, and Robert believed that was exactly what it was meant to be, and insisted the values all matched. And furthermore, Windows and Linux didn't have a problem either. But they don't use those CHS values, so that's not a fair test. And furthermore, Windows doesn't seem to bother setting them to reasonable values, relying on the fact that they are supposed to be ignored in type x'0c'.

We had to go right back to MSDOS to confirm the behavior as "definitive", and then Robert made the required code change.

This was combined with inconsistent behavior from ArcaOS. It seems that the start CHS can be arbitrary, but the end CHS should be maxed out in the last cylinder. But ArcaOS doesn't strictly enforce that. So when I was making adjustments, and it worked, I would form a conclusion, but then have that conclusion invalidated by another test.

However, I eventually got it to work, and now there is a pdoso.zip that starts on sector 504, so I'm only wasting 230k or 200k depending on how you count (63 vs 128) in order to get both track alignment and 4k alignment.

In addition to that, pdoso.zip was updated with a new pdld so that ArcaOS can build ELF executables if that is useful for some reason. It won't run them though. You have to run them on PDOS/386 (either pdos.zip or pdoso.zip) or real Linux.

I'm expecting to now switch to replicating for Linux what I have just done for OS/2.

kerravon

  • Jr. Member
  • **
  • Posts: 50
  • Karma: +0/-0
    • View Profile
Re: new gcc toolchain
« Reply #20 on: March 17, 2024, 08:14:49 am »
I switched from FAT32 to FAT16 in order to test that, and managed to crash ArcaOS 5.0.8 attempting to add the attached volume. I will report it via the official channels.

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4871
  • Karma: +103/-1
    • View Profile
Re: new gcc toolchain
« Reply #21 on: March 17, 2024, 08:47:25 am »
I switched from FAT32 to FAT16 in order to test that, and managed to crash ArcaOS 5.0.8 attempting to add the attached volume. I will report it via the official channels.

Did you change the partition type?
Edit: seems it is 06, so yes.
DFsee sees has this,
Code: [Select]
DFS partition  Id : 21  disk nr : 17  = FixedDisk Diskgeo = CHS:    957  16  63
 System Indicator : 0x06       = FAT16         UNIX devicename: /dev/Ida1     
 FileSyst. format : FAT16                     Windows BOOT.INI: Partition(1)   
 Partition   type : Primary    Visible        Bootrec-OEM-name: MSWIN4.1       
 Partition   size : 0x000E9091 =   466.1 MiB  =    946.938 cylinders           
FAT entry size of : 16  Bits   (FAT16   ) will be forced.                     
Size of FAT entry : 16  Bits    FAT label in Root : PDOS                       
FAT DIRTY status  : 0x00 = CLEAN                                               
FAT1 CRC-32 value : 0x861c6346  FAT2 CRC-32 value : 0x861c6346 = OK           
The FAT entry size seems weird.
« Last Edit: March 17, 2024, 09:16:13 am by Dave Yeo »

kerravon

  • Jr. Member
  • **
  • Posts: 50
  • Karma: +0/-0
    • View Profile
Re: new gcc toolchain
« Reply #22 on: March 17, 2024, 08:58:47 am »
I switched from FAT32 to FAT16 in order to test that, and managed to crash ArcaOS 5.0.8 attempting to add the attached volume. I will report it via the official channels.

Did you change the partition type?

Yes, 06 for FAT16.

Created like this:

D:\scratch\xxx>type doit.bat
del pdos.vhd
parted mkpart 0x80,0x06,63,954513 pdos.vhd
mkdosfs --blocks 477256 --offset 63 -F 16 -n "PDOS" pdos.vhd
mcopy -i pdos.vhd --offset 63 hi.txt ::

D:\scratch\xxx>


Bug report:

https://mantis.arcanoae.com/view.php?id=3616

kerravon

  • Jr. Member
  • **
  • Posts: 50
  • Karma: +0/-0
    • View Profile
Re: new gcc toolchain
« Reply #23 on: March 17, 2024, 09:03:54 am »

parted mkpart 0x80,0x06,63,954513 pdos.vhd
mkdosfs --blocks 477256 --offset 63 -F 16 -n "PDOS" pdos.vhd
mcopy -i pdos.vhd --offset 63 hi.txt ::


BTW, all the above tools, and almost all the source code on the PDOS/386 disks - is C90 compliant and thus should compile on basically any C compiler, including the gcc 3.2.3 that I ship as LX executables.

I simply haven't constructed a makefile and executed the makefile to build them.

That is basically an exercise for the reader.

I have stopped at the point where all the essential tools to do a C90 compile have been built.

So using nothing more than either base OS/2 plus the tools on the PDOS/386 disk - or just PDOS/386 itself - you should be able to reconstruct the world armed with a C90 compiler and a masm-subset assembler.