<p>Am 17.03.2017 22:16 schrieb "Bishop" <<a href="mailto:cat_shtaer@rambler.ru">cat_shtaer@rambler.ru</a>>:<br>
><br>
> 03/17/17 11:56:47, Sven Barth via fpc-devel <<a href="mailto:fpc-devel@lists.freepascal.org">fpc-devel@lists.freepascal.org</a>>:<br>
><br>
> >> 1) EXE-file contained .CRT section. As i understand it contained one pointer to _FPC_Tls_Callback functions from RTL. Is it used only for this?<br>
> > Correct.<br>
> And main sence of this function is allocated ThreadVar regions for thread, than was created in initialization code of DLL`s that was loaded staticaly (OS load them use information in .idata section)?<br></p>
<p>Bo, the main sense of this is to detect when a new thread is started and more importantly terminated cause only with this we can free the threadvar area of the thread accordingly (if the thread is an external one, not one started using BeginThread or TThread).</p>
<p>><br>
> > It probably should be .rdata, but I think that older binutils had problems with that, thus they were put into .data and that was never changed till now...<br>
> So now it is possible to change it? Plus what about 2nd part of my question?<br>
><br>
><br>
> >Or even possible it must be evicted and replace just with call instructions? I mean autogeneration of fpc_InitializeUnits and fpc_FinalizeUnits?<br>
> What reason for we need so strange init/final unit function calling solution? Autogenerated functions will take less space (direct or RIP-related address - all functions in same segment), safer than varible in w/r segment (this is a way to make some atack on application) and faster.</p>
<p>Why *should* it be auto generated if one can use a table and let the RTL do the rest.<br>
Also with the addition of dynamic packages this will move even more towards a table based approach.</p>
<p>><br>
> > I might remember it incorrectly, but I think that Microsoft says that all accesses should be RIP relative to reduce the need for relocations.<br>
> But EXE generated by FPC dont ASLR aware. This have no needed flags in EXE file header (I use VMMap to get info about process and it show ASLR modules). Windows support both type of executable (i dont say about DLL in this time). Static and ASLR. I think it will be logicaly if FPC can generate both type of applications (it already have flags for PIC and RIP-related addressing is a good form of PIC realization). Plus on Linux we have picture like it. Main binary can be PIC or not-PIC. SO-libraries can be only PIC (that logicaly because they need relocation, that exe-file can avoid).</p>
<p>But you can set the corresponding PE flag for ASLR using $SetPEOpts (or so). No recompilation needed in that case.<br>
Microsoft recommended that approach for Win64 so why should we do the work and implement it differently even if ASLR isn't enabled by default for FPC executables?</p>
<p>Regards,<br>
Sven</p>