Not All Symbols Present in a Loadable Kernel Module
Martes G Wigglesworth
martes at mgwigglesworth.com
Tue May 6 11:56:22 UTC 2008
I thought that the "inline" switch was specific to C++ and C and not
gcc, hence the standard for the language says to add the inline
parameter to explicitly produce optimized code. Unless gcc is not
standard, I don't see why the compiler would automatically optimize the
coded function to "inline."
On Mon, 2008-05-05 at 14:06 -0400, Alexander Sack wrote:
> For my own edification, unless you specifically mark a function
> inline, will gcc really optimize them out? That seems a little
> overboard unless there is some compiler option that says its okay to
> do that. I guess that would be very easy to test if you do as you
> say, just sock away the function address pointer somewhere and you
> should be okay...
> On Mon, May 5, 2008 at 12:32 PM, Kostik Belousov <kostikbel at gmail.com> wrote:
> > On Mon, May 05, 2008 at 09:27:10AM -0700, David Christensen wrote:
> > > > > Yes, I'm building a debug kernel. I have the line listed above as
> > > > well
> > > > > as the following:
> > > > >
> > > > > options KDB
> > > > > options DDB
> > > > > options GDB
> > > > > options INVARIANTS
> > > > > options INVARIANT_SUPPORT
> > > > > options WITNESS
> > > > > options WITNESS_SKIPSPIN
> > > >
> > > > Dave:
> > > >
> > > > What symbols can you not access exactly and how are you
> > > > installing/setting up debugging?
> > > >
> > > > I just built a RELENG_7 with DDB and I'm able to access bce symbols
> > > > without a problem. I can examine them and call them. I'm not using
> > > > options GDB however, only KDB/DDB.
> > > >
> > > > I would:
> > > >
> > > > - Make sure you have the right if_bce.ko/if_bce.ko.symbols files
> > > > generated/installed which contains the debug sections of your ko (from
> > > > the objcopy calls during the build - the binary is stripped with a
> > > > section pointer to the if_bce.ko.symbols file for debugging
> > > > information I believe)
> > > > - If you are using GDB, make sure its pointed to the right source base
> > > > so it can retrieve symbol information correctly
> > > > - If you are using GDB, stub it out and just use DDB to verify that
> > > > your build is sane (it works for me!)
> > > > - If all else fails, you can always build bce statically (just to move
> > > > forward etc.)
> > >
> > > - Enable the kernel debugger as described above
> > > - Build the driver in the /usr/src/sys/modules/bce directory with the
> > > command "make".
> > > - Run the command "nm if_bce.ko | grep dump_stat" in the same directory
> > > with the kernel module just built.
> > >
> > > In my case I only see a symbol for bce_dump_status_block, but there is a
> > > second routine called bce_dump_stats_block. In my working build there
> > > are 23 functions that start with "bce_dump" but only 8 are displayed with
> > > the command "nm if_bce.ko | grep bce_dump". Of course, I also get the
> > > symbol not present error when I try to use any of those missing symbols
> > > through a "call" command in the debugger.
> > Most likely, they are optimized out, gcc likes to inline once-called
> > static functions. Aside from playing with the optimization options,
> > the easiest way seems to use functions somewhere else, e.g., put the
> > addresses into some table. Just guessing.
> freebsd-net at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
More information about the freebsd-net