The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [TUHS] Debugging help sought
@ 2020-08-06  1:28 Adam Thornton
  2020-08-06  2:01 ` Jim Capp
  2020-08-06 15:47 ` Paul Winalski
  0 siblings, 2 replies; 19+ messages in thread
From: Adam Thornton @ 2020-08-06  1:28 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [TUHS] Debugging help sought
  2020-08-06  1:28 [TUHS] Debugging help sought Adam Thornton
@ 2020-08-06  2:01 ` Jim Capp
  2020-08-06  3:04   ` Warner Losh
  2020-08-06 15:47 ` Paul Winalski
  1 sibling, 1 reply; 19+ messages in thread
From: Jim Capp @ 2020-08-06  2:01 UTC (permalink / raw)
  To: Adam Thornton; +Cc: The Eunuchs Hysterical Society

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [TUHS] Debugging help sought
  2020-08-06  2:01 ` Jim Capp
@ 2020-08-06  3:04   ` Warner Losh
  2020-08-06  3:08     ` Warner Losh
  2020-08-06  4:57     ` Dave Horsfall
  0 siblings, 2 replies; 19+ messages in thread
From: Warner Losh @ 2020-08-06  3:04 UTC (permalink / raw)
  To: Jim Capp; +Cc: The Eunuchs Hysterical Society

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [TUHS] Debugging help sought
  2020-08-06  3:04   ` Warner Losh
@ 2020-08-06  3:08     ` Warner Losh
  2020-08-06  5:55       ` Adam Thornton
  2020-08-06  4:57     ` Dave Horsfall
  1 sibling, 1 reply; 19+ messages in thread
From: Warner Losh @ 2020-08-06  3:08 UTC (permalink / raw)
  To: Jim Capp; +Cc: The Eunuchs Hysterical Society

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [TUHS] Debugging help sought
  2020-08-06  3:04   ` Warner Losh
  2020-08-06  3:08     ` Warner Losh
@ 2020-08-06  4:57     ` Dave Horsfall
  2020-08-06  7:16       ` Otto Moerbeek
  1 sibling, 1 reply; 19+ messages in thread
From: Dave Horsfall @ 2020-08-06  4:57 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [TUHS] Debugging help sought
  2020-08-06  3:08     ` Warner Losh
@ 2020-08-06  5:55       ` Adam Thornton
  0 siblings, 0 replies; 19+ messages in thread
From: Adam Thornton @ 2020-08-06  5:55 UTC (permalink / raw)
  To: Warner Losh; +Cc: The Eunuchs Hysterical Society

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


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [TUHS] Debugging help sought
  2020-08-06  4:57     ` Dave Horsfall
@ 2020-08-06  7:16       ` Otto Moerbeek
  0 siblings, 0 replies; 19+ messages in thread
From: Otto Moerbeek @ 2020-08-06  7:16 UTC (permalink / raw)
  To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [TUHS] Debugging help sought
  2020-08-06  1:28 [TUHS] Debugging help sought Adam Thornton
  2020-08-06  2:01 ` Jim Capp
@ 2020-08-06 15:47 ` Paul Winalski
  2020-08-06 16:09   ` Larry McVoy
  2020-08-07  0:35   ` Warner Losh
  1 sibling, 2 replies; 19+ messages in thread
From: Paul Winalski @ 2020-08-06 15:47 UTC (permalink / raw)
  To: Adam Thornton; +Cc: The Eunuchs Hysterical Society

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.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [TUHS] Debugging help sought
  2020-08-06 15:47 ` Paul Winalski
@ 2020-08-06 16:09   ` Larry McVoy
  2020-08-06 16:19     ` Paul Winalski
  2020-08-07  0:35   ` Warner Losh
  1 sibling, 1 reply; 19+ messages in thread
From: Larry McVoy @ 2020-08-06 16:09 UTC (permalink / raw)
  To: Paul Winalski; +Cc: The Eunuchs Hysterical Society

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.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [TUHS] Debugging help sought
  2020-08-06 16:09   ` Larry McVoy
@ 2020-08-06 16:19     ` Paul Winalski
  2020-08-06 16:24       ` Larry McVoy
  0 siblings, 1 reply; 19+ messages in thread
From: Paul Winalski @ 2020-08-06 16:19 UTC (permalink / raw)
  To: Larry McVoy; +Cc: The Eunuchs Hysterical Society

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.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [TUHS] Debugging help sought
  2020-08-06 16:19     ` Paul Winalski
@ 2020-08-06 16:24       ` Larry McVoy
  2020-08-06 23:41         ` Adam Thornton
  0 siblings, 1 reply; 19+ messages in thread
From: Larry McVoy @ 2020-08-06 16:24 UTC (permalink / raw)
  To: Paul Winalski; +Cc: The Eunuchs Hysterical Society

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.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [TUHS] Debugging help sought
  2020-08-06 16:24       ` Larry McVoy
