[comp.unix.wizards] dumping core on *

vixie@palo-alto.DEC.COM (Paul Vixie) (07/29/88)

In article <11955@ncoast.UUCP> allbery@ncoast.UUCP (Brandon S. Allbery) writes:
# [...] 386 and 680x0 systems, both of which tend to dump core on *(NULL),
# the world's favorite Vax-ism.)

If you map a page there, *(NULL) will find it.  If you don't, you get a page
fault.  If your page fault handler decides it's a bad address, it'll segfault
you.

It all depends on the linker, the loader, and the virtual memory system.

VMS (which runs on VAXes) doesn't put any page at location 0, just to catch
this type of bug.  The VAX/VMS C manual warns in its portability section that
*(NULL) will cause rude things to happen to your program.

Summary: don't blame it on the Vax, blame it on Real 4.3BSD.  We're all sort
of expecting an ld option to appear in 4.4 that makes this an option.  It's
complicated because the kernel need to know about it also, and nobody wants
to allocate another magic number (or another set of them, really) and it's
hard to decide how else to pass the option in to the kernel.  Got any ideas?
-- 
Paul Vixie
Digital Equipment Corporation	Work:  vixie@dec.com	Play:  paul@vixie.UUCP
Western Research Laboratory	 uunet!decwrl!vixie	   uunet!vixie!paul
Palo Alto, California, USA	  +1 415 853 6600	   +1 415 864 7013

guy@gorodish.Sun.COM (Guy Harris) (08/02/88)

> Summary: don't blame it on the Vax, blame it on Real 4.3BSD.  We're all sort
> of expecting an ld option to appear in 4.4 that makes this an option.  It's
> complicated because the kernel need to know about it also, and nobody wants
> to allocate another magic number (or another set of them, really) and it's
> hard to decide how else to pass the option in to the kernel.  Got any ideas?

John Bruner, when he added "-Z" to "ld", added a new magic number for it, I
think; it's like ZMAGIC only it leaves page 0 out of the address space.  I
don't see any horrible problem with adding a new magic number.

vixie@palo-alto.DEC.COM (Paul Vixie) (08/02/88)

In article <62285@sun.uucp> guy@gorodish.Sun.COM (Guy Harris) writes:
# John Bruner, when he added "-Z" to "ld", added a new magic number for it, I
# think; it's like ZMAGIC only it leaves page 0 out of the address space.  I
# don't see any horrible problem with adding a new magic number.

It's a hack, though.

What's needed is a single magic number that says "I'm a binary executable
for architecture Fegan-Elmer Blueblood 20000", and then something much
smarter and more elegant than COFF that says "my segments are XXXXXX, the
first segment has this kind of memory map (with this region demand- paged
(if possible), this region pre-loaded during exec, this region shared and
read-only, this region shared and read-write (!), this one on the roof, this
one in the garden, etc, etc".  A generic solution instead of a
multiplication of magic numbers.  COFF won't do as-is, but it's a step
in the right direction.

The hack will be easier, and can be put in in probably about two hours.  But
I don't want a hack that runs on my own system, I want something that Sun and
DEC and CSRG and Pyramid and MIPS and AT&T will all say "yeah, that's a good
solution" and _all_ use it.  I don't want another BSD-only hack or another
AT&T-only hack.
-- 
Paul Vixie
Digital Equipment Corporation	Work:  vixie@dec.com	Play:  paul@vixie.UUCP
Western Research Laboratory	 uunet!decwrl!vixie	   uunet!vixie!paul
Palo Alto, California, USA	  +1 415 853 6600	   +1 415 864 7013

friedl@vsi.UUCP (Stephen J. Friedl) (08/03/88)

In article <3642@palo-alto.DEC.COM>, vixie@palo-alto.DEC.COM (Paul Vixie) writes:
[discussion on magic numbers here]

> COFF won't do as-is, but it's a step in the right direction.

Unrelated to the original topic, I seem to recall hearing of
a new version of COFF in the works.  Since the dpANS requires
at least 12 levels of ptr/array/fcn declarators and COFF only
provides for six*, I would suspect that somebody is working on
this.  Anybody have any word?

     Steve

[*] - 12-level support in the symbol table is not required for
ANSI conformance, but it is likely that somebody will want SDB
to know how to fully work with one of these programs...

-- 
Steve Friedl    V-Systems, Inc.  +1 714 545 6442    3B2-kind-of-guy
friedl@vsi.com     {backbones}!vsi.com!friedl    attmail!vsi!friedl
--------- Nancy Reagan on flood-control: "Just say Noah"-----------

levy@ttrdc.UUCP (Daniel R. Levy) (08/04/88)

In article <62285@sun.uucp>, guy@gorodish.Sun.COM (Guy Harris) writes:
# > Summary: don't blame it on the Vax, blame it on Real 4.3BSD.  We're all sort
# > of expecting an ld option to appear in 4.4 that makes this an option.  It's
# > complicated because the kernel need to know about it also, and nobody wants
# > to allocate another magic number (or another set of them, really) and it's
# > hard to decide how else to pass the option in to the kernel.  Got any ideas?
# 
# John Bruner, when he added "-Z" to "ld", added a new magic number for it, I
# think; it's like ZMAGIC only it leaves page 0 out of the address space.  I
# don't see any horrible problem with adding a new magic number.

A new magic number is nice 'cause then you could simply convert your existing
executables.  This would save having to recompile stuff, and would let you
check the products of vendors who only provide binary distributions.

Could a system call be added (horrors!) or an existing call modified to
map out page 0 (or for that matter, any arbitrary page you chose)?
-- 
|------------Dan Levy------------|  THE OPINIONS EXPRESSED HEREIN ARE MINE ONLY
| Bell Labs Area 61 (R.I.P., TTY)|  AND ARE NOT TO BE IMPUTED TO AT&T.
|        Skokie, Illinois        | 
|-----Path:  att!ttbcad!levy-----|

guy@gorodish.Sun.COM (Guy Harris) (08/04/88)

> A new magic number is nice 'cause then you could simply convert your existing
> executables.  This would save having to recompile stuff, and would let you
> check the products of vendors who only provide binary distributions.

No, you can't.  The problem is not that implementations of UNIX (or other OSes,
for that matter) on some machines construct an address space with a page full
of uninteresting stuff starting at location 0; the problem is that they put the
first instruction to be executed when running an image at location 0, and put
other objects (code or data) into that page.  If you just patch the magic
number, the program will still start at location 0; however, since there
wouldn't be a location 0, it would bomb out.

Since executables tend to lack relocation bits, you can't just shuffle the
address space of the program up by one page, either; absolute references to
objects in the first page will bomb out.

> Could a system call be added (horrors!) or an existing call modified to
> map out page 0 (or for that matter, any arbitrary page you chose)?

Either of those could be done, but they have the same problem; if the program
wasn't built to run in an address space lacking the first page, it'll die
whenever it references something that legitimately exists within that page.

jack@cwi.nl (Jack Jansen) (08/05/88)

Well, there's a simple hack to get a binary format that doesn't
use a new magic number and will break hardly any existing programs:
Make ld generate ZMAGIC output with the first page full of zeroes. Of
course, this moves crt0.o into page 1 (and thus setting a_entry to
0x400 or something).

Now, the only trick needed is that the kernel recognizes the fact that page
0 is full of zeroes and doesn't map it......
	Jack Jansen, jack@cwi.nl (or jack@mcvax.uucp)
	The shell is my oyster.