mounting root
Why does the kernel still tries to mount root from fd0c first when i set options ROOTDEVNAME=\cd9660:acd0\ ? And when fd0c fails, THEN he mounts it from acd0. thx for any help -- www.bsdaemon.be - securax.org - docs.bsdaemon.be keyserver: pgpkeys.mit.edu PGP keyID: DA07EAE9 signature.asc Description: This is a digitally signed message part
-fomit-frame-pointer for the world build
Hello there colleagues, I'd tried to search thru the web, but did not succeed enough. What are the drawbacks of building FreeBSD with -fomit-frame-pointer? As far as I can see, it saves both space (which is not as worth as disk space got cheaper and cheaper) and execution time (which is, AFAICC, more important). I'd already done some tests, but not really deep. Would you please clarify this issue abit, or point me to any articles describing exact -fomit-frame-pointer behaviour? Thank you in advance. Sincerely, D.Marck [DM5020, DM268-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: -fomit-frame-pointer for the world build
Dmitry Morozovsky wrote: What are the drawbacks of building FreeBSD with -fomit-frame-pointer? As far as I can see, it saves both space (which is not as worth as disk space got cheaper and cheaper) and execution time (which is, AFAICC, more important). I'd already done some tests, but not really deep. Would you please clarify this issue abit, or point me to any articles describing exact -fomit-frame-pointer behaviour? The frame pointer is used for debugging, specifically for the stack traceback function to know arguments. Removing it means losing some debugging functionality. Next time try info gcc: `-fomit-frame-pointer' Don't keep the frame pointer in a register for functions that don't need one. This avoids the instructions to save, set up and restore frame pointers; it also makes an extra register available in many functions. *It also makes debugging impossible on some machines.* On some machines, such as the Vax, this flag has no effect, because the standard calling sequence automatically handles the frame pointer and nothing is saved by pretending it doesn't exist. The machine-description macro `FRAME_POINTER_REQUIRED' controls whether a target machine supports this flag. *Note Registers::. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: -fomit-frame-pointer for the world build
On Fri, 2 Aug 2002, Terry Lambert wrote: TL What are the drawbacks of building FreeBSD with -fomit-frame-pointer? As TL far as I can see, it saves both space (which is not as worth as disk space TL got cheaper and cheaper) and execution time (which is, AFAICC, more TL important). TL TL I'd already done some tests, but not really deep. TL TL Would you please clarify this issue abit, or point me to any articles TL describing exact -fomit-frame-pointer behaviour? TL TL The frame pointer is used for debugging, specifically for the TL stack traceback function to know arguments. Removing it means TL losing some debugging functionality. Next time try info gcc: TL TL `-fomit-frame-pointer' TL Don't keep the frame pointer in a register for functions that TL don't need one. This avoids the instructions to save, set up and TL restore frame pointers; it also makes an extra register available TL in many functions. *It also makes debugging impossible on some TL machines.* TL TL On some machines, such as the Vax, this flag has no effect, because TL the standard calling sequence automatically handles the frame TL pointer and nothing is saved by pretending it doesn't exist. The TL machine-description macro `FRAME_POINTER_REQUIRED' controls TL whether a target machine supports this flag. *Note Registers::. Yes, Terry, I'd read this note. However, it does not clarify for me which exactly functionality is lost with omitting this. I tried to build some binaries with -fomit..., then tried to debug it a bit, and gdb shows me both backtrace stack and arguments, so I was in doubt a bit -- so here is my question ;-) Sincerely, D.Marck [DM5020, DM268-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: -fomit-frame-pointer for the world build
Dmitry Morozovsky wrote: [ ... -fomit-frame-pointer ... ] Yes, Terry, I'd read this note. However, it does not clarify for me which exactly functionality is lost with omitting this. I tried to build some binaries with -fomit..., then tried to debug it a bit, and gdb shows me both backtrace stack and arguments, so I was in doubt a bit -- so here is my question ;-) Try it again on a SPARC or other RISC machine that pushes register window frames on the stack after a certain function call depth is achieved. I was pretty sure at one time that the PPC platform had a variant of this problem, as well. If you want a definative answer, then the people to ask are the GCC implementors, who put the option into the compiler for a reason, and added the descriptive text to the .info file in the first place. Realize that this is a GCC issue, not a FreeBSD issue. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Pet Health Plan!
Title: Email This offer is brought to you by the American Pet Plan.com. If you no longer wish to receive offers in the future, please unsubscribe below. If you cannot view this email, please click here: www.americanpetplan.com 1992 Celebrating 10 years of Excellence! 2002 The American Pet Plan can save you hundreds or even thousands of dollars per yearon all your veterinary health care costs!All at very affordable rates!! Veterinarian Recommended!Benefits Include: $5.00 Doctor Visits! $10.00 Comprehensive Medical Exams! Lowest Cost In-Office Vaccinations! Benefits on All other Veterinary Care Rx's! Benefits on Grooming Boarding! Benefits on Pet Sitting Dog Training! Immediate Benefits on Pre-existing Conditions! All Animals Accepted! No Age Limits! Extremely Affordable! And So Much More! VISIT US NOW AT WWW.AMERICANPETPLAN.COM ! This message is never sent unsolicited. You are receiving this message as a member of the American Pet Plan.com or one of our advertising affiliates. If you do not want to receive special offers in the future, please click here: [EMAIL PROTECTED] and type in UNSUBSCRIBE in the subject line. You will be immediately removed. index_header.jpg
Re: -fomit-frame-pointer for the world build
I tried to build some binaries with -fomit..., then tried to debug it a
bit, and gdb shows me both backtrace stack and arguments, so I was in
doubt a bit -- so here is my question ;-)
I can answer that. Consider the following two functions:
f(int n)
{
int x; int y;
... // no calls to other functions, no nested
// declaration of variables
}
g(int n)
{
int x;
int array[n]; // allowed in gcc
int y;
... // no calls to other functions, no nested
// declaration of variables
}
First assume stack grows toward higher addresses. For the
other direction just swap - and + in computing local
var addresses.
Note that when using a frame ptr (also called a dynamic
link in compiler lingo), one generally needs to something
like this:
on entry:
push frame ptr
frame ptr = stack ptr
stack ptr += framesize
just before returning:
stack ptr -= framesize
frame ptr = pop
return
Its caller then removes arguments on the stack.
Now notice that the framesize of f() is a constant! To
address a local variable(or any args), one can either use
frame ptr + offset1,
where offset1 = its distance from the frame ptr,
note that for arg n the distance is -ve.
or use
stack ptr - offset2,
where offset2 = its distance from the stack ptr.
Given that the framesize is constant, we can always compute
where the frame starts from the stack ptr and hence we don't
need the frame ptr. Debugging should also work if the
framesize constant is made known to the debugger -- usually
by storing it just before the generated code for the
function. Consequently you don't need to save and restore
the caller's frame ptr -- hence the time savings.
But if the framesize is not a constant (such as when a
variable sized array is declared as in g()), things get a bit
complicated. If we have a frame ptr as well as a stack ptr,
you can address x as well as y with a constant offset. If
you remove the frame pointer, you need to use the value of n
in computing the offset of x. Further, the debugger may find
it very difficult to locate the framesize (but it can be
done) to unravel the stack. So you may or may not see any
time savings.
Note that there are tricks to making the framesize constant
even when there are variables declared in nested blocks.
This is done by hoisting the vars to the function level.
My view is that -fomit-frame-pointer is almost always worth
it provided gdb is smart enough to locate all the frames.
If this is not clear enough, try drawing a picture of how
the frames are popped and pushed on a stack as well as stare
the generated code until you 'get it'!
-- bakul
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
very minor vm_map.c typo ?
Hello, In vm_map.c, in the vm_map_insert(...) function there is the following piece of code which checks if the addresses supplied to the function are valid: ** if ((start map-min_offset) || (end map-max_offset) || (start = end)) return (KERN_INVALID_ADDRESS); ** Specifically, I am interested in the final comparison. Is it possible that start == end could ever be correct? Do zero sized entries ever get inserted? (I don't see why you would ever wish to do this, please explain it to me if there is a reason). Normally I'd submit a PR about this but since its not an area of the code I am very familiar with I thought I'd ask. I would also supply a patch but for a one character change it seems pretty silly. Thanks, -- Dominic To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: very minor vm_map.c typo ?
Dominic Marks wrote: Hello, In vm_map.c, in the vm_map_insert(...) function there is the following piece of code which checks if the addresses supplied to the function are valid: ** if ((start map-min_offset) || (end map-max_offset) || (start = end)) return (KERN_INVALID_ADDRESS); ** Specifically, I am interested in the final comparison. Is it possible that start == end could ever be correct? Do zero sized entries ever get inserted? (I don't see why you would ever wish to do this, please explain it to me if there is a reason). That would most likely be a case of defensive programming, especially in case of a sign wraparound problem or the like. No, inserting a zero-length map entry isn't valid and the defensive case comes for free. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
