Menu
▾
▴
reactos-kernel
|
From: Eric K. <ek...@rz...> - 2001-10-15 00:17:25
|
Hi! Today I wanted to publish a new gcc and binutils release. Instead of just doing that I fixed a few older bugs in ld and sent the patches to Danny Smith (MinGW maintainer). The ld-patch allows the creation of dll's using 'gcc -shared ...'. When fastcall functions were exported, the created dll was broken. If the patches are okay and Danny doesn't find any more bugs, he will publish a new MinGW release and the fastcall-feature will finally be official. :-)) I hope you don't mind the delay, Eric Kohl ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Phillip S. <ps...@cf...> - 2001-10-15 00:31:22
|
You didn't happen to also fix the bug that prevents it from generating binary output so we don't have to have djgpp to compile freeloader did you? ;) At 01:52 AM 10/15/2001 +0200, you wrote: >Hi! > >Today I wanted to publish a new gcc and binutils release. Instead of just >doing that I fixed a few older bugs in ld and sent the patches to Danny >Smith (MinGW maintainer). The ld-patch allows the creation of dll's using >'gcc -shared ...'. When fastcall functions were exported, the created dll >was broken. > >If the patches are okay and Danny doesn't find any more bugs, he will >publish a new MinGW release and the fastcall-feature will finally be >official. :-)) > >I hope you don't mind the delay, > >Eric Kohl ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Eric K. <ek...@rz...> - 2001-10-15 10:31:19
|
Phillip Susi <ps...@cf...> wrote: > You didn't happen to also fix the bug that prevents it from generating > binary output so we don't have to have djgpp to compile freeloader did you? ;) > No! And I'm afraid we cannot build a 'merged' toolset that supports mingw and djgpp. :-( I compared the object files generated by mingw and djgpp. They are entirely different. Mingw generates calls to alloca() in tui.o and djgpp doesn't. So the problem is not only the linker, it's the compiler too. Just try to build FreeLoader using mingw and you'll see. Btw, I guess the M$ developers still have to use VC 1.52 (16 bit) to build the WinXP boot code. ;) - Eric Kohl ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Robert C. <rob...@it...> - 2001-10-15 11:39:38
|
----- Original Message ----- From: "Eric Kohl" <ek...@rz...> To: <ros...@re...> Sent: Monday, October 15, 2001 8:27 PM Subject: [ros-kernel] Re: Gcc and binutils release > > Phillip Susi <ps...@cf...> wrote: > > > > You didn't happen to also fix the bug that prevents it from generating > > binary output so we don't have to have djgpp to compile freeloader did > you? ;) > > > No! And I'm afraid we cannot build a 'merged' toolset that supports mingw > and djgpp. :-( > > I compared the object files generated by mingw and djgpp. They are entirely > different. Mingw generates calls to alloca() in tui.o and djgpp doesn't. So > the problem is not only the linker, it's the compiler too. Just try to build > FreeLoader using mingw and you'll see. Thats probably because (IIRC) alloca is used by a header macro somewhere. > Btw, I guess the M$ developers still have to use VC 1.52 (16 bit) to build > the WinXP boot code. ;) > > - Eric Kohl All I know is that on Linux, 16 bit code for bootloaders is generated and linked by the gcc-gas-ld toolchain. I can look into their makefiles for you guys ... if you'd like. Rob ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Robert C. <rob...@it...> - 2001-10-15 14:07:24
|
----- Original Message ----- From: "Robert Collins" <rob...@it...> To: <ros...@re...> Sent: Monday, October 15, 2001 9:30 PM Subject: [ros-kernel] Re: Gcc and binutils release > All I know is that on Linux, 16 bit code for bootloaders is generated > and linked by the gcc-gas-ld toolchain. I can look into their makefiles > for you guys ... if you'd like. > Side question: Can someone remind me why making ReactOS multi-boot compliant so that Grub et al can boot it was a bad thing? - Grub should build under cygwin very happily. The makefiles would need a little tweaking for use under mingw without cygwin. --- and now onto the Main issue: generating boot code from gcc + binutils. Grub is built from gcc + binutils. http://savannah.gnu.org/cgi-bin/viewcvs/grub/grub/stage1/ contains the stage1 portion of Grub, which is the assembly code. They simply use -fno-builtin -nostdinc on the commandline to gcc to prevent accidentally pulling in a library header... So I can offer the following: It *is* possible with a standard x86 targeted gcc+recent binutils (all the ReactOS ones are ok) to generate 16 bit assembly suitable for bootstrapping a bootloader. I can see several options: 1) convert freeloader to use standard gcc+binutils as Grub does. 2) make ReactOS multiboot compliant so that it can be used with Grub or other multiboot bootloaders. then phase out freeloader, or make it a multiboot compliant bootloader. 3) Start from scratch under gcc+binutils. I suspect that 1) is actually quite easy and is the way to go... However you'll need to get gcc to support Intel asm memnomics or change to AT&T as it only supports AT&T by default. I'm sure there are patchs out there to give gcc Intel support, this came up somewhere else recently I think... maybe even here:}. Rob ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Brian P. <br...@sg...> - 2001-10-15 15:50:32
|
Right now FreeLoader is fully gcc+binutils compliant and will build under most x86 gcc dists. It uses AT&T assembly. The real problem with MingW is that it cannot assemble 16-bit code. Every time I use the .code16 directive it complains that it cannot represent reloc type BFD_RELOC_16. For some reason they have the 16-bit code support compiled out of MingW. AFAIK this is the only pending issue that is keeping FreeLoader from compiling. About ReactOS being multiboot compliant -- I don't see how we can accomplish this without an intermediate boot loader. ReactOS will need to have hardware & registry information passed in from the boot loader, and the list of modules to load is specified in the registry. All this doesn't fit very well into the multiboot spec. Brian -----Original Message----- From: Robert Collins [mailto:rob...@it...] Sent: Monday, October 15, 2001 7:36 AM To: ros...@re... Subject: [ros-kernel] Re: Gcc and binutils release ----- Original Message ----- From: "Robert Collins" <rob...@it...> To: <ros...@re...> Sent: Monday, October 15, 2001 9:30 PM Subject: [ros-kernel] Re: Gcc and binutils release > All I know is that on Linux, 16 bit code for bootloaders is generated > and linked by the gcc-gas-ld toolchain. I can look into their makefiles > for you guys ... if you'd like. > Side question: Can someone remind me why making ReactOS multi-boot compliant so that Grub et al can boot it was a bad thing? - Grub should build under cygwin very happily. The makefiles would need a little tweaking for use under mingw without cygwin. --- and now onto the Main issue: generating boot code from gcc + binutils. Grub is built from gcc + binutils. http://savannah.gnu.org/cgi-bin/viewcvs/grub/grub/stage1/ contains the stage1 portion of Grub, which is the assembly code. They simply use -fno-builtin -nostdinc on the commandline to gcc to prevent accidentally pulling in a library header... So I can offer the following: It *is* possible with a standard x86 targeted gcc+recent binutils (all the ReactOS ones are ok) to generate 16 bit assembly suitable for bootstrapping a bootloader. I can see several options: 1) convert freeloader to use standard gcc+binutils as Grub does. 2) make ReactOS multiboot compliant so that it can be used with Grub or other multiboot bootloaders. then phase out freeloader, or make it a multiboot compliant bootloader. 3) Start from scratch under gcc+binutils. I suspect that 1) is actually quite easy and is the way to go... However you'll need to get gcc to support Intel asm memnomics or change to AT&T as it only supports AT&T by default. I'm sure there are patchs out there to give gcc Intel support, this came up somewhere else recently I think... maybe even here:}. Rob ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Eric K. <ek...@rz...> - 2001-10-15 20:15:56
|
Brian Palmer <br...@sg...> wrote: > Right now FreeLoader is fully gcc+binutils compliant and will build under > most x86 gcc dists. It uses AT&T assembly. The real problem with MingW is > that it cannot assemble 16-bit code. Every time I use the .code16 directive > it complains that it cannot represent reloc type BFD_RELOC_16. For some > reason they have the 16-bit code support compiled out of MingW. AFAIK this > is the only pending issue that is keeping FreeLoader from compiling. > I have just built freeldr.sys (not the bootsectors) using MinGW. I had to modify multiboot.c and tui.c to avoid calls to alloca(). The calls to alloca() are generated by MinGW but not by djgpp. After using objcopy (according to Robert Collins) I got a binary freeldr.sys. At least it is *not* a pe-file. - Eric Kohl ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Robert C. <rob...@it...> - 2001-10-15 23:29:05
|
----- Original Message ----- From: "Brian Palmer" <br...@sg...> > > About ReactOS being multiboot compliant -- I don't see how we can accomplish > this without an intermediate boot loader. ReactOS will need to have hardware > & registry information passed in from the boot loader, and the list of > modules to load is specified in the registry. All this doesn't fit very well > into the multiboot spec. Oh. Uhmm, lets see now, in most free os's hardware is detected by the kernel and config data is determined by the root partition. So for ReactOS (please correct me if I'm wrong) hardware is detected _pre_ kernel loading and config data is determined by the SYSTEMROOT. hardware: how will ReactOS deal with plugnplay and the like? I would have thought that the kernel (or a module) will need to be able to detect and categorise new hardware at runtime - think USB. Win2k certainly does this. This implies to me that the HKCC hive is maintained bythe kernel under NT, not the boot loader? 'course you folk are the gurus, and wrote ROS, so I'll just listen now :]. Anyway, I'd guess that from the Grub point of view arbitrary h/w detection is a kernel responsibility, so whatever Grub is told is the kernel is what needs to perform that detection. Chain loading here we come. SYSTEMROOT: well thats simply a root partition + path specifier. So the only thing I see is that the _initial_ h/w detection is done outside the kernel today. *shrug* it's not going to worry me much one way or another though :}. I only asked in case time migrating freeloader could be saved... Rob ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Phillip S. <ps...@cf...> - 2001-10-16 00:37:33
|
The hardware that is detected by ntdetect.com is legacy devices like floppy drives and serial ports. Floppy drives do not support auto detection, which is why you have to tell your bios about them, and ntdetect queries the bios for this information and stores it in KHLM\HARDWARE. All other PnP hardware is enumerated by the WDM bus drivers in win2k. At some point we're going to start implementing WDM drivers. At 09:17 AM 10/16/2001 +1000, you wrote: >Oh. Uhmm, lets see now, in most free os's hardware is detected by the >kernel and config data is determined by the root partition. > >So for ReactOS (please correct me if I'm wrong) >hardware is detected _pre_ kernel loading and config data is determined >by the SYSTEMROOT. > >hardware: how will ReactOS deal with plugnplay and the like? I would >have thought that the kernel (or a module) will need to be able to >detect and categorise new hardware at runtime - think USB. Win2k >certainly does this. This implies to me that the HKCC hive is maintained >bythe kernel under NT, not the boot loader? 'course you folk are the >gurus, and wrote ROS, so I'll just listen now :]. Anyway, I'd guess that >from the Grub point of view arbitrary h/w detection is a kernel >responsibility, so whatever Grub is told is the kernel is what needs to >perform that detection. Chain loading here we come. > >SYSTEMROOT: well thats simply a root partition + path specifier. > >So the only thing I see is that the _initial_ h/w detection is done >outside the kernel today. > >*shrug* it's not going to worry me much one way or another though :}. I >only asked in case time migrating freeloader could be saved... > >Rob ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Jakov af W. <ja...@vm...> - 2001-10-15 14:52:24
|
On Mon, Oct 15, 2001 at 09:30:13PM +1000, Robert Collins wrote: > > > All I know is that on Linux, 16 bit code for bootloaders is generated > and linked by the gcc-gas-ld toolchain. I can look into their makefiles > for you guys ... if you'd like. > AFAIK the bin86 package is used for that: as86 and ld86. regards, Jakob ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Robert C. <rob...@it...> - 2001-10-15 23:44:41
|
----- Original Message ----- From: "Jakov af Wallby" <ja...@vm...> To: <ros...@re...> Sent: Tuesday, October 16, 2001 12:15 AM Subject: [ros-kernel] Re: Gcc and binutils release > On Mon, Oct 15, 2001 at 09:30:13PM +1000, Robert Collins wrote: > > > > > > All I know is that on Linux, 16 bit code for bootloaders is generated > > and linked by the gcc-gas-ld toolchain. I can look into their makefiles > > for you guys ... if you'd like. > > > > AFAIK the bin86 package is used for that: as86 and ld86. > The bin86 package is only needed for linux compilation, not for lilo or grub. Rob ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Michael Z. <mi...@za...> - 2001-10-15 16:01:43
|
> > >>Btw, I guess the M$ developers still have to use VC 1.52 (16 bit) to >> >build > >>the WinXP boot code. ;) >> I wouldn't be surprised if they would use an modified version of for example gcc and etc. They even distribute gcc for an posix extending layer on NT, Interix (i guess it is called like that). Greetz, Michael. |
|
From: Robert C. <rob...@it...> - 2001-10-15 17:40:34
|
Further to my last email...
I can see there is multiboot stuff in freeloader already. Doh!
Also, the current make file will fail because mingw gcc is built with
only PE emulation by default, which may be causing problems as you are
trying to link to a 'binary' target - which PE is not supported for.
Now, using grub as further inspiration...
===
# General rule for making a raw binary.
%: %.exec
$(OBJCOPY) -O binary $< $@
===
so for something like freeldr.sys which I'm assuming is actually a raw
binary, all you need is
freeldr.sys: freeldr.exec
../bootsect/stubit ../bootsect/fatstub.bin freeldr.exec freeldr.sys
freeldr.exec: asmcode.a c_code.a \
./bootsect/stubit ../bootsect/fatstub.bin
And that could possibly be simpler if the stub is included in the main
source dir.
Rob
====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html =
====================================================
|
|
From: KJK::Hyperion <no...@li...> - 2001-10-16 16:44:22
|
At 12.27 15/10/2001 +0200, you wrote: >Btw, I guess the M$ developers still have to use VC 1.52 (16 bit) to build >the WinXP boot code. ;) Yes, but they're pushing Intel to drop 16 bit support eventually. Have you seen Windows 2000? it doesn't identify partitions by ordinal, but by GUID: it's a preview of what we'll see with the Itanium architecture, and with Microsoft's Windows XP 64bit (on the current architecture, however, it's just a royal pain in the a**: even resizing a partition makes Win2k beleive it's been deleted, thus changing its GUID and reassigning its mount points). All the partitioning scheme will be cleaned up from ugly inheritances as the Extended partition and 16-bit code in boot-loaders Anyway, I'm pretty sure they continued to update their 16 bit compilers, internally. For example, I recall reading in Matt Pietrek's Windows 95 System Programming about Win95's kernel having been compiled with something like a compiler generating 16bit executables with 32bit addressing... ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
