LD Command Line Options

[Kenny]

Hello

I am trying to use LD on a Win32 platform to combine multiple COFF object files into a single COFF object file, but I'm having trouble finding the command line options (or a different tool) to do this.

By default, LD will combine the object files, merge the sections and resolve the internal symbols, but it adds extra code and produces a PE exe, which is very unhelpful. I have also tried the -i (produce relocatable code) option to LD which produces a COFF object file as output, but it does not merge the sections of the different input files, instead giving me one set of sections (.text, .data, etc.) for each input file.

I have tried the LD with DJGPP and MinGW and found the same result for each.

It doesn't seem feasible to attempt to remove the PE header because it has added a large quantity of bootstrapping code into the exe. Gcc itself won't produce a combined object from multiple C files. I could combine the code into a single code file but that strikes me as very much the wrong thing to do. I could modify the loader to accept and locate multiple .text, .data etc. sections but I would rather not have to do that just yet.

This is really frustrating me as the inability to produce loadable library modules for my OS is hampering development, and I know that what I'm trying to do is very straightforward. I just need to find the right options to get LD to do the linking, but not add the win32 rubbish to it.

Any help greatly appreciated.

[Selenic]

Well, obviously a Windows-targeted compiler is going to produce Windows executables. You need a 'none'-targeted GCC Cross Compiler, which produces raw executables/libraries, for which you'll have to construct your own glue. (strangely, this very common recommendation doesn't, from a quick look, seem to be in the obvious places to look when starting out. It really should be)

[Combuster]

