HASM 2.32 Release

[johnsa]

That is very strange.. I can't see any real difference between what .data produces and the full directive :

_DATA SEGMENT ALIGN(32) FLAT 'DATA'

The only thing missing is the ALIAS.. I wonder if the reason is that from Delphi it's combining/merging data sections in a different order..

IE: using it's data section then taking on the asm module's .data, thus loosing the alignment, possibly because internally it probably just uses PARA ..

The base address of .data is definitely aligned, but the offset part isn't which is making me thing it's merging the sections together at link stage and somehow the offsets shift.. I wonder if the ALIAS is affecting that..

[aw27]

That is very strange.. I can't see any real difference between what .data produces and the full directive :

_DATA SEGMENT ALIGN(32) FLAT 'DATA'

The only thing missing is the ALIAS.. I wonder if the reason is that from Delphi it's combining/merging data sections in a different order..

IE: using it's data section then taking on the asm module's .data, thus loosing the alignment, possibly because internally it probably just uses PARA ..

The base address of .data is definitely aligned, but the offset part isn't which is making me thing it's merging the sections together at link stage and somehow the offsets shift.. I wonder if the ALIAS is affecting that..

This happens both with Delphi and Free Pascal Compiler.
If I don't use the ALIAS with Delphi or FPC,  the segment is not linked. In other words, there is no error but the segment simply is not there together with its data. I am not aware of any compiler switch or whatever to force the linkage.

[johnsa]

So if you just use .data then you wouldn't get the segment at all surely ?? _ perhaps the alias is required because you've named it _DATA1 and not _DATA.
The only thing I can think is using _DATA1 with the alias forces FPC/Delphi to link that segment in a different order that just "happens" to keep the align(32) where-as with the normal _DATA it gets merged in with it's own one and then doesn't respect align(32)

[aw27]

So if you just use .data then you wouldn't get the segment at all surely ?? _ perhaps the alias is required because you've named it _DATA1 and not _DATA.
The only thing I can think is using _DATA1 with the alias forces FPC/Delphi to link that segment in a different order that just "happens" to keep the align(32) where-as with the normal _DATA it gets merged in with it's own one and then doesn't respect align(32)

I can't keep the name _DATA, I will receive this error:  Error A2078: Segment definition changed: _DATA, alignment

[johnsa]

Ahh.. well i guess that is giving us the answer right there

_DATA is the "default", it's used by FPC/Delphi and probably has an alignment of para/16, so trying to merge one in with different attributes isn't possible.

It sounds like there is no fix for this apart  from your manual segment work-around! :(

[TWell]

@John
With that new option -Sp32, data sections in object files is quite identical.
PEView is good tool to examine that.
As in my tests, as in message #71, Free Pascal linker works correctly.
Anyone can download that bare compiler ppc386.exe and test it how it works without RTL.
Minimal support files are in that message.

We need proper examples for testing, to see when something goes wrong.

[nidud]

deleted

[johnsa]

Nidud, if I followed your post correctly it seems like two different link orderings, and the first one the asm module comes first, alignment is correct, the second when it merges in after the HLL data the alignment is no longer respected?

[nidud]

deleted

[nidud]

deleted

[johnsa]

So in conclusion, it was a good option to add (-Sp) and we've done it, but it won't solve the Delphi/FPC issue. I guess for that you'll have to resort to the manual work-around to avoid it merging the segments and only
respecting it's own 4 byte alignment.

[nidud]

deleted