Help!

I'm getting the error "error: format limitations exceeded." on the attached source file. This seems be related to the file's size. If I eliminate the ADD instructions appearing in this test file, it compiles without any problems (there are only two instructions appearing in the file: a set of ADC instructions and a set of ADC instructions). BTW, I'm encountering this problem with FASM v1.51.
Cheers,
Randy Hyde

There are too many relocations - COFF format allows only 65535 relocations per section.

Could this perhaps be solved by splitting into stuff like .data$0 , .data$1 (and so forth), which at least some linkers (microsoft) will merge at link-time? Iirc the PE relocation format isn't limited like this. Not saying that fasm should do this splitting btw, just a suggestion for randall.

Hmmm...
Okay. I wonder what MASM and TASM are doing with this same code? Well, TASM is OMF, so that's probably a different issue. I wonder if MASM is doing something differently or if it's just generating a bad PE file (it handles an assembly with about 600,000 of these statements in it). As the file really only references three different variables (just several hundred thousand times each), I wonder if MASM is combining the relocation records?

Oh well, I'll see what else I can come up with.
Cheers,
Randy Hyde

Nevermind. I was also generating OMF with MASM, which seems to work fine. Generating COFF is another issue.
Cheers,
Randy Hyde

Hm, masm seems to produce only 576 relocations in the coff version (dumpbin /relocations). I don't really have any OMF tools around, so I don't know the amount in the OMF version. I guess masm just overflows and wraps around.

The OMF .obj messes up IDA majorly btw - took forever to disassemble, and the xrefs seemed to be pretty broken (do they use 16bit quantities?). The COFF version took much shorter time to disassemble, and shows that indeed output code would be broken - the last references in the disassembly points to the entry-point symbol, not dVar.

Just for fun, I tried putting in a couple of sections (ie, '.text$0', '.text$1'), and fasm then assembled without problems. With section align of 1, it seems that everything it stitched perfectly together by the linker into one .text section. So I guess for generated output, you could have your generator spit out a new .text$?? section after around 64k of instructions. I'm not sure how the linker reacts if there's sections with non-1byte-align though - whether it forces all alignment to the highest, or it just links the various sections with their specified align.

And well, it's probably irrelevant as long as your linker of choice supports both COFF and OMF, I guess

Btw, Privalov, Randall's code has 'reserve' statements in the .data section - while this is probably not a good practice in initialized sections, I think fasm ought to zero out the memory anyway? Otherwise you get random stuff in the output file.

I have just realized, that in this aspect MS COFF format differs a bit from the original COFF, and it allows to store the extended relocation count in some other way in case of overflow in the original 16-bit field - it is needed to set the special section flag in that case and store the actual 32-bit count in the additional relocation field at the beginning of relocation table. So now I have to add that ability to the fasm's MS COFF formatter.

f0dder: fasm fills all the reserved space with zeros anyway (the only exception are the alignment spaces, which are filled with NOPs).

Privalov, the relocation stuff sounds good. However, are you sure fasm zeroes the reserved space? See attached zip file. It was assembled with fasm 1.51 win32 console, and the first 32 bytes of the data section seems to indicate otherwise:

You have put only the reserved data into that section, so fasm made it and BSS section automatically, and the data of this section does not appear in the file at all. Put some initialized bytes after the data reservation directives and you'll see data of section in the output file.

Look at the .obj and .exe - the section *does* go physically into both. I probably wouldn't ever do code like this myself, so it's not that much of an issue, I just noticed it when assembling Randall's example. I still think it's a bug though

No, the contents of your .data section does not appear in the .obj file - I don't know about the exe, I was not checking it, as it is a matter of linker, not fasm. The test.obj you have posted contains:

• COFF header at offset 0, 14h bytes
  
• section table at offset 14h - 2 entries, 50h bytes
  
• data of code section at offset 64h - one byte (ret instruction code)
  
• symbols table at offset 65h - 3 entries, 36h bytes
  
• strings table at offset 9Bh - no entries, 4 bytes containing the size of table

Sorry, privalov! - didn't look closely enough at the .obj.

The error seems to be that fasm puts both ubinitialized and uninitialized flags for the .data section. I use MS link 7.10.3077, and it's obviously confused by the presence of both flags

This is you who have put the "data" flag there.

Well, it's Randall, but...

Wouldn't it be a good idea for fasm to either remove the 'initialized data' when adding the 'uninitialized data' flag, or not add the 'uninitialized data' flag automatically? Having both is a bit weird

So why they are flags instead of just a code indicating the type of section? fasm gives you freedom of marking sections with any combination of flags you wish, but it cares about BSS flag automatically, as it has some special meaning - it means that there is no data of this section in file. Theoretically you could mark it as a code also, if you wanted to have some uninitialized code section - why not? You've got freedom, but you should also take the responsibility for the result you achieve when you use this freedom.

Automatically adding the uninitialized flag takes away some of my freedom - nah, just teasing you, Privalov. I can't think of a situation where this is a problem, you shouldn't be adding the 'data' flag if you don't have data in the section. Keep up the good work on fasm, I really like it

My personal feeling is that if someone uses RB (or whatever) and *expects* the bytes to be zeroed, they deserve what they get . That is, after all, what DB is for.

Cheers,
Randy Hyde