On 30.07.2026 13:39, Mounir IDRASSI via Tinycc-devel wrote:
Hi,
I just saw your 38059770 commit. Thanks for the Windows TLS work and
the DEF parser follow-up.
Thanks, no matter. Just for the records, from
$ git log -16 --shortstat --oneline
38059770 tccpe: tls on windows (i386 / x86-64 / arm64)
19 files changed, 265 insertions(+), 258 deletions(-)
That's netto +7 lines ;)
Indeed, I over-scoped Richard's report and pushed too quickly.
I should have preserved his authorship, and the unwrapped commit
messages are my mistake.
The wider work was prompted by concrete cases I noticed while tracing
the code: `_end` is created before copy relocations can extend `.bss`.
Separately named allocatable sections can lie beyond the canonical
sections, and a symbol can be visible only through an input DSO.
Ok, I must say you seem to have gotten the wider fundamental principles
and implications related to the issue rather well an completely.
However as to the volume, number of new functions, number of new test
files etc, I don't know whether this work was assisted by AI, but if
so maybe you could tell them agents that this is still the TinyCC and
that there are some humans who eventually might want to understand
what's going on there really. Code is allowed to be (a bit) weird
if it just works, or it may be incomplete as long as it's still simple.
But not weird and incomplete at the same time. (just for the audience,
don't take it personally)
`char end = 7` was deliberately testing ELF symbol preemption,
Ok, so what is the deal? As I understood it, the linker should set
the underscored symbols _etext/_edata/_end unconditionally, as before,
but 'provide' the non-underscored (old) symbols only when needed,
that is: Referenced in user code but not defined in user code.
At least that is what your code suggests:
set_linker_sym(s1, "_etext", text_section, -1);
set_linker_sym(s1, "_edata", data_section, -1);
set_linker_sym(s1, "_end", bss_section, -1);
/* These conventional ELF symbols have PROVIDE semantics. */
provide_linker_sym(s1, "etext", text_section, -1);
provide_linker_sym(s1, "edata", data_section, -1);
provide_linker_sym(s1, "end", bss_section, -1);
Plus testcases
int end(void) { return 42; }
and
int etext(void) { return 1; }
int edata(void) { return 2; }
int end(void) { return 3; }
which seem to confirm the simple rule as those being available as
ordinary symbols.
But then
char end = 7;
which your code points to _end(bss) already contradicts the rule.
Certainly more likely someone out there would like to have a variable
named 'end' entirely naively, than s/he would be interested in the end
of some bss segment. (I guess the only thing really interested is the
Boehm GC, aside from the question whether its behavior in combination
with code from tcc could be considered as entirely predictable).
Anyway, back to another test case:
int _end(void) { return 24; }
which now seems to contradict the basic policy in the other direction,
I would think. That is, it seems allowed but shouldn't be.
I mean maybe there are quite some historical behaviors or misbehaviors
to be found in gcc or elsewhere, but we don't necessarily need to have
all that in TCC, in particular not when the misbehavior can't quite easily
be implemented at all ;)
-- gr
Regards,
Mounir IDRASSI
_______________________________________________
Tinycc-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
