Date: Sat, 28 Nov 1998 17:33:36 -0800 (PST) From: John Polstra <jdp@polstra.com> To: wolman@cs.washington.edu Cc: current@FreeBSD.ORG Subject: Re: MAXDSIZ limit Message-ID: <199811290133.RAA27144@vashon.polstra.com> In-Reply-To: <199811282349.PAA16757@miles.cs.washington.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <199811282349.PAA16757@miles.cs.washington.edu>,
Alec Wolman <wolman@cs.washington.edu> wrote:
>
> Hello,
>
> I'm running FreeBSD 3.0-19981103 SNAP, and I'm running into a problem
> or two. I first tried changing MAXDSIZE in my kernel config file to
>
> MAXDSIZ 2048*1024*1024
>
> This causes numerous compilation warnings, presumably because the
> calculations being done with the number are signed rather than unsigned.
You should have defined MAXDSIZ as something like "2048UL*1024*1024"
^^
to make it explicitly an unsigned long. That's the form that is used
in <machine/vmparam.h>.
> Setting it to 2000*1024*1024 eliminates all of those warnings except
> for one, in imgact_elf.c. I tried booting this kernel, but it dies.
> I don't have the exact error message, but the kernel boots up and
> manages to go through the device configuration, but when it gets to
> execing an elf process things go haywire. I think the error message
> had to do with being unable to start getty.
>
> When I fixed the compiler warning with the following change,
> and I changed MAXDSIZ to 1500*1024*1024, and rebooted, then things
> seemed to work ok. However, I suspect that lowering MAXDSIZ rather
> than fixing the code is what made things better. Does anyone here
> understand why the elf code needs to multiply MAXDSIZ by 2 and then
> use that as a base address for something else? Is anyone with a
> bit more expertise interested in looking into this problem?
The code is loading the dynamic linker at the address 2*MAXDSIZ, which
by default works out to 0x40000000. I don't know why it's being
loaded there. The traditional place for ELF dynamic linkers (in SVR4)
is at 0x08000000, which is "far enough" below the load address for
executables, 0x08048000.
Would you mind trying it with that statement in imgact_elf.c changed
to "addr = 0x08000000"? I'd be interested to know whether it works
OK. If it does, we should probably change it. It would have the nice
advantage that we could count on the dynamic linker being at a fixed
address. We wouldn't have to build it PIC any more, so it would be
faster.
John
--
John Polstra jdp@polstra.com
John D. Polstra & Co., Inc. Seattle, Washington USA
"Nobody ever went broke underestimating the taste of the American public."
-- H. L. Mencken
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199811290133.RAA27144>