Maximum size of unit: Internal Error 200205172

[marcov]

There are quite a lot of coff related changes between 3.2 and 3.3.1. Providing Testing results with 3.3.1 might speed up the bugreport.

Note that this is possibly a format limitation, not necessarily a FPC limitation (e.g. on *nix with a different object format it might be different)

[Bart]

Note that this is possibly a format limitation, not necessarily a FPC limitation (e.g. on *nix with a different object format it might be different)

TS said that Delphi was able to compile/build, so it is a limitation of (the implementation in) FPC.

Bart

[marcov]

Note that this is possibly a format limitation, not necessarily a FPC limitation (e.g. on *nix with a different object format it might be different)

TS said that Delphi was able to compile/build, so it is a limitation of (the implementation in) FPC.

But of the (PE)COFF implementation, not the general implementation. Though we don't link ELF, so that is maybe a stretch :-)

[Grahame Grieve]

So I'd like to try with the most recent FPC but I couldn't get the current version to compile?

Bug: https://bugs.freepascal.org/view.php?id=37745

[mr-highball]

So I'd like to try with the most recent FPC but I couldn't get the current version to compile?

Bug: https://bugs.freepascal.org/view.php?id=37745

Not sure if you are already using this, but fpcupdeluxe should simplify multi instances of fpc/lazarus as well as making it very easy to ensure you have latest trunk (and keep it up to date)

https://github.com/LongDirtyAnimAlf/fpcupdeluxe/releases

[Grahame Grieve]

Ah thanks. I has some vague memory that it existed, but I couldn't remember what it was actually called, and my google skills were inadequate for the task for finding it without knowing the name. I will give it a go.

in the mean time, I split my big units up into smaller units so I could move ahead, and I at least get a clean compile (3 million lines) - it's my Coronavirus lock-down project; now I just have to fix all the things I hacked to get it going.

[Grahame Grieve]

... not fixed in 3.3.1

[Martin_fr]

I have a program that compiles ok, but I get an error during linking:

Have you tried using an external linker?
-Xe

[Mr.Madguy]

Not sure about this case, but for me "Out of memory" is very common error for big modules in Delphi. In most cases it's caused by debug information for generics. Generics have long names. Especially when they're nested. I.e. something like "TGeneric1<TSomeType, TGeneric2<TSomeOtherType>>". This is one of the reasons, why I want to migrate to FPC.

UPD May be I have old sources. It's 3.0.0 sources. Don't have time to download new ones. And according to this sources, this internal error can happen in one of two places:
1) When reading long PE section name (that is longer, than 8 symbols). Dunno, if FPC uses long section names. I guess, it shouldn't.
2) When reading symbol table, mostly used as debug info.
This error happens, if:
1) Pointer to symbol table is nil.
2) Position to read exceeds size of symbol table.
3) #0 is found at that position, i.e. zero length string.

So, I guess, it's broken symbol table.

[Thaddy]

I suspect resource starvation as well, but that does not hide that such huge units are bad software design in most - if not all - cases.
Anyway: internal errors are there for a reason, so this will likely be fixed.

[Mr.Madguy]

There is change in 3.2.0 vs 3.0.0. Some big obj files are now supported. They have some different header structure. And may be bugged.

[PascalDragon]

So, I guess, it's broken symbol table.

It was not the symbol table, but the string table: if a section name is larger than 8 it's replaced by an offset into the string table which is located at the end of the object. If that offset (in decimal) has less than 8 digits all is well (it's prefixed by a '/'), but larger offsets were the problem: it's sadly not documented that these need to be encoded as Base64-6-character strings (prefixed by '//'). I had to dig through LLVM to learn about that... (note: this is independant of Big Obj COFF or not, though of course the former are more likely to be affected )

Anyway, it should be fixed now in 46876 and I'll request to merge it to 3.2.1 as well.

[Grahame Grieve]

Great thanks

[Mr.Madguy]

It was not the symbol table, but the string table: if a section name is larger than 8 it's replaced by an offset into the string table which is located at the end of the object. If that offset (in decimal) has less than 8 digits all is well (it's prefixed by a '/'), but larger offsets were the problem: it's sadly not documented that these need to be encoded as Base64-6-character strings (prefixed by '//'). I had to dig through LLVM to learn about that... (note: this is independant of Big Obj COFF or not, though of course the former are more likely to be affected )

Anyway, it should be fixed now in 46876 and I'll request to merge it to 3.2.1 as well.

So, at the end it's case #1. And PE File format doesn't mention anything about // prefix and Base64 section names. So, it must be something new.

[PascalDragon]

So, at the end it's case #1. And PE File format doesn't mention anything about // prefix and Base64 section names. So, it must be something new.

Yes, that's where I had looked at first as well.

If I had to guess this mechanism was probably introduced at a similar time as Big Obj COFF (which isn't mentioned there either) cause having larger offsets is much more likely there.