[-- Attachment #1: Type: text/plain, Size: 398 bytes --] 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 [-- Attachment #2: Type: text/html, Size: 617 bytes --]
[-- Attachment #1: Type: text/plain, Size: 712 bytes --] 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@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 [-- Attachment #2: Type: text/html, Size: 1221 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1124 bytes --] On Wed, Aug 5, 2020, 8:12 PM Jim Capp <jcapp@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. Could that cause this error? > 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@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 > > [-- Attachment #2: Type: text/html, Size: 2469 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1346 bytes --] On Wed, Aug 5, 2020, 9:04 PM Warner Losh <imp@bsdimp.com> wrote: > > > On Wed, Aug 5, 2020, 8:12 PM Jim Capp <jcapp@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. > > Could that cause this error? >> > > 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 > >> On Aug 5, 2020, at 9:30 PM, Adam Thornton <athornton@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 >> >> [-- Attachment #2: Type: text/html, Size: 3237 bytes --]
On Wed, 5 Aug 2020, Warner Losh wrote:
> On Wed, Aug 5, 2020, 8:12 PM Jim Capp <jcapp@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
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
On Thu, Aug 06, 2020 at 02:57:25PM +1000, Dave Horsfall wrote:
> On Wed, 5 Aug 2020, Warner Losh wrote:
>
> > On Wed, Aug 5, 2020, 8:12 PM Jim Capp <jcapp@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
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 8/5/20, Adam Thornton <athornton@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?
-Paul W.
On Thu, Aug 06, 2020 at 11:47:09AM -0400, Paul Winalski wrote:
> On 8/5/20, Adam Thornton <athornton@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?
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.
On 8/6/20, Larry McVoy <lm@mcvoy.com> wrote:
>
> 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.
-Paul W.
On Thu, Aug 06, 2020 at 12:19:49PM -0400, Paul Winalski wrote:
> On 8/6/20, Larry McVoy <lm@mcvoy.com> wrote:
> >
> > 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.
I think we also sometimes forget how small 64K was. Terseness wasn't
a choice.
[-- Attachment #1: Type: text/plain, Size: 878 bytes --] 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@mcvoy.com> wrote: > On Thu, Aug 06, 2020 at 12:19:49PM -0400, Paul Winalski wrote: > > On 8/6/20, Larry McVoy <lm@mcvoy.com> wrote: > > > > > > 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. > > I think we also sometimes forget how small 64K was. Terseness wasn't > a choice. > [-- Attachment #2: Type: text/html, Size: 1346 bytes --]
[-- Attachment #1: Type: text/plain, Size: 427 bytes --] On Thu, Aug 6, 2020, 9:48 AM Paul Winalski <paul.winalski@gmail.com> wrote: > On 8/5/20, Adam Thornton <athornton@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. > [-- Attachment #2: Type: text/html, Size: 1093 bytes --]
[-- Attachment #1: Type: text/plain, Size: 695 bytes --] 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@bsdimp.com> wrote: > > > On Thu, Aug 6, 2020, 9:48 AM Paul Winalski <paul.winalski@gmail.com> > wrote: > >> On 8/5/20, Adam Thornton <athornton@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. >> > [-- Attachment #2: Type: text/html, Size: 1705 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1228 bytes --] 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@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@bsdimp.com> wrote: > >> >> >> On Thu, Aug 6, 2020, 9:48 AM Paul Winalski <paul.winalski@gmail.com> >> wrote: >> >>> On 8/5/20, Adam Thornton <athornton@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. >>> >> [-- Attachment #2: Type: text/html, Size: 2656 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1561 bytes --] 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@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@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@bsdimp.com> wrote: >> >>> >>> >>> On Thu, Aug 6, 2020, 9:48 AM Paul Winalski <paul.winalski@gmail.com> >>> wrote: >>> >>>> On 8/5/20, Adam Thornton <athornton@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. >>>> >>> [-- Attachment #2: Type: text/html, Size: 3281 bytes --]
> From: Warner Losh > 8 I think was the limit. IIRC, you could use longer names than that (in C), but external references only used the first 7 (in C - C symbols had a leading '_' tacked on; I used to know why), 8 (in assembler). > Could that cause this error? Seems unlikely - see below. > 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... Someone who actually looked at the source: https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/ld.c instead of just guessing. Give that man a star! I spent a while looking at the code, trying to figure out i) how it works, and ii) what's going wrong with that message, but I don't have a definitive answer. The code is not super well commented, so one has to actually understand what it's doing! :-) It seems to my initial perusal that it maintains two symbol tables, one for globals (which accumulates as each file is processed), and one for locals (which is discarded/reset for each file). As Werner mentioned, the message appears when a local symbol referenced in the relocation information in the current file can't be found (in the local symbol table). It's not, I think, simply due to too many local symbols in an input file - there seems to be a check for that as it's reading the input file symbol table: if (lp >= &local[NSYMPR]) error(1, "Local symbol overflow"); *lp++ = symno; *lp++ = sp; although of course there could be a bug which breaks this check. It seems to me that this is an 'impossible' error, one which can only happen due to i) a bug in the loader (a fencepost error, or something), or ii) an error in the input a.out file. I don't want to spend more time on it, since I'm not sure if you've managed to bypass the problem. If not, let me know, and we'll track it down. (This may involve you addding some printf's so we have more info about the details.) Noel
[-- Attachment #1: Type: text/plain, Size: 685 bytes --] On Fri, Aug 7, 2020 at 12:07 PM Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote: IIRC, you could use longer names than that (in C), but external references > only used the first 7 (in C - C symbols had a leading '_' tacked on; I > used to > know why), 8 (in assembler). > Precisely to avoid collisions between external names in C and names in assembler (whose namespace was flat except for local labels) when they were linked into your program. For similar reasons, F77 names had a trailing '_' tacked on. John Cowan http://vrici.lojban.org/~cowan cowan@ccil.org There is / One art / No more / No less To do / All things / With art- / -Lessness --Piet Hein [-- Attachment #2: Type: text/html, Size: 1280 bytes --]
[-- Attachment #1: Type: text/plain, Size: 867 bytes --] On Fri, Aug 7, 2020 at 10:08 AM Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote: > > From: Warner Losh > > 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... > > Someone who actually looked at the source: > > https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/ld.c > > instead of just guessing. Give that man a star! > I've spent some time in ld.c lately: https://github.com/bsdimp/mk211bsd/blob/master/hints/160.ld.diff since I had to retro-fit the new archive support into the 2.10.1BSD + patches posted to comp.bugs.2bsd version of ld I needed for 2.11BSDpl0 :) Ideally, nobody would be able to tell my retrofits from the usenet patch that's also in this diff... Warner [-- Attachment #2: Type: text/html, Size: 1509 bytes --]