6 Aug
2020
6 Aug
'20
1:28 a.m.
I finally munged lbforth.c (https://gist.github.com/lbruder/10007431) into
compiling cleanly on mostly-stock v7 with the system compiler (lbforth
itself does fine on 211BSD, but it needs a little help to build in a real
K&R environment).
Which would be nice, except that when it gets to the linker....
$ cc -o 4th forth.c
ld:forth.o: Local symbol botch
WTF?
How do I begin to debug this?
Adam
6 Aug
6 Aug
2:01 a.m.
Looking through the code, I see some awfully long function names. Does anyone recall if
there are/were limits on the size of variable and function names?
Could that cause this error?
On Aug 5, 2020, at 9:30 PM, Adam Thornton
<athornton(a)gmail.com> wrote:
I finally munged lbforth.c (https://gist.github.com/lbruder/10007431) into compiling
cleanly on mostly-stock v7 with the system compiler (lbforth itself does fine on 211BSD,
but it needs a little help to build in a real K&R environment).
Which would be nice, except that when it gets to the linker....
$ cc -o 4th forth.c
ld:forth.o: Local symbol botch
WTF?
How do I begin to debug this?
Adam
3:04 a.m.
On Wed, Aug 5, 2020, 8:12 PM Jim Capp <jcapp(a)anteil.com> wrote:
Maybe too many symbols?
The error comes from lookloc. This is called for external type relocations.
It searches the local symbol table for something that matches the
relocation entry. This error happens when it can't find it...
Not sure of the root causes for *that* though.
Warner
> On Aug 5, 2020, at 9:30 PM, Adam Thornton <athornton(a)gmail.com> wrote:
>
> I finally munged lbforth.c (https://gist.github.com/lbruder/10007431)
> into compiling cleanly on mostly-stock v7 with the system compiler (lbforth
> itself does fine on 211BSD, but it needs a little help to build in a real
> K&R environment).
> Which would be nice, except that when it
gets to the linker....
> $ cc -o 4th forth.c
> ld:forth.o: Local symbol botch
> WTF?
> How do I begin to debug this?
> Adam
Looking through the code, I see some awfully long
function names. Does
anyone recall if there are/were limits on the size of variable and function
names?
8 I think was the limit.
Could that cause this error?
3:08 a.m.
On Wed, Aug 5, 2020, 9:04 PM Warner Losh <imp(a)bsdimp.com> wrote:
On Wed, Aug 5, 2020, 8:12 PM Jim Capp <jcapp(a)anteil.com> wrote:
Maybe too many symbols?
The error comes from lookloc. This is called for external type
relocations. It searches the local symbol table for something that matches
the relocation entry. This error happens when it can't find it...
Not sure of the root causes for *that* though.
Try cc -c and do size on the .o. that might give you a hint about what is
too big.
Warner
Warner
Looking through the code, I see some awfully long
function names. Does
anyone recall if there are/were limits on the size of variable and function
names?
8 I think was the limit.
Could that cause this error?
> On Aug 5, 2020, at 9:30 PM, Adam Thornton <athornton(a)gmail.com> wrote:
>
>
> I finally munged lbforth.c (https://gist.github.com/lbruder/10007431)
> into compiling cleanly on mostly-stock v7 with the system compiler (lbforth
> itself does fine on 211BSD, but it needs a little help to build in a real
> K&R environment).
>
> Which would be nice, except that when it gets to the linker....
>
> $ cc -o 4th forth.c
> ld:forth.o: Local symbol botch
>
> WTF?
>
> How do I begin to debug this?
>
> Adam
>
>
5:55 a.m.
Thanks.
Part of getting the thing to compile for V7 was shortening the names so they were unique
in the first 8 characters (rather like I had to do for Frotz on TOPS-20).
I suspect “too many symbols” since I wrote a cpppp (C preprocssor preprocessor) to emulate
the symbol pasting in the original code, and there are a _LOT_ (well, 71) of
BUILTIN(a,b,c,d) and ADD_BUILTIN(c) which each expand into a function.
Wondering if breaking it up into multiple source files, and thus object files, would help.
Doubt it will but maybe I will try that tomorrow.
Adam
4:57 a.m.
On Wed, 5 Aug 2020, Warner Losh wrote:
On Wed, Aug 5, 2020, 8:12 PM Jim Capp
<jcapp(a)anteil.com> wrote:
Looking through the code, I see some awfully long function names.
Does anyone recall if there are/were limits on the size of
variable and function names?
8 I think was the limit.
Seven plus the leading (implied) underscore?
-- Dave
7:16 a.m.
On Thu, Aug 06, 2020 at 02:57:25PM +1000, Dave Horsfall wrote:
On Wed, 5 Aug 2020, Warner Losh wrote:
K&R 1st edition Reference Manual section 2.2 mentions 8 (including
underscore) as the number of significant characters, though names can
be longer. External names are more restricted: it has a table of
limits for external names for various targerts. PDP-11 is 7 chars,
Honeywell 6000 is 6 chars (with no case distinction).
-Otto
On Wed, Aug 5, 2020, 8:12 PM Jim Capp
<jcapp(a)anteil.com> wrote:
Looking through the code, I see some awfully long function names.
Does anyone recall if there are/were limits on the size of
variable and function names?
8 I think was the limit.
Seven plus the leading (implied) underscore?
-- Dave 
4:09 p.m.
On Thu, Aug 06, 2020 at 11:47:09AM -0400, Paul Winalski wrote:
On 8/5/20, Adam Thornton <athornton(a)gmail.com>
wrote:
That's funny, I was just talking to my older son yesterday. We had the
chat about how much you could get done in a semester in college, a buddy
and I did about 80% of an Ada compiler. It was a lot. I told my kid
that industry is different, it moves way slower and that is because
there is a huge difference between something you get done in a few months
and throw away and something that you are going to hand off to users.
Error handling and messages matter a lot. Backwards compatibility
matters a lot.
Isn't Adam working on v7? If so, not so great error messages are
sort of understood, it was early times. They got better.
$ cc -o 4th forth.c
ld:forth.o: Local symbol botch
I hate error messages like that. Would it have been that much extra
trouble for ld to tell you which symbol caused the problem?
4:24 p.m.
On Thu, Aug 06, 2020 at 12:19:49PM -0400, Paul Winalski wrote:
On 8/6/20, Larry McVoy <lm(a)mcvoy.com> wrote:
I think we also sometimes forget how small 64K was. Terseness wasn't
a choice.
Isn't Adam working on v7? If so, not so great error messages are
sort of understood, it was early times. They got better.
Unix *was* a research project in those days, wasn't it? It's easy to
forget that these days.
11:41 p.m.
Here's the output of "size," which doesn't tell me much....I think.
Unless
in v7 data has to be under 32K rather than 64K? Surely not, right? (The
data segment is 32K of main memory for FORTH, plus some for the startup
Forth script, plus a bit for the line buffer and some miscellaneous pointer
variables.)
$ size forth.o
7580+34034+0 = 41614b = 0121216b
On Thu, Aug 6, 2020 at 9:24 AM Larry McVoy <lm(a)mcvoy.com> wrote:
On Thu, Aug 06, 2020 at 12:19:49PM -0400, Paul
Winalski wrote:
On 8/6/20, Larry McVoy <lm(a)mcvoy.com>
wrote:
I think we also sometimes forget how small 64K was. Terseness wasn't
a choice.
Isn't Adam working on v7? If so, not so great error messages are
sort of understood, it was early times. They got better.
Unix *was* a research project in those days, wasn't it? It's easy to
forget that these days.
7 Aug
7 Aug
12:35 a.m.
On Thu, Aug 6, 2020, 9:48 AM Paul Winalski <paul.winalski(a)gmail.com> wrote:
On 8/5/20, Adam Thornton <athornton(a)gmail.com>
wrote:
It's a relocation entry it can't find a symbol for that's the issue...
Warner
$ cc -o 4th forth.c
ld:forth.o: Local symbol botch
I hate error messages like that. Would it have been that much extra
trouble for ld to tell you which symbol caused the problem?
-Paul W.
4:30 a.m.
So maybe I missed a symbol when I was trying to make everything unique in 8
chars? There are no external symbols; all that's in my forth.h are macros
and typedefs.
Adam
On Thu, Aug 6, 2020 at 5:35 PM Warner Losh <imp(a)bsdimp.com> wrote:
On Thu, Aug 6, 2020, 9:48 AM Paul Winalski <paul.winalski(a)gmail.com>
wrote:
On 8/5/20, Adam Thornton
<athornton(a)gmail.com> wrote:
It's a relocation entry it can't find a symbol for that's the issue...
Warner
$ cc -o 4th forth.c
ld:forth.o: Local symbol botch
I hate error messages like that. Would it have been that much extra
trouble for ld to tell you which symbol caused the problem?
-Paul W.
5:49 a.m.
It's likely too many. Ld used to have lots of fixed sized arrays... I had
to hack on the 2.10.1BSD to change supported ar formats and noticed. Also
had to tweak some of the constants to get something much bigger compiling.
The BSD ld had overlay suppot merged into it, but was otherwise quite
similar to V7, though I've not done a deep dive into ld from v7...
Tl;dr: chances are good more, smaller files will work.
Warner
On Thu, Aug 6, 2020, 10:30 PM Adam Thornton <athornton(a)gmail.com> wrote:
So maybe I missed a symbol when I was trying to make
everything unique in
8 chars? There are no external symbols; all that's in my forth.h are
macros and typedefs.
Adam
On Thu, Aug 6, 2020 at 5:35 PM Warner Losh <imp(a)bsdimp.com> wrote:
>
>
> On Thu, Aug 6, 2020, 9:48 AM Paul Winalski <paul.winalski(a)gmail.com>
> wrote:
>
>> On 8/5/20, Adam Thornton <athornton(a)gmail.com> wrote:
>> >
>> > $ cc -o 4th forth.c
>> > ld:forth.o: Local symbol botch
>>
>> I hate error messages like that. Would it have been that much extra
>> trouble for ld to tell you which symbol caused the problem?
>>
>
> It's a relocation entry it can't find a symbol for that's the
issue...
>
> Warner
>
>> -Paul W.
>>
>
5:54 a.m.
Thanks. Since I am already pre-preprocessing the macros that generate the
FORTH builtin words (no token pasting in K&R C), I can trivially split them
out into individual files each with a single short function.
On Thu, Aug 6, 2020 at 10:49 PM Warner Losh <imp(a)bsdimp.com> wrote:
It's likely too many. Ld used to have lots of
fixed sized arrays... I had
to hack on the 2.10.1BSD to change supported ar formats and noticed. Also
had to tweak some of the constants to get something much bigger compiling.
The BSD ld had overlay suppot merged into it, but was otherwise quite
similar to V7, though I've not done a deep dive into ld from v7...
Tl;dr: chances are good more, smaller files will work.
Warner
On Thu, Aug 6, 2020, 10:30 PM Adam Thornton <athornton(a)gmail.com> wrote:
> So maybe I missed a symbol when I was trying to make everything unique in
> 8 chars? There are no external symbols; all that's in my forth.h are
> macros and typedefs.
>
> Adam
>
> On Thu, Aug 6, 2020 at 5:35 PM Warner Losh <imp(a)bsdimp.com> wrote:
>
>>
>>
>> On Thu, Aug 6, 2020, 9:48 AM Paul Winalski <paul.winalski(a)gmail.com>
>> wrote:
>>
>>> On 8/5/20, Adam Thornton <athornton(a)gmail.com> wrote:
>>> >
>>> > $ cc -o 4th forth.c
>>> > ld:forth.o: Local symbol botch
>>>
>>> I hate error messages like that. Would it have been that much extra
>>> trouble for ld to tell you which symbol caused the problem?
>>>
>>
>> It's a relocation entry it can't find a symbol for that's the
issue...
>>
>> Warner
>>
>>> -Paul W.
>>>
>>
1351
days inactive
1352
days old
15 comments
7 participants
participants (7)
-
Adam Thornton -
Dave Horsfall -
Jim Capp -
Larry McVoy -
Otto Moerbeek -
Paul Winalski -
Warner Losh