On Mon, Jul 11, 2022 at 2:27 PM Clem Cole <clemc@ccc.com> wrote:

On Mon, Jul 11, 2022 at 4:03 PM Warner Losh <imp@bsdimp.com> wrote:

_end is the end of the text segment. _edata same for the data. You can create these two by just creating a file that defines them as symbols = . And global. And link that file last. Though crt is supposed to have that. 
Hmmm -- I might have miss remembered this...  but I'm pretty sure the way ld(1) worked is that it supplied _edata, _etext, and _end automagically by ld(1) IIF, there are no other undefined symbols. Adding them into a file is probably not going to get what you want.

Oh right, _etext, _edata and _end are supposed to be linker creatures (created by the linker), but I can't recall when the linker started doing that...

_decmch is likely in m.s so maybe that's not included.  Iirc it should be next to last...
My bet is this key to the whole issue he is having.  If Gavin can figures out what gives WRT _decmch, I bet it links. 

That's the area I'd try first... But I'd expect both data and bss symbols to be scattered in many of the other files though... It may be something as simple as an empty .o file from those compiler runs that failed...
@Gavin Tersteeg -- I would trust Warner's memory more than mine since he tries to keep 2.9BSD alive,  but he knows I go back to V5 and the early/mid 70s; but bits in my memory have decayed over the years. Suggestion, take a quick peek in the sources to ld.c  and look for it hard coding the check for those three symbols.  They will look up as undefined originally, then latter get set to values only if there are no other UNDEFINED symbols.

 2.11BSD, but who's counting :)