In fs/proc/array.c:proc_pid_statm() there is this test block:
if (vma->vm_flags & VM_EXECUTABLE)
trs += pages; /* text */
else if (vma->vm_flags & VM_GROWSDOWN)
drs += pages; /* stack */
else if (vma->vm_end > 0x60000000)
lrs += pages; /* library */
else
drs += pages;
Is there any special reason for the hardcoded constant `0x60000000'?
In the Linux/m68k tree, we use TASK_UNMAPPED_BASE instead. But I don't know
why.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Tue, Oct 31, 2000 at 04:48:11PM +0100, Geert Uytterhoeven wrote:
> In fs/proc/array.c:proc_pid_statm() there is this test block:
>
> if (vma->vm_flags & VM_EXECUTABLE)
> trs += pages; /* text */
> else if (vma->vm_flags & VM_GROWSDOWN)
> drs += pages; /* stack */
> else if (vma->vm_end > 0x60000000)
> lrs += pages; /* library */
> else
> drs += pages;
>
> Is there any special reason for the hardcoded constant `0x60000000'?
> In the Linux/m68k tree, we use TASK_UNMAPPED_BASE instead. But I don't know
> why.
I think this is an old x86 load address for an ELF interpreter. Would
you be happy with ELF_ET_DYN_BASE? I made a fairly small patch that
deals with that.
Cheers,
Bill
William Lee Irwin III <[email protected]> writes:
|> On Tue, Oct 31, 2000 at 04:48:11PM +0100, Geert Uytterhoeven wrote:
|> > In fs/proc/array.c:proc_pid_statm() there is this test block:
|> >
|> > if (vma->vm_flags & VM_EXECUTABLE)
|> > trs += pages; /* text */
|> > else if (vma->vm_flags & VM_GROWSDOWN)
|> > drs += pages; /* stack */
|> > else if (vma->vm_end > 0x60000000)
|> > lrs += pages; /* library */
|> > else
|> > drs += pages;
|> >
|> > Is there any special reason for the hardcoded constant `0x60000000'?
|> > In the Linux/m68k tree, we use TASK_UNMAPPED_BASE instead. But I don't know
|> > why.
|>
|> I think this is an old x86 load address for an ELF interpreter.
No, it is a leftover from the a.out times. IMHO it should be removed
completely. "Library pages" has no meaning for ELF.
Andreas.
--
Andreas Schwab "And now for something
[email protected] completely different."
SuSE Labs, SuSE GmbH, Schanz?ckerstr. 10, D-90443 N?rnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
William Lee Irwin III <[email protected]> writes:
>> I think this is an old x86 load address for an ELF interpreter.
On Fri, Dec 07, 2001 at 09:33:12AM +0100, Andreas Schwab wrote:
> No, it is a leftover from the a.out times. IMHO it should be removed
> completely. "Library pages" has no meaning for ELF.
Enlightening. Are you willing to accept changes to the format?
Some other changes to this function have also been suggested.
I'll follow up with a patch that unconditionally returns 0 for
library pages.
Cheers,
Bill
> No, it is a leftover from the a.out times. IMHO it should be removed
> completely. "Library pages" has no meaning for ELF.
"Library pages" == unmodified execute-only pages mapped from a
file that is not the executable.