POLINK: "Section .text is missing access flag; assuming

[japheth]

Hello,

when linking a COFF object (not Win32) with POLINK it complains:

Code Select Expand


POLINK: warning: Section '.text' is missing access flag; assuming READ/WRITE.
POLINK: warning: Section '.data' is missing access flag; assuming READ/WRITE.
POLINK: warning: Section '.bss' is missing access flag; assuming READ/WRITE.


the warning looks harmless, but the map shows a problem:

Code Select Expand


hello.exe

Preferred load address is 00400000

Start         Length     Name                   Class
0001:00000000 00000950H .data                   DATA
0001:00000950 00002ef4H .bss                    DATA
0002:00000000 000073f0H .text                   CODE
0003:00000000 000007bcH .reloc                  DATA


POLINK has located the .data and .bss sections *before* .text, which is bad. Could this be changed? The MS linker does it correct:

Code Select Expand


hello

Preferred load address is 00400000

Start         Length     Name                   Class
0001:00000000 000073f0H .text                   CODE
0002:00000000 00000950H .data                   DATA
0002:00000950 00002f18H .bss                    DATA


The test case is:

http://www.japheth.de/Download/polink.zip

(please do NOT try to run the resulting .EXE!, it is not intended to run in the Win32 subsystem).

Regards

Japheth

[Pelle]

When linking non-Win32 COFF files, a completely different approach to relocations must be used. The section order is probably the least problem. Linking non-Win32 COFF files isn't exactly my highest priority...

Maybe, but also maybe not...

[japheth]

> When linking non-Win32 COFF files, a completely different approach to
> relocations must be used. The section order is probably the least problem.

I'm aware of the slightly incompatibe handling of relocations of Win32 linkers and "others" and have a small tool available to "fix" this issue. The section order indeed is the only problem remaining.

> Linking non-Win32 COFF files isn't exactly my highest priority...

Yes, understandable. But it might be easy to fix .