[TUHS] Re: LSX issues and musing

[Warner Losh <imp@bsdimp.com>]

[-- Attachment #1: Type: text/plain, Size: 1864 bytes --]

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

> @Warner Losh <imp@bsdimp.com>
>
> 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 <+gctersteeg@gmail.com> -- 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 :)

Warner

> ᐧ
>

[-- Attachment #2: Type: text/html, Size: 4662 bytes --]