@ 2020-08-06 23:41         ` Adam Thornton
  0 siblings, 0 replies; 19+ messages in thread
From: Adam Thornton @ 2020-08-06 23:41 UTC (permalink / raw)
  To: Larry McVoy; +Cc: The Eunuchs Hysterical Society

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [TUHS] Debugging help sought
  2020-08-06 15:47 ` Paul Winalski
  2020-08-06 16:09   ` Larry McVoy
@ 2020-08-07  0:35   ` Warner Losh
  2020-08-07  4:30     ` Adam Thornton
  1 sibling, 1 reply; 19+ messages in thread
From: Warner Losh @ 2020-08-07  0:35 UTC (permalink / raw)
  To: Paul Winalski; +Cc: The Eunuchs Hysterical Society

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [TUHS] Debugging help sought
  2020-08-07  0:35   ` Warner Losh
@ 2020-08-07  4:30     ` Adam Thornton
  2020-08-07  5:49       ` Warner Losh
  0 siblings, 1 reply; 19+ messages in thread
From: Adam Thornton @ 2020-08-07  4:30 UTC (permalink / raw)
  To: Warner Losh; +Cc: The Eunuchs Hysterical Society

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [TUHS] Debugging help sought
  2020-08-07  4:30     ` Adam Thornton
@ 2020-08-07  5:49       ` Warner Losh
  2020-08-07  5:54         ` Adam Thornton
  0 siblings, 1 reply; 19+ messages in thread
From: Warner Losh @ 2020-08-07  5:49 UTC (permalink / raw)
  To: Adam Thornton; +Cc: The Eunuchs Hysterical Society

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [TUHS] Debugging help sought
  2020-08-07  5:49       ` Warner Losh
@ 2020-08-07  5:54         ` Adam Thornton
  0 siblings, 0 replies; 19+ messages in thread
From: Adam Thornton @ 2020-08-07  5:54 UTC (permalink / raw)
  To: Warner Losh; +Cc: The Eunuchs Hysterical Society

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [TUHS] Debugging help sought
  2020-08-07 16:07 Noel Chiappa
  2020-08-07 17:11 ` John Cowan
@ 2020-08-07 20:48 ` Warner Losh
  1 sibling, 0 replies; 19+ messages in thread
From: Warner Losh @ 2020-08-07 20:48 UTC (permalink / raw)
  To: Noel Chiappa; +Cc: The Eunuchs Hysterical Society

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [TUHS] Debugging help sought
  2020-08-07 16:07 Noel Chiappa
@ 2020-08-07 17:11 ` John Cowan
  2020-08-07 20:48 ` Warner Losh
  1 sibling, 0 replies; 19+ messages in thread
From: John Cowan @ 2020-08-07 17:11 UTC (permalink / raw)
  To: Noel Chiappa; +Cc: The Eunuchs Hysterical Society

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [TUHS] Debugging help sought
@ 2020-08-07 16:07 Noel Chiappa
  2020-08-07 17:11 ` John Cowan
  2020-08-07 20:48 ` Warner Losh
  0 siblings, 2 replies; 19+ messages in thread
From: Noel Chiappa @ 2020-08-07 16:07 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > 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


^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2020-08-07 20:49 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-08-06  1:28 [TUHS] Debugging help sought Adam Thornton
2020-08-06  2:01 ` Jim Capp
2020-08-06  3:04   ` Warner Losh
2020-08-06  3:08     ` Warner Losh
2020-08-06  5:55       ` Adam Thornton
2020-08-06  4:57     ` Dave Horsfall
2020-08-06  7:16       ` Otto Moerbeek
2020-08-06 15:47 ` Paul Winalski
2020-08-06 16:09   ` Larry McVoy
2020-08-06 16:19     ` Paul Winalski
2020-08-06 16:24       ` Larry McVoy
2020-08-06 23:41         ` Adam Thornton
2020-08-07  0:35   ` Warner Losh
2020-08-07  4:30     ` Adam Thornton
2020-08-07  5:49       ` Warner Losh
2020-08-07  5:54         ` Adam Thornton
2020-08-07 16:07 Noel Chiappa
2020-08-07 17:11 ` John Cowan
2020-08-07 20:48 ` Warner Losh

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