On Sat, Apr 27, 2013 at 09:14:59PM +0200, Otto Moerbeek wrote: > On Sat, Apr 27, 2013 at 09:09:25PM +0200, Franco Fichtner wrote: > > > On Apr 27, 2013, at 7:36 PM, Ted Unangst <t...@tedunangst.com> wrote: > > > > > On Sat, Apr 27, 2013 at 08:10, Otto Moerbeek wrote: > > >> On Sat, Apr 27, 2013 at 01:08:06AM -0400, Eitan Adler wrote: > > >> > > >>> Adding static to internal function allows the compiler to better > > >>> detect dead code (functions, variables, etc) and makes it easier for > > >>> the compiler to optimize; e.g., since it knows a function will only > > >>> called once it can inline code; or not output a symbol for a certain > > >>> function. > > >> > > >> In general we don't lik this because it makes things harder to debug. > > >> For libraries, yes, but for programs, no. > > > > > > Isn't that rule only for the kernel? ddb can only see global symbols, > > > but gdb should work fine in userland. Certainly I can set breakpoints > > > on static functions, even when compiled without -g. > > > > On backtrace(3) (which is a GNU thing, I know), static functions don't > > show up with their respective names even though they are in the binary. > > That's a tad annoying, but I am not aware of any other limitation. Can > > someone please enlighten me? > > Inlined functions are pretyy confusing in gdb.
So basically we're making the code more difficult to understand because we don't want to spend the one-time effort to move the static "inlinification" from -O2 to -O3... I'm not convinced we should give up that easily ;) It should even be possible to have static functions including breakpoints in the kernel. There is nothing particularly odd about them as long as they are not inlined. There may be more than one with the same name but the address->name mapping is distinct, isn't it? > > -Otto >
