virtual memory question
Should I be able to recover the physical address of a memory region allocated by configmalloc in a kernel module and mapped to a virtual address by a user application? Dr ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Process virtual memory question
Although the 4.4 BSD design and implementation book says the text part of a process starts from 0x,, it actually starts from some place around 0x800, (or 0x8048000 to be exact). What's in the area between 0 - 0x800,? Why do we not use it if it is left empty as shown by /proc/pid/map? How is the magic number 0x8048000 determined? Thanks. -Zhihui To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Process virtual memory question
In article Pine.SOL.4.21.010008490.22923-10@jade, Zhiui Zhang [EMAIL PROTECTED] wrote: Although the 4.4 BSD design and implementation book says the text part of a process starts from 0x,, it actually starts from some place around 0x800, (or 0x8048000 to be exact). What's in the area between 0 - 0x800,? Why do we not use it if it is left empty as shown by /proc/pid/map? How is the magic number 0x8048000 determined? Thanks. Processes used to be mapped at address 0 when we used the a.out object file format. We changed the starting address to 0x8048000 when we switched to the ELF format. That magic address came from SVR4, the first system to use ELF. I am not 100% sure why the SVR4 developers chose that address. I think it may have been so that they could map libc and the dynamic linker at the fixed address 0, thereby avoiding the need to do any run-time relocations on them. In any case, all ELF-based systems on the x86 architecture seem to use this same address. On other architecutures such as the Alpha it is entirely different, of course. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Process virtual memory question
Thanks. It just occurs to me that Linux kernel used to have something like this in routine BUG(): * ((char *) 0) = 0; It is called when there is a kernel bug. So address 0 should not be mapped writable, otherwise all C statements " char * p = NULL; * p = value; " would be legal. The book "Unix Internals - A Practical Approach" by S.D. Pate has a figure showing in ELF format, the stack lies BELOW the code segment and grows downwards. This might have something to do with code starting from 0x8048000. -Zhihui On Thu, 11 Jan 2001, John Polstra wrote: In article Pine.SOL.4.21.010008490.22923-10@jade, Zhiui Zhang [EMAIL PROTECTED] wrote: Although the 4.4 BSD design and implementation book says the text part of a process starts from 0x,, it actually starts from some place around 0x800, (or 0x8048000 to be exact). What's in the area between 0 - 0x800,? Why do we not use it if it is left empty as shown by /proc/pid/map? How is the magic number 0x8048000 determined? Thanks. Processes used to be mapped at address 0 when we used the a.out object file format. We changed the starting address to 0x8048000 when we switched to the ELF format. That magic address came from SVR4, the first system to use ELF. I am not 100% sure why the SVR4 developers chose that address. I think it may have been so that they could map libc and the dynamic linker at the fixed address 0, thereby avoiding the need to do any run-time relocations on them. In any case, all ELF-based systems on the x86 architecture seem to use this same address. On other architecutures such as the Alpha it is entirely different, of course. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Process virtual memory question
In article Pine.SOL.4.21.010352290.24593-10@jade, Zhiui Zhang [EMAIL PROTECTED] wrote: Thanks. It just occurs to me that Linux kernel used to have something like this in routine BUG(): * ((char *) 0) = 0; It is called when there is a kernel bug. So address 0 should not be mapped writable, otherwise all C statements " char * p = NULL; * p = value; " would be legal. Right. Address 0 is not mapped writable in FreeBSD. The book "Unix Internals - A Practical Approach" by S.D. Pate has a figure showing in ELF format, the stack lies BELOW the code segment and grows downwards. This might have something to do with code starting from 0x8048000. Yes, I think you are right, now that my memory is returning. :-) In SVR4 the stack grew downwards from 0x800. I think that libc and the dynamic linker (all together in one shared library) were mapped between 0x800 and 0x8048000. But that is just a guess. Most modern libcs wouldn't fit in that amount of space these days. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Process virtual memory question
Thanks. It just occurs to me that Linux kernel used to have something like this in routine BUG(): * ((char *) 0) = 0; It is called when there is a kernel bug. So address 0 should not be mapped writable, otherwise all C statements " char * p = NULL; * p = value; " would be legal. The book "Unix Internals - A Practical Approach" by S.D. Pate has a figure showing in ELF format, the stack lies BELOW the code segment and grows downwards. This might have something to do with code starting from 0x8048000. Also remember that for CPUs with virtually indexed caches, base addresses for text, data, and stack matter a great deal. Perhaps this is a remanence? For reference, see: "UNIX Systems for Modern Architectures" by Curt Schimmel, chapter 7. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
