Linker option /ALIGN

[frankie]

Hi Pelle,
There is a bug (I suppose) in the linker using the /ALIGN option. Setting a value of 512 the first section of the PE executable (usually .text) is always aligned on a page boundary (4096 bytes), the RVA of first section is always 0x1000, the following sections are aligned on the correct boundary (i.e. .data @ 0x1200, .rdata @ 0x1400, etc).
This option enable the use of your compiler to produce an executable with file/memory sections alignment wich allows direct loading as kernel modules loaded from bootstrap code.
Using the Microsoft linker I obtain the correct alignment, but with a limitation in the maximum base address (MSLINK : fatal error LNK1249: image exceeds maximum extent with base address FFFFFF0000000 and size 0x1000) that your linker doesn't have.
Please could you correct this and, if you think this could be of any use, add another switch to choose file alignment (i.e. file sections layout aligned on a boundary other than 512). The last could be used for the reverse adjustment so file layout is the same as memory layout on page boundary.

Thank for your support and your compiling system
Regards
F.

[Pelle]

Hello Frankie,

I will look at it. Did some changes in this area for the /DRIVER option in 2.90 beta, but for other cases the code is the same as before.

Pelle

[Pelle]

The /ALIGN option in the attached linker should work now (needs more testing).

Adding a file alignment option is probably a good idea, but at this stage I prefer to only fix bugs in the linker. I can't find any useful information about LNK1249 or the conditions for when it's triggered. It's probably a very good error, but unless I understand why - I can't add it to my linker.

Pelle

[frankie]

Thanks Pelle,
I'll made some checks as soon as I have time.
About the MSLINK error LNK1249 it's a simple check made by linker to avoid loading executable above 2Gb user memory (the upper 2Gb in WINNT are reserved for OS, in fact specifing /DRIVER option you are allowed with higher addresses).
But to make your system open also for open development (actually is largely used DJGPP and Gcc) I suggest to simply send a warning specifing that window executabe could not run above 0x8000000 (why a windows programmer should choose this option?). The check should be done during loading phase of linking, and the warning should trigger as soon as the generated address exceed 0x7fffffff.

Regards
F.

[Pelle]

I'm aware of the 2GB limit, but have never been near it myself. This is why I have never seen this warning before. There are almost no hits in Google, so I assume I'm not the only one. Microsoft could have phrased the error better - I find it rather confusing, especially with the 'size' information (I understand why, but the first reaction to this message is: huh?!).

The /LARGEADDRESSAWARE option also seems to affect the warning.

Pelle

[frankie]

The /LARGEADDRESSAWARE switch just moves the code maximum address to 3Gb (max memory address 0xbfff0000), above wich the error is triggered again.

Regards
F.

[Pelle]

I guess my point is that in the end, several condition needed to be checked before doing the actual address check - to emit a warning that few, if any, people will ever see.

Well, it doesn't matter. I have added the warning now.

Pelle

[frankie]

Hello Pelle,
Just for your info I checked the new linker version and I was able to compile (with pocc and nasm) and link (polink) a bootable kernel-like chunk of sw.
I had a problem with an unused symbol declared as external from an assembler module (assembled with nasm), the linker issued an undefined symbol error. The symbol was declared in a different 'C' module that was present in the linker stream. Removing the external definitionin the asm module, and the whole 'C' module, the compiler hasn't complained any more.
I don't know if this is a known issue, anyway I'll check it again if I'll have some time for (I'm really full of work in this time).
Regards
F.

[Pelle]

Hello,

Thanks for the info!

Hard to say anything about the symbol problem without more info.

Pelle

[frankie]

Pelle,
just a symbol's decoration problem. Last time I had no time to check.
Everithing is fine now.
Regards
F.

[Pelle]

Very good. Thanks for the info.

Pelle