Hi,
Original reporter here. Since the AI question came up in the thread, I'd
rather answer it straight than let it sit there.
Yes, I use AI to write code. My hand is crippled and typing at any length
isn't really on the cards for me anymore, so these days I dictate, and I
review and test what comes back rather than typing it out myself. That's
not an excuse for anything that turns out to be wrong - what I send is
mine and I'll own it - but the honest answer to the question is yes, and
it seemed worse to leave it unsaid.
For the record, what I originally sent was small: 13 lines gated on
TARGETOS_BSD, adding the plain etext/edata/end next to the existing
underscored ones in tcc_add_linker_symbols(). The reasoning was narrow.
glibc supplies the plain names from its own crt objects, BSD libc doesn't,
and BDWGC looks up etext/end directly to bound its conservative root
region. I tested that on a FreeBSD 15.1 VM against a real prebuilt
libgc.a and left it there. I wasn't proposing the wider PROVIDE work and
hadn't thought it through to anything like that depth.
On your two points:
The _end one looks real to me. 149+override_end_copy_reloc.c asserts that
a user's `int _end(void)` wins and returns 24, but _end goes through
set_linker_sym, which is meant to be unconditional. Both of those can't be
true at once, and it isn't only a naming quibble.
The `char end = 7` case I'm less certain about, and it isn't my call. It's
in a DSO (151+_dso_linker_symbol.c), so what's being exercised is
executable-over-DSO interposition, which real ELF linkers do perform.
Whether TCC ought to is a judgement about what TCC is for, and you're far
better placed to make that than I am.
For what I actually reported, none of it matters much either way. BDWGC
declares extern etext/end and never defines them, so it only needs the
plain referenced-but-not-defined case - which is the rule you described
anyway. None of the disputed behaviour touches it.
One thing worth flagging if the wider commit does get rolled back: my
original patch wouldn't answer the naive-user concern either. It called
set_global_sym unconditionally, so a user's `end` would get clobbered
harder than PROVIDE clobbers it. If that's the worry, PROVIDE is the
better primitive - the argument is about how much of it to build, not
whether it's the right thing.
Happy to retest whatever ends up landing, on FreeBSD, if that's useful.
Richard
_______________________________________________
Tinycc-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
