OSDev.org

Why don't cygwin produce flat binary code... he did the exception and terminates..

Hi,

There was the same message 2 weeks ago.

I also had the same problem, and I could not correct it, so I turned to DJGPP.

One guest of this forum suggested that it was a bug in Cygwin.

Look at a message called "Link the Kernel"

Roswell

It's a Cygwin ld bug.

You have several options:
1) Switch to DJGPP
2) Have your OS use one of the other Cygwin formats (e.g. PE)
3) Write a program that converts PE files to flat binary (if the PE file is linked with memory alignment and section alignment both set to 4096 bytes, all you need to do is strip the headers)

I suggest that you switch to DJGPP.

Is this really a Cygwin "bug" or is it just a feature that's missing?

K.J.

I found that cygwin compiles much faster.. is there another solution? may be use djgpp's linker and gcc cygwin's compiler? Do they recognize their formats?

GCC only produces assembler output, which is then taken by AS, assembled, and linked with other files by LD. AS and LD belong to binutils, so this is not an issue of GCC being incompatible with anything. The problem is, that DJGPP only comes with LD enabled for coff, aout and other formats. But not PE. Because of this, you'll have to install DJGPP, get binutils sources and rebuild them using DJGPP. Then, hopefully, you'll be able to use cygwin's port of GCC with DJGPP's port of binutils.

not so bad, kernel

cygwin can produce flat binary files. After linking, use the following:

objcopy -S -O binary yourexe yourexe.bin

-S says to strip all symbols
-O binary says to produce a binary file

I spent days arguing with cygwin and had just installed djgpp when I found a web page that linked to a web page that linked to a file that had that information in it. I removed djgpp and have had no problems with cygwin at all.

should i link it something special, or usual?

Just link as usual (which I think defaults to pei-i386 format). In fact, the only way I've been able to get anything other than PE format is with objcopy. I always get errors with ld when specifying alternate output formats.

One note: I've had problems when linking nasm output with gcc output. For some reason the linker would get relative offsets wrong in calls from nasm to gcc functions. I was able to resolve this by telling nasm to output elf format. The linker is able to handle mixed elf and coff objects. I don't know why this worked, but I just spent 6 hours yesterday fighting with it.

I know there's supposed to be a cygwin bug related to the .bss size and linking with nasm, but I don't think this was related to that. I wasn't accessing any .bss addresses at all.

An alternative is to use gas. It's not so bad if you specify .intel_syntax so you don't have to use the bassackward AT&T syntax.