[TUHS] LSX issues and musing

[TUHS] LSX issues and musing

[Gavin Tersteeg]

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

Hello, and greetings!

I guess as this is my first post here, I should give some background on
what I have been working on. Last summer I spent a lot of time getting UNIX
V6 working on my PDP-11/23 system. It took a lot of tinkering with the
kernel and drivers to make it work in the way I wanted to, but in the end I
was left with a system that ran well enough to do some demonstrations at
VCFMW.

This year I want to do more stuff with 1970s era UNIX, but now with even
more technical restrictions. I have had a Heathkit H-11 (consumer grade
PDP-11/03) for a while now, and I have been looking for something
interesting to do with it. From my research, it seems like there were two
different UNIX variants that could run on a system like this. These
variants were LSX and MINI-UNIX. MINI-UNIX seems to require a decent
mass-storage device like a RK05 and some porting to work on an 11/03, while
LSX is designed to work on exactly the hardware specs that I have on hand.

So on to the actual issues I am having at the moment: I have put together a
SIMH instance to get the ball rolling in building a kernel that will boot
on my EIS-less 11/03, but I am having significant difficulty actually
getting the kernel to build. The first issue is that the C compiler will
randomly spit out a "0: Missing temp file" when attempting to compile
something. This is annoying, but circumventable by just running the same
command over and over until it works. The second issue, however, is much
more of a road block for me. I can't seem to get the kernel to actually
link together once everything is compiled. When the final "ld -X" is
executed, I always get the following errors:

"
Undefined:
_end
_edata
_decmch
"
(This is from the build script found in the "shlsx" file)
https://minnie.tuhs.org/cgi-bin/utree.pl?file=LSX/sys/shlsx

I am assuming that this is some sort of issue with the object file
orderings, but I simply do not know enough about V6 ld to properly debug
this issue. I am hoping that somebody here has already run into this issue,
and knows what I am doing wrong.

If I can get this working, I have a long laundry list of modifications and
experiments that I want to run with LSX, but as it stands, this is where I
am stuck at.

Thank you,
Gavin

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

[TUHS] Re: LSX issues and musing

[Warner Losh]

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

On Mon, Jul 11, 2022, 1:48 PM Gavin Tersteeg <gctersteeg@gmail.com> wrote:

> Hello, and greetings!
>
> I guess as this is my first post here, I should give some u background on
> what I have been working on. Last summer I spent a lot of time getting UNIX
> V6 working on my PDP-11/23 system. It took a lot of tinkering with the
> kernel and drivers to make it work in the way I wanted to, but in the end I
> was left with a system that ran well enough to do some demonstrations at
> VCFMW.
>
> This year I want to do more stuff with 1970s era UNIX, but now with even
> more technical restrictions. I have had a Heathkit H-11 (consumer grade
> PDP-11/03) for a while now, and I have been looking for something
> interesting to do with it. From my research, it seems like there were two
> different UNIX variants that could run on a system like this. These
> variants were LSX and MINI-UNIX. MINI-UNIX seems to require a decent
> mass-storage device like a RK05 and some porting to work on an 11/03, while
> LSX is designed to work on exactly the hardware specs that I have on hand.
>
> So on to the actual issues I am having at the moment: I have put together
> a SIMH instance to get the ball rolling in building a kernel that will boot
> on my EIS-less 11/03, but I am having significant difficulty actually
> getting the kernel to build. The first issue is that the C compiler will
> randomly spit out a "0: Missing temp file" when attempting to compile
> something. This is annoying, but circumventable by just running the same
> command over and over until it works. The second issue, however, is much
> more of a road block for me. I can't seem to get the kernel to actually
> link together once everything is compiled. When the final "ld -X" is
> executed, I always get the following errors:
>
> "
> Undefined:
> _end
> _edata
> _decmch
> "
> (This is from the build script found in the "shlsx" file)
> https://minnie.tuhs.org/cgi-bin/utree.pl?file=LSX/sys/shlsx
>
> I am assuming that this is some sort of issue with the object file
> orderings, but I simply do not know enough about V6 ld to properly debug
> this issue. I am hoping that somebody here has already run into this issue,
> and knows what I am doing wrong.
>

_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.

_decmch is likely in m.s so maybe that's not included.  Iirc it should be
next to last...

You might already have files with these symbols... nm is your friend here...

Warner

If I can get this working, I have a long laundry list of modifications and
> experiments that I want to run with LSX, but as it stands, this is where I
> am stuck at.
>
> Thank you,
> Gavin
>

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

[TUHS] Re: LSX issues and musing

[Clem Cole]

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

@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.

>
> _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.

@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.

> ᐧ

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

[TUHS] Re: LSX issues and musing

[Warner Losh]

[-- 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 --]

[TUHS] Re: LSX issues and musing

[Phil Budne]

A quick google for _decmch found:

https://www.tuhs.org/cgi-bin/utree.pl?file=LSX/sys/low.s

.....
.if DEC
.if EIS-1
.globl	_decmch

rxcs = 177170
rxdb = 177172

_decmch:
	mov	r2,-(sp)
	mov	$rxdb,r1
	mov	4(sp),r0
	asl	r0
	add	4(sp),r0
	clr	r2
.....