All of lore.kernel.org
 help / color / mirror / Atom feed
* vma->vm_end > 0x60000000
@ 2000-10-31 15:48 Geert Uytterhoeven
  2001-12-07  3:17 ` William Lee Irwin III
  0 siblings, 1 reply; 5+ messages in thread
From: Geert Uytterhoeven @ 2000-10-31 15:48 UTC (permalink / raw)
  To: Linux Kernel Development; +Cc: Linux/m68k


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 -- geert@linux-m68k.org

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

* Re: vma->vm_end > 0x60000000
  2000-10-31 15:48 vma->vm_end > 0x60000000 Geert Uytterhoeven
@ 2001-12-07  3:17 ` William Lee Irwin III
  2001-12-07  8:33   ` Andreas Schwab
  0 siblings, 1 reply; 5+ messages in thread
From: William Lee Irwin III @ 2001-12-07  3:17 UTC (permalink / raw)
  To: Geert Uytterhoeven; +Cc: Linux Kernel Development, Linux/m68k

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

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

* Re: vma->vm_end > 0x60000000
  2001-12-07  3:17 ` William Lee Irwin III
@ 2001-12-07  8:33   ` Andreas Schwab
  2001-12-07  8:47     ` William Lee Irwin III
  2001-12-07 20:16     ` Albert D. Cahalan
  0 siblings, 2 replies; 5+ messages in thread
From: Andreas Schwab @ 2001-12-07  8:33 UTC (permalink / raw)
  To: William Lee Irwin III
  Cc: Geert Uytterhoeven, Linux Kernel Development, Linux/m68k

William Lee Irwin III <wli@holomorphy.com> 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
Andreas.Schwab@suse.de				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

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

* Re: vma->vm_end > 0x60000000
  2001-12-07  8:33   ` Andreas Schwab
@ 2001-12-07  8:47     ` William Lee Irwin III
  2001-12-07 20:16     ` Albert D. Cahalan
  1 sibling, 0 replies; 5+ messages in thread
From: William Lee Irwin III @ 2001-12-07  8:47 UTC (permalink / raw)
  To: Linux Kernel Development

William Lee Irwin III <wli@holomorphy.com> 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



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

* Re: vma->vm_end > 0x60000000
  2001-12-07  8:33   ` Andreas Schwab
  2001-12-07  8:47     ` William Lee Irwin III
@ 2001-12-07 20:16     ` Albert D. Cahalan
  1 sibling, 0 replies; 5+ messages in thread
From: Albert D. Cahalan @ 2001-12-07 20:16 UTC (permalink / raw)
  To: Andreas Schwab
  Cc: William Lee Irwin III, Geert Uytterhoeven,
	Linux Kernel Development, Linux/m68k

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

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

end of thread, other threads:[~2001-12-07 20:16 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-10-31 15:48 vma->vm_end > 0x60000000 Geert Uytterhoeven
2001-12-07  3:17 ` William Lee Irwin III
2001-12-07  8:33   ` Andreas Schwab
2001-12-07  8:47     ` William Lee Irwin III
2001-12-07 20:16     ` Albert D. Cahalan

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.