flat assembler
Message board for the users of flat assembler.

Index > Compiler Internals > error: format limitations exceeded.

Author
Thread Post new topic Reply to topic
Randall Hyde



Joined: 03 Dec 2003
Posts: 57
Randall Hyde
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


Description:
Download
Filename: fasmbm2.zip
Filesize: 95.65 KB
Downloaded: 503 Time(s)

Post 23 Feb 2004, 22:57
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7781
Location: Kraków, Poland
Tomasz Grysztar
There are too many relocations - COFF format allows only 65535 relocations per section.
Post 24 Feb 2004, 07:16
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
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.
Post 24 Feb 2004, 16:03
View user's profile Send private message Visit poster's website Reply with quote
Randall Hyde



Joined: 03 Dec 2003
Posts: 57
Randall Hyde
Privalov wrote:
There are too many relocations - COFF format allows only 65535 relocations per section.


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
Post 24 Feb 2004, 18:14
View user's profile Send private message Visit poster's website Reply with quote
Randall Hyde



Joined: 03 Dec 2003
Posts: 57
Randall Hyde
Randall Hyde wrote:
[
Hmmm...
Okay. I wonder what MASM and TASM are doing with this same code? Well, TASM is OMF,


Nevermind. I was also generating OMF with MASM, which seems to work fine. Generating COFF is another issue.
Cheers,
Randy Hyde
Post 24 Feb 2004, 18:36
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
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 Smile

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.
Post 24 Feb 2004, 20:11
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7781
Location: Kraków, Poland
Tomasz Grysztar
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).
Post 29 Feb 2004, 14:20
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
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:
Code:
00000400   4C 01 02 00  D6 54 3F 40  65 00 00 00  03 00 00 00   L:; ÍT?@e   e
00000410   00 00 84 01  2E 64 61 74  61 00 00 00  00 00 00 00     ä:.data
    


Description:
Download
Filename: uninitialized.zip
Filesize: 751 Bytes
Downloaded: 490 Time(s)

Post 29 Feb 2004, 14:32
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7781
Location: Kraków, Poland
Tomasz Grysztar
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.
Post 29 Feb 2004, 14:50
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
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 Smile
Post 29 Feb 2004, 14:56
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7781
Location: Kraków, Poland
Tomasz Grysztar
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
Post 29 Feb 2004, 15:10
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
Sorry, privalov! - didn't look closely enough at the .obj. Embarassed

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 Smile
Post 29 Feb 2004, 15:20
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7781
Location: Kraków, Poland
Tomasz Grysztar
This is you who have put the "data" flag there. Wink
Post 29 Feb 2004, 15:25
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
Well, it's Randall, but... Wink

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 Smile
Post 29 Feb 2004, 15:31
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7781
Location: Kraków, Poland
Tomasz Grysztar
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.
Post 29 Feb 2004, 15:43
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
Automatically adding the uninitialized flag takes away some of my freedom Wink - 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 Very Happy
Post 29 Feb 2004, 15:50
View user's profile Send private message Visit poster's website Reply with quote
Randall Hyde



Joined: 03 Dec 2003
Posts: 57
Randall Hyde
Privalov wrote:
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.


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

Cheers,
Randy Hyde
Post 01 Mar 2004, 23:59
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.