Re: [AD] Allegro assembly code + OMF

[Shawn Hargreaves <shawn@xxxxxxxxxx>]

Greg Hackmann <hacker@xxxxxxxxxx> writes:
> Right now I'm trying to work on static library support for Borland
> C++Builder, but I've hit a major snag.  Seems that Borland's linker only
> supports OMF format .OBJ files, and gcc only generates COFF format .OBJ
> files.

Yuck. I don't have anything concrete to suggest here, other than to try 
looking for MSVC to Borland conversion systems. Microsoft used OMF in 
their 16 bit compilers, but switched to COFF for win32, so all their 
recent libs are in COFF format (that's how the MSVC Allegro is able to so 
easily use sources that were assembled by djgpp). Unfortunately Microsoft 
and DJ have a difference of opinion about the precise meaning of some of 
the COFF header flags, so their objects aren't entirely compatible, but 
this isn't a problem for the limited number of things Allegro needs to do 
in the asm files (it just imposes a few restrictions like we can't 
declare globals in asm files, and can't call C functions from asm sources 
except via a function pointer).

But to cut a long story short, the Allegro asm files as built using djgpp 
work directly with MSVC. Since Microsoft have been releasing libs in that 
format for years, there is a good chance someone else may have hit this 
problem before, so I'd look for any references about getting 32 bit 
static Microsoft libs to work with Borland.

> Unfortunately, I couldn't find a free disassembler that works the way I 
> need it to (i.e. can disassemble COFF code into a format that NASM can 
> accept);

I tried several of those when first starting the porting work, but 
couldn't find any that worked properly.

Hmm, I smell a challenge coming on: anyone fancy knocking up a quick Perl 
script that would turn output from djgpp objdump into input for NASM or 
TASM or whatever? Perhaps not the most direct route to the goal, but it 
would mostly just be a search and replace operation, and using 
disassembler output as the input would simplify things a great deal (no 
need to deal with all the vagaries of human code layout, comments, and 
what have you, let alone the evil macros in the Allegro asm files).

> So far the only option I can see is for me to rewrite the entire
> assembly portion of Allegro in NASM so that I can get OMF .OBJ file
> generation.  While this would *technically* work (NASM can also generate
> COFF files, so it wouldn't mess up the other ports), I'm sure it's a bit
> much to ask the entire dev team to switch over to NASM just for the sake
> of one port, especially since I can still make a dynamically-linked
> library.

I'd much rather not do this, partly due to a personal preference for AT&T 
syntax, but also because it would lose the ability to build out of the 
box with standard djgpp, Linux, and BeOS tools (that is essential for 
source-format Unix distributions).

As you say, the easy option is to just go on using the dynamic lib 
produced by a different compiler. This seems like a cop-out in a way, but 
on the other hand, DLL modules are a core part of Windows, so you could 
argue that it is simply taking advantage of this OS feature to avoid 
needing to port to any more compilers than we absolutely have to :-)

Are there any specific benefits to having a native Borland version, other 
than just to be able to say that we did it? I do want to get a native gcc 
build on Windows, because I think it is important that people be able to 
contribute to Allegro using entirely free tools, but I don't see any such 
essential reason for a Borland build. It would certainly be nice, though: 
seems silly to be held up by some piddling detail like the object file 
format!



-- 
Shawn Hargreaves - shawn@xxxxxxxxxx - http://www.talula.demon.co.uk/
"A binary is barely software: it's more like hardware on a floppy disk."