It is not much of a problem because one can always manually align the entry point, but this would go unnoticed by coders expecting that FASM internal linker would do it for them (as in the case with external linkers).

ofc code alignment is not a requirement. But it does help in branch prediction, instruction fetch, front-end stalls and similar performance stuff. In fact, FASM PE's executable version does align the entry point to 8 or 16 boundaries (i can't remember which one). If you switched the position of the two segments shown above, the entry point is in fact aligned to 16-byte boundaries.

It gives me the impression that FASM aligns only the first segment it finds in the source, and also suggests that the entry point should be in the first (code) segment in the source. This is quite limiting IMHO. idk, perhaps it has something to do with how kernel handles the entry point.

Usually, the entry point gets executed only once. GCC even marks it as "cold" by default (which means no alignment either, as far as I know). The entry point doesn't have to be at the beginning either.

It makes no sense to align the entry point when a "hot path" function (one called during an inner loop) would benefit from alignment or cache locality instead (stuck hot functions called near each other in close space, and align them of course). Just place the entry point somewhere in darkest pits of anti-performance because it's not important for speed.

@Furs
GCC aligns main entry point to 8/16-byte boundaries. Obviously there is branch prediction involved when GCC calls main and therefore it is crucial for performance for __main to be aligned. So does ld and golink. Even FASM PE's/PE64 console format does it all the time, every time. The only one off here is ELF64 executable format.

GCC aligns main entry point to 8/16-byte boundaries. Obviously there is branch prediction involved when GCC calls main and therefore it is crucial for performance for __main to be aligned. So does ld and golink.

Just because something is aliigned in no way implies it is "crucial for performance". A single call/jmp, even if it is unpredicted and unaligned and uncached, would not even register on any performance monitoring tools.

fasmnewbie wrote:

Even FASM PE's/PE64 console format does it all the time, every time. The only one off here is ELF64 executable format.

PE format is an entirely different thing from ELF. They are not comparable, they load differently and they are formatted differently.

Neither of the formats does align the entry point, this would be pointless. Usually the sections are aligned (this is needed to set up the section attributes, for example) so if you put your entry point right at the start of an section, like in these PE samples, it is going to be aligned just because it has been given the same address as entire section. But an address given to ENTRY directive can be any address:

Neither of the formats does align the entry point, this would be pointless. Usually the sections are aligned (this is needed to set up the section attributes, for example) so if you put your entry point right at the start of an section, like in these PE samples, it is going to be aligned just because it has been given the same address as entire section. But an address given to ENTRY directive can be any address:

Ok. Fair enough. That means coders wishing to use ELF64 executable format should manually align their entry points, if their code segment is preceded by other segment. Just to confirm my suspicion.

One more thing, I am wondering if there's any correlation between the size of data in the data segment and the relative position of the entry point. Because everytime I extend / decrease the string "hello world" in the first post, the entry point position shifted. From what I can see, the two segments are far apart from each other (by pages) and should not interfere with one another?

One more thing, I am wondering if there's any correlation between the size of data in the data segment and the relative position of the entry point. Because everytime I extend / decrease the string "hello world" in the first post, the entry point position shifted. From what I can see, the two segments are far apart from each other (by pages) and should not interfere with one another?

The ELF format is different from PE, the segments are not extended to fill the slack space between. So all data and code is joined together with just the section headers between. You can't change that, it is the ELF format. When the loader allocates the pages in memory you will find "gaps" before and after each section where the code and data has been skipped to match the file arrangement.

Loadable process segments must have congruent values for p_vaddr and p_offset, modulo the page size.

This means that the offset that the code has in file affects the address where it is going to be loaded in memory. Since page size is 1000h, if entry point is at offset 0C1h in file, in memory it must have an address of form xxxxx0C1h. Therefore anything that causes things in file to move around is going to affect this address.

Thanks for the explanation and link Tomasz. It answers some of my doubts.

From what I understand, in Linux, the alignment state of a segment is dependant upon how things are laid out in other, probably unrelated, segment or segment(s) which may or may not have similar segment flags as the segment in question.

e.g, If my executable segment appears first in my source, then followed by a writeable segment, there's a chance that the data (2nd) segment would start at uneven address/page. Am I seeing this correctly?

@Furs
GCC aligns main entry point to 8/16-byte boundaries. Obviously there is branch prediction involved when GCC calls main and therefore it is crucial for performance for __main to be aligned. So does ld and golink. Even FASM PE's/PE64 console format does it all the time, every time. The only one off here is ELF64 executable format.

GCC aligns hot functions to 16-bytes, if it was 8-byte aligned it only proves that it just happened to be that way and wasn't exactly intended.

But I mean, you need some hot functions in there (__attribute__((hot))), otherwise there will be no point. If the entry point is the only function then obviously it's going to be aligned since the section itself is. This is just happenstance though. Hot functions get placed before cold functions and thus the entry point is placed last as well in this situation.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum