Liste des Groupes | Revenir à cl c |
On 25/03/2024 12:26, David Brown wrote:On 25/03/2024 12:16, Michael S wrote:On Sun, 24 Mar 2024 23:43:32 +0100
David Brown <david.brown@hesbynett.no> wrote:>>
I could be wrong here, of course.
It seems, you are.
It happens - and it was not unexpected here, as I said. I don't
have all these compilers installed to test.
But it would be helpful if you had a /little/ more information. If
you don't know why some compilers generate binaries that have
memory mapped at 0x400000, and others do not, fair enough. I am
curious, but it's not at all important.
In the PE EXE format, the default image load base is specified in a
special header in the file:
Magic: 20B
Link version: 1.0
Code size: 512 200
Idata size: 1024 400
Zdata size: 512
Entry point: 4096 1000 in data:0
Code base: 4096
Image base: 4194304 400000
Section align: 4096
By convention it is at 0x40'0000 (I've no idea why).
More recently, dynamic loading, regardless of what it says in the PE
header, has become popular with linkers. So, while there is still a
fixed value in the Image Base file, which might be 0x140000000, it
gets loaded at some random address, usually in high memory above 2GB.
I don't know what's responsible for that, but presumably the OS must
be in on the act.
To make this possible, both for loading above 2GB, and for loading at
an address not known by the linker, the code inside the EXE must be
position-independent, and have relocation info for any absolute
64-bit static addresses. 32-bit static addresses won't work.
>
Les messages affichés proviennent d'usenet.