lkml.org 
[lkml]   [2001]   [Dec]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: proc_pid_statm
On Fri, Dec 07, 2001 at 09:38:35AM +0530, BALBIR SINGH wrote:
> I looked at ELF_ET_DYN_BASE and it is defined differently on
> different architectures. For example on an i386, it is defined
> to be 2GB which is 0x80000000.
> On ia64 it is defined as (TASK_UNMAPPED_BASE + 0x1000000).
> I would *dare* suggest that since all shared libraries are
> mmapped, the correct value to compare against in your patch is
> TASK_UNMAPPED_BASE.

Well, it should be different. My analysis was that the libraries
were loaded above the ELF interpreter. I believe your assessment
is more accurate.

On Fri, Dec 07, 2001 at 09:38:35AM +0530, BALBIR SINGH wrote:
> On my i386, the ldd output and looking at /proc/<pid>/maps
> justifies this.
>
> ldd -d /bin/ls
> libtermcap.so.2 => /lib/libtermcap.so.2 (0x4002d000)
> libc.so.6 => /lib/i686/libc.so.6 (0x40031000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
>
>
> ld-linux.so.2 is loaded at TASK_UNMAPPED_BASE. Again, let me
> remind you that I am speculating, so please correct me if u think
> I am wrong.

TASK_UNMAPPED_BASE is what the m68k tree uses as well. I'll roll a
fresh version of the patch using that instead.

Oddly, on i386 the following definitions are used:

include/asm-i386/processor.h:273:#define TASK_UNMAPPED_BASE (TASK_SIZE / 3)
include/asm-i386/elf.h:58:#define ELF_ET_DYN_BASE (TASK_SIZE / 3 * 2)

so only one of us can be correct here, and it appears to be you:

include/asm-i386/processor.h:268:#define TASK_SIZE (PAGE_OFFSET)

and 3*0x40000000 == 0xC0000000 == PAGE_OFFSET

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

\
 
 \ /
  Last update: 2005-03-22 13:18    [W:0.067 / U:2.476 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site