(strangely, this very common recommendation doesn't, from a quick look, seem to be in the obvious places to look when starting out. It really should be)

Getting Started, under the "windows" header.

[Selenic]

(strangely, this very common recommendation doesn't, from a quick look, seem to be in the obvious places to look when starting out. It really should be)

Getting Started, under the "windows" header.

Ah yes, so it is, thanks (that's why I included the 'quick look' disclaimer - I expected that it would be there somewhere)

[montrom]

Off-Topic: Make the beginner's information (links/excerpts) an auto-PM when new people sign up and also make it apart of the activation process via email.

On-Topic: Post your linker script. Post your make file.

[Kenny]

The compilation is being driven by a batch file.

Code: Select all

del obj\all\*.o

nasm asm/kernelasmnet.asm	-o bin\kernelasmnet.bin 	-f bin
nasm asm/isr.asm	-o obj\all\isr.o	-f coff
nasm asm\FontBitmap.asm		-o obj\all\FontBitmap.o	-f coff

gcc -c src\start.c	-o obj\start.o		-ffreestanding -Wall
gcc -c src\main.c	-o obj\all\main.o	-Wall
gcc -c src\ports.c	-o obj\all\ports.o	-Wall
gcc -c src\ints.c	-o obj\all\ints.o	-Wall
gcc -c src\video.c	-o obj\all\video.o	-Wall
gcc -c src\string.c	-o obj\all\string.o	-Wall
gcc -c src\stdlib.c	-o obj\all\stdlib.o	-Wall
gcc -c src\keyboard.c	-o obj\all\keyboard.o	-Wall
gcc -c src\commands.c	-o obj\all\commands.o	-Wall
gcc -c src\mm.c		-o obj\all\mm.o		-Wall
gcc -c src\timer.c	-o obj\all\timer.o	-Wall
gcc -c src\gdt.c	-o obj\all\gdt.o	-Wall

gcc -c src\list.c	-o obj\all\list.o	-Wall
gcc -c src\stream.c	-o obj\all\stream.o	-Wall

gcc -c src\dvrata.c	-o obj\all\dvrata.o	-Wall
gcc -c src\dvrram.c	-o obj\all\dvrram.o	-Wall
gcc -c src\fat.c	-o obj\all\fat.o	-Wall
gcc -c src\dos.c	-o obj\all\dos.o	-Wall
gcc -c src\pci.c	-o obj\all\pci.o	-Wall
gcc -c src\pcinames.c	-o obj\all\pcinames.o	-Wall

gcc -c src\libs.c	-o obj\all\libs.o	-Wall

gcc -c src\process.c	-o obj\all\process.o	-Wall -save-temps

ld -o obj\kernelc.o	obj\start.o obj\all\*.o	-i -e _main -Ttext 0x7E00
ld -o obj\kernelc.o	obj\start.o obj\all\*.o	   -e _main -Ttext 0x7E00

REM --print-map

objcopy -R .note -R .comment -S -O binary obj\kernelc.o bin\kernelc.bin

CorrectSize bin\kernelc.bin 65536 00

copy /B bin\kernelasmnet.bin  + /B bin\kernelc.bin + /B test.library.img /B kernel.bin

pause

This builds a monolithic binary file for offset 0x7C00 which is then PXE booted onto the testbed. The library loader in the kernel works perfectly for the object files being output by GCC directly, and during development I had assumed (apparently incorrectly) that LD would be able to just pop out a neatly linked object file for me to load. Imagine my surprise.

[Kenny]

I have set up Cygwin, gotten the sources to GCC and followed the other steps in the GCC Cross Compiler article. Other than the compilation taking a long time, it all went well.

The target I chose was i586-coff, which has given me the ld target option of coff-i386.

However ... using the coff-i386 target option is giving me exactly the same output as the incremental (-i) linking using the DJGPP linker, a COFF file with one set of sections for each input file, instead of what I would like which is for it to link the input files and provide a single set of sections in the output file.

I appreciate the help, and I think that creating the cross-compiler is definately a step I needed to take in the development, but it hasn't advanced the plot in my current dilemma.

Am I asking the wrong question? Do I need to ask how to get ld to merge the sections?

Thoughts?

(Apologies, it's been a long night ... )

[montrom]

Hi, sorry I didn't get back to you sooner. No, I think you are asking the right questions. I pretty much understood that you wanted a single flat binary file the entire time. What I don't understand is why you would need a cross-compiler for that as I do so just fine using the same tools you were using originally. I'm wondering a few things about your batch file. Doesn't those relative addresses fail? Why isn't there a pause at the end so that you could see your progress? Are you sure that the object files are being created? Put down the cross-compiler for just a moment and build yourself a linker script, debug it as necessary and I know that if you do it right, it will work, because I do it everyday. Good luck.

EDIT: Doh, there is a pause. Good job!

[gerryg400]

I notice you run ld twice. One with -i, once without. Why ?

NOTE: the -i option does not give a loadable output, unless your loader completes the link. -i gives a relocatable binary. It must be relocated.

[Kenny]

You ask a good question, I'm just trying to remember ... I believe it was something to do with error reporting. If I have an undefined symbol error somewhere in the build, one of these two reports it, the other doesn't. I never did sit down to figure out why. It may well be that one of these calls is redundant.

Thinking about it ... I apologise. I've posted the wrong build script. This is the one for the flat binary kernel, not the COFF library.

The other is, for the most part, identical except for the linking stage, where I'm looking for a COFF output.

Sorry if I've wasted your time on the first one

Code: Select all

del obj\*.o

gcc -c ..\modulebase.c -o obj\modulebase.o	-ffreestanding -Wall
gcc -c main.c	-o 	obj\main.o			-ffreestanding -Wall

ld -o helloworld.o	obj\modulebase.o obj\main.o

pause

ModuleBase.c is a stub that is (will be) linked with each library and executable that provides any initialisation etc. for the module. main.c is your common-or-garden "Hello World" program.

[Combuster]

Other question: what do you actually need merged sections for?
is it:
a) To use as an executable? You don't need merged sections for that. Also, not all references have been linked properly.
b) To create a static library? You don't need merged sections for that. Actually its even bad to do that as you'll force the entire library to be linked in instead of the parts you actually need. Instead you should use the ar tool (Link archiver)
c) To create a DLL? Then make a PE DLL and not a COFF file.

So it must be:
d) for no sane reason? (hint hint)

[Kenny]

I think I can wrap this up now.

The reason for wanting merged sections is because my module loader was developed against GCC built object files, for which there is one set of sections. I had made the assumption that LD would be capable of outputting linked object files of this form, which is not an unreasonable assumption given that it knows how to merge sections and it knows how to output object files.

Upon finding out that it didn't immediately produce the output I wanted, I had come here to see if there was some command line option, link script option, rune. or incantation that woould make it do both these things that I have seen, but together. adding two characters to a build script seemed the easier option than rewriting a sizable chunk of code to accept the different format.

I shall go off and investigate both the ELF format (which I was meaning to do anyway, especially now that I have a cross-compiling toolchain) and extending the COFF loader to suport multiple sections.

Thanks all

[Combuster]

So you did attempt choice A.

Did you realize that COFF is an object file, and not an executable file? It is not designed to be executed as it is perfectly allowed to have missing references, unfilled relocations and everything else the linker is designed to do during the creation of an executable.

If you want to build a complete linker, go ahead. If you want to be plagued with random failures, go ahead. But don't complain.

[montrom]

Rune or Incantation. I know it may seem like it, but programming isn't magic. However, the LD manual is magical. A linker script that has been properly done is magical. However, leaving a well trotted path to discover weird (COFF loader) and exotic places (cross-compiler) isn't so magical.