03/18/17 00:51:05, Sven Barth via fpc-devel <
Post by Sven Barth via fpc-develBo, 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).
Thanks, now i understand how its work. Plus as i understand on Linux (and
other unixes) threadvar for external threads allocated on first access to
them (and free via PThread ability to call destructor for key).
Correct.
(and my first word should have been "No", not "Bo"; stupid smartphone
keyboard)
Post by Sven Barth via fpc-develWhy *should* it be auto generated if one can use a table and let the
RTL do the rest.
Is it not better make all that can be done in compile time? Its not more
complex solution for compiler code, but as i see it, its more harmonious
(Its depend not only INIFINAL, but all tables, than used in RTL to make
work of compiler/linker. As example, FPC_THREADVARTABLES. Different
modules, i mean DLL or SO, use different TLS keys for their threadvar
regions. But why position of variable from begin of threadvar region must
be generated in runtime? Isn`t it work for linker?). Possible this is
depend on that "dynamic packages"?
If you have different modules (the binary and the libraries) then they are
*separate* entities. Cause it could be that a Pascal library is used with a
C binary and thus a library has the whole RTL statically linked (or at
least that part that is used).
Only dynamic packages allow one to transparently have units be part of
different binary modules yet providing one whole application. Package
libraries can however only be used by a binary compiled with the same
compiler as they rely on quite a bit of compiler magic.
Post by Sven Barth via fpc-develAlso with the addition of dynamic packages this will move even more
towards a table based approach.
Where i can read information about what is it and why we need it? What
kind of problems is must solve? Because we already have dll/so, and as i
know and see for now its enough. Possible my knowledge is not enough to see
whole problem.
With dynamic packages you can share classes, strings, memory, etc. between
the modules (the main binary and the different package libraries), because
the RTL will only exist once. And all this transparently for the user.
When you use ordinary libraries you need to use a shared memory manager to
pass strings around and you can't use the "as" and "is" operators inside
the main binary on classes passed in from the libraries (and by extension
this also applies to exceptions).
Post by Sven Barth via fpc-develBut you can set the corresponding PE flag for ASLR using $SetPEOpts (or
so). No recompilation needed in that case.
Can. But what if i dont want ASLR binary? Its totaly valid.
Since ASLR is disabled by default in FPC that question is useless.
Post by Sven Barth via fpc-develMicrosoft 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?
Recommendation in not a law (like it is with SEH in Win64). C compilers
allow both type of programs, depend on what programmer need. Is it need
many work to change it? As i see it, its just one check in compiler code
for global varibles (if select PIC - use RIP-related, if not - use direct).
It already done in linux. I think it was better to give compiler user more
possibilities when its cost almoust nothing.
If it is so important to you: patches are welcome. But keep in mind that
the default needs to be the status quo.
Regards,
Sven