The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Clem Cole <clemc@ccc.com>
To: Warner Losh <imp@bsdimp.com>
Cc: Gavin Tersteeg <gctersteeg@gmail.com>,
	The Eunuchs Hysterical Society <tuhs@tuhs.org>
Subject: [TUHS] Re: LSX issues and musing
Date: Mon, 11 Jul 2022 16:26:57 -0400	[thread overview]
Message-ID: <CAC20D2PdWn9SVJ0hO2SkxGM319=nmcq6vyhWBv3zdv7SuUt6bA@mail.gmail.com> (raw)
In-Reply-To: <CANCZdfooZVxqyU--1e2w7t-A+CfvKAG-auxMgvAQO8jcf-F5tg@mail.gmail.com>

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

  reply	other threads:[~2022-07-11 20:28 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-11 19:47 [TUHS] " Gavin Tersteeg
2022-07-11 20:01 ` [TUHS] " Warner Losh
2022-07-11 20:26   ` Clem Cole [this message]
2022-07-11 20:30     ` Warner Losh
2022-07-11 20:37 ` Phil Budne
2022-07-11 21:06 Noel Chiappa
2022-07-11 21:24 Noel Chiappa
2022-07-11 21:37 ` Gavin Tersteeg
2022-07-11 21:47 Paul Ruizendaal via TUHS
2022-07-11 23:47 Noel Chiappa
2022-07-15  8:07 ` Gavin Tersteeg
2022-07-27  8:02   ` Gavin Tersteeg
2022-07-27 16:24     ` Heinz Lycklama
2022-07-30  4:39       ` Gavin Tersteeg
2022-07-31 19:57 Noel Chiappa
2022-08-01  5:37 ` Heinz Lycklama
2022-08-02 17:56   ` Gavin Tersteeg
2022-08-03  4:32     ` steve jenkin
2022-08-03  4:55       ` Ron Natalie
2022-08-03  5:09       ` G. Branden Robinson
2022-08-03 15:17 Noel Chiappa
2022-08-05  4:35 Paul Ruizendaal via TUHS

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAC20D2PdWn9SVJ0hO2SkxGM319=nmcq6vyhWBv3zdv7SuUt6bA@mail.gmail.com' \
    --to=clemc@ccc.com \
    --cc=gctersteeg@gmail.com \
    --cc=imp@bsdimp.com \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).