* [pups] 2.11BSD "make unix" aborts Error 141
@ 2003-03-19 16:52 Norman Wilson
0 siblings, 0 replies; 8+ messages in thread
From: Norman Wilson @ 2003-03-19 16:52 UTC (permalink / raw)
Steven M. Schultz:
It's the exit status of the assembler. On _some_ modules, the
assembler ('as') jumps off into the weeds and executes an 'exit'
system call with a non-zero value in R0. 141 is a lower case 'a'
as I recall.
0141 (octal) is 'a. 141 decimal is 0215 octal, i.e. carriage return with
parity.
What seems more likely is that 141 decimal is 0200 + 13 decimal. If a
simple value returned by wait, that means SIGPIPE + core image, which
seems unlikely. If an exit status as displayed by the shell, it just
means SIGPIPE (128 + signal number). Or is signal 13 different in 2.11
than in V7? (That seems even less likely.)
SIGPIPE doesn't seem entirely unreasonable as an accident that could
happen if something goes wrong in the assembly-language-code-tweaking
part of the kernel build.
Of course if it's a random value handed to sys exit, all rules are off.
Norman Wilson
Toronto ON
^ permalink raw reply [flat|nested] 8+ messages in thread
* [pups] 2.11BSD "make unix" aborts Error 141
2003-03-19 17:59 Steven M. Schultz
@ 2003-03-19 21:26 ` Warren Toomey
0 siblings, 0 replies; 8+ messages in thread
From: Warren Toomey @ 2003-03-19 21:26 UTC (permalink / raw)
On Wed, Mar 19, 2003 at 09:59:03AM -0800, Steven M. Schultz wrote:
[lamenting a difficult bug in as]
> What might be needed is a decent (or existent ;)) syscall tracing
> capability. That combined with the capability to "coredump a non-0
> exit process) might be enough to track down what's causing 'as'
> to depart the scene prematurely.
This might sound weird, but my Apout user-mode PDP-11 simulator might just
be the tool for this. It would be trivial to put some syscall tracing code
into the simulator, and I have rebuilt a 2.11BSD kernel with Apout several
times.
Warren
^ permalink raw reply [flat|nested] 8+ messages in thread
* [pups] 2.11BSD "make unix" aborts Error 141
@ 2003-03-19 18:58 Carl Lowenstein
0 siblings, 0 replies; 8+ messages in thread
From: Carl Lowenstein @ 2003-03-19 18:58 UTC (permalink / raw)
> From: "Steven M. Schultz" <sms at 2BSD.COM>
> To: pups at minnie.tuhs.org
> Subject: Re: [pups] 2.11BSD "make unix" aborts Error 141
> List-Archive: <http://minnie.tuhs.org/pipermail/pups/>
> Date: Wed, 19 Mar 2003 09:46:51 -0800 (PST)
>
> Hi -
>
> > From: David Evans <dfevans at bbcr.uwaterloo.ca>
> > Ugh.
> >
> > Am I naive to suggest a rewrite of as? :)
>
> Just a little bit <g>
>
> It's a thought that used to occur to me fairly often a long time
> ago. I cured myself of it though after I did the rewrite into
> its current form (if you think it's bad now you should have seen it
> before ;)).
>
> The biggest problem are the SDI (Span Dependent Instructions). The
> PDP-11 has 'jmp' (non conditional but no range limit) and 'br' (many
> flavors of conditional branches but with a +/- 128 byte range).
> The compiler generates pseudo instructions like 'jeq' and leaves it
> up to the assembler to figure out if a branch will reach or if a
> branch around a jump is needed. That's a PITA to handle and is
> I believe the cause of much ugliness in the assembler.
That, of course, is a _neat feature_ of AS. On the other hand, how
much code bloat would result if AS always emitted (bne;jmp) pairs for
'jeq', etc. Maybe only generate (bne;jmp) for forward 'jeq' where the
span is not yet known. I am sure there are pathological instabilities
in this kind of code generation, where expanding one branch/jump
instruction makes another one go out of span range.
Answer: 3:1 for each unnecessary pair. But I have no idea of the
statistics for real code.
carl
--
carl lowenstein marine physical lab u.c. san diego
clowenst at ucsd.edu
^ permalink raw reply [flat|nested] 8+ messages in thread
* [pups] 2.11BSD "make unix" aborts Error 141
@ 2003-03-19 17:59 Steven M. Schultz
2003-03-19 21:26 ` Warren Toomey
0 siblings, 1 reply; 8+ messages in thread
From: Steven M. Schultz @ 2003-03-19 17:59 UTC (permalink / raw)
Hi -
> From: norman at nose.cs.utoronto.ca (Norman Wilson)
> 0141 (octal) is 'a. 141 decimal is 0215 octal, i.e. carriage return with
> parity.
And I remembered that (correctly as it turns out) without looking
at ascii(7) <g>
> What seems more likely is that 141 decimal is 0200 + 13 decimal. If a
> simple value returned by wait, that means SIGPIPE + core image, which
> seems unlikely. If an exit status as displayed by the shell, it just
It's, if I recall, being displayed by 'make'. There's no coredump
so the interpretation of 0141 is that of an exit status. It's been
a while since I've looked into the problem - it was quite annoying
to run the sequence (that was causing make to cease) manually and not
have it happen the same way.
a 'shell'
> means SIGPIPE (128 + signal number). Or is signal 13 different in 2.11
> than in V7? (That seems even less likely.)
Ah, ok - that makes sense too. No, SIGPIPE is the same as it's always
been since it was first defined as 13
> SIGPIPE doesn't seem entirely unreasonable as an accident that could
> happen if something goes wrong in the assembly-language-code-tweaking
> part of the kernel build.
But something is causing the assembler to exit prematurely and break
the pipe in the first place.
SIGPIPE happens, of course, when a writer process writes to a pipe
where the receiving/reading process has exited. 'as' is exiting
prematurely - that can be determined by looking at the partially
created (or empty) .s file that gets left behind.
> Of course if it's a random value handed to sys exit, all rules are off.
What might be needed is a decent (or existent ;)) syscall tracing
capability. That combined with the capability to "coredump a non-0
exit process) might be enough to track down what's causing 'as'
to depart the scene prematurely.
Cheers,
Steven Schultz
^ permalink raw reply [flat|nested] 8+ messages in thread
* [pups] 2.11BSD "make unix" aborts Error 141
@ 2003-03-19 17:46 Steven M. Schultz
0 siblings, 0 replies; 8+ messages in thread
From: Steven M. Schultz @ 2003-03-19 17:46 UTC (permalink / raw)
Hi -
> From: David Evans <dfevans at bbcr.uwaterloo.ca>
> Ugh.
>
> Am I naive to suggest a rewrite of as? :)
Just a little bit <g>
It's a thought that used to occur to me fairly often a long time
ago. I cured myself of it though after I did the rewrite into
its current form (if you think it's bad now you should have seen it
before ;)).
The biggest problem are the SDI (Span Dependent Instructions). The
PDP-11 has 'jmp' (non conditional but no range limit) and 'br' (many
flavors of conditional branches but with a +/- 128 byte range).
The compiler generates pseudo instructions like 'jeq' and leaves it
up to the assembler to figure out if a branch will reach or if a
branch around a jump is needed. That's a PITA to handle and is
I believe the cause of much ugliness in the assembler.
So I'm fought the urge to rewrite the assembler and 'won' - I no longer
feel the rewrite urges ;)
Cheers,
Steven Schultz
^ permalink raw reply [flat|nested] 8+ messages in thread
* [pups] 2.11BSD "make unix" aborts Error 141
2003-03-19 16:29 Steven M. Schultz
@ 2003-03-19 16:38 ` David Evans
0 siblings, 0 replies; 8+ messages in thread
From: David Evans @ 2003-03-19 16:38 UTC (permalink / raw)
On Wed, Mar 19, 2003 at 08:29:34AM -0800, Steven M. Schultz wrote:
> It's the exit status of the assembler. On _some_ modules, the
> assembler ('as') jumps off into the weeds and executes an 'exit'
> system call with a non-zero value in R0. 141 is a lower case 'a'
> as I recall.
>
Ugh.
Am I naive to suggest a rewrite of as? :)
--
David Evans (NeXTMail/MIME OK) dfevans at bbcr.uwaterloo.ca
Ph.D. Candidate, Computer/Synth Junkie http://bbcr.uwaterloo.ca/~dfevans/
University of Waterloo "Default is the value selected by the composer
Ontario, Canada overridden by your command." - Roland TR-707 Manual
^ permalink raw reply [flat|nested] 8+ messages in thread
* [pups] 2.11BSD "make unix" aborts Error 141
@ 2003-03-19 16:29 Steven M. Schultz
2003-03-19 16:38 ` David Evans
0 siblings, 1 reply; 8+ messages in thread
From: Steven M. Schultz @ 2003-03-19 16:29 UTC (permalink / raw)
Hi -
> From: "Jonathan Engdahl" <j.r.engdahl at adelphia.net>
> I'm running essentially the CURLY 2.11BSD system with networking on a
Ah, yes - the 'master reference 2.11BSD system' ('SHEMP' is a virtual
pdp-11 running under P11 ;)).
> PDP-11/53. When I go to rebuild unix with "make all", the build will run for
> a while, then quit with "Error 141". If I type "make all" again, it keeps on
Yep, I've been seeing that for years and aside from some kernel
hackery to assist in the debugging I haven't done much other than
to come up with a workaround.
> going for a while. After several iterations of this, eventually the make
> completes, and the system will boot the result. What is this "Error 141"
> business?
It's the exit status of the assembler. On _some_ modules, the
assembler ('as') jumps off into the weeds and executes an 'exit'
system call with a non-zero value in R0. 141 is a lower case 'a'
as I recall.
Now for the interesting part. If you do something like
setenv FOOBAR abcdef
and run the make the assembler won't "exit 'a". ALSO, if you run
the pipeline of the failing command manually, using temp files, it
won't fail. Makes it very hard to debug.
> I've not looked for the cause of this yet. I'm being lazy, and hoping
> someone has seen this before and can give me a quick answer, before I go
I'm lazy too (I hear that being lazy is a virtue in programmers ;))
so I just pad the environment with "FOO abc" or something and the
make works.
The only idea I've come up with to try and track the problem down
is a hack to the 'exit' logic in the kernel to create a coredump
of a program that exits with 'non-zero' status. Then at least
there'd be something to postmortem. An added complication is that
the assembler has this nasty habit of using 'jmp' to move around
rather than 'jsr' so it's hard to find out where the program was
at times. A long time ago I did make a few changes to 'as' to reduce
the usage of 'jmp' in an attempt to track this down but then, when
even I ran the program under the debugger it never failed - a typical
Heisenberg type of bug ;(
Good Luck.
Steven Schultz
^ permalink raw reply [flat|nested] 8+ messages in thread
* [pups] 2.11BSD "make unix" aborts Error 141
2003-03-17 16:38 [pups] 2BSD build problem - unix.o not too big Steven M. Schultz
@ 2003-03-19 2:24 ` Jonathan Engdahl
0 siblings, 0 replies; 8+ messages in thread
From: Jonathan Engdahl @ 2003-03-19 2:24 UTC (permalink / raw)
I'm running essentially the CURLY 2.11BSD system with networking on a
PDP-11/53. When I go to rebuild unix with "make all", the build will run for
a while, then quit with "Error 141". If I type "make all" again, it keeps on
going for a while. After several iterations of this, eventually the make
completes, and the system will boot the result. What is this "Error 141"
business?
I've not looked for the cause of this yet. I'm being lazy, and hoping
someone has seen this before and can give me a quick answer, before I go
digging.
--
Jonathan Engdahl
http://users.safeaccess.com/engdahl
"The things which are seen are temporary,
but the things which are not seen are eternal." II Cor. 4:18
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2003-03-19 21:26 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-03-19 16:52 [pups] 2.11BSD "make unix" aborts Error 141 Norman Wilson
-- strict thread matches above, loose matches on Subject: below --
2003-03-19 18:58 Carl Lowenstein
2003-03-19 17:59 Steven M. Schultz
2003-03-19 21:26 ` Warren Toomey
2003-03-19 17:46 Steven M. Schultz
2003-03-19 16:29 Steven M. Schultz
2003-03-19 16:38 ` David Evans
2003-03-17 16:38 [pups] 2BSD build problem - unix.o not too big Steven M. Schultz
2003-03-19 2:24 ` [pups] 2.11BSD "make unix" aborts Error 141 Jonathan Engdahl
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).