1. 08 Jun, 2004 3 commits
  2. 04 Jun, 2004 5 commits
    • Greg Kroah-Hartman's avatar
    • Jonathan Corbet's avatar
      [PATCH] Module section offsets in /sys/module · 3f7b0672
      Jonathan Corbet authored
      So here I am trying to write about how one can apply gdb to a running
      kernel, and I'd like to tell people how to debug loadable modules.  Only
      with the 2.6 module loader, there's no way to find out where the various
      sections in the module image ended up, so you can't do much.  This patch
      attempts to fix that by adding a "sections" subdirectory to every module's
      entry in /sys/module; each attribute in that directory associates a
      beginning address with the section name.  Those attributes can be used by a
      a simple script to generate an add-symbol-file command for gdb, something
      like:
      
      #!/bin/bash
      #
      # gdbline module image
      #
      # Outputs an add-symbol-file line suitable for pasting into gdb to examine
      # a loaded module.
      #
      cd /sys/module/$1/sections
      echo -n add-symbol-file $2 `/bin/cat .text`
      
      for section in .[a-z]* *; do
          if [ $section != ".text" ]; then
      	echo  " \\"
      	echo -n "	-s" $section `/bin/cat $section`
          fi
      done
      echo
      
      Currently, this feature is absent if CONFIG_KALLSYMS is not set.  I do
      wonder if CONFIG_DEBUG_INFO might not be a better choice, now that I think
      about it.  Section names are unmunged, so "ls -a" is needed to see most of
      them.
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      3f7b0672
    • Frank A. Uepping's avatar
      [PATCH] Driver Core: fix struct device::release issue · 1248a637
      Frank A. Uepping authored
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      
      
      On Saturday 27 March 2004 02:14, Greg KH wrote:
      > On Sat, Mar 06, 2004 at 12:47:24PM +0100, Frank A. Uepping wrote:
      > > Hi,
      > > if device_add fails (e.g. bus_add_device returns an error) then the release
      > > method will be called for the device. Is this a bug or a feature?
      >
      > Are you sure this will happen?  device_initialize() gets a reference
      > that is still present after device_add() fails, right?  So release()
      > will not get called.
      At the label PMError, kobject_unregister is called, which decrements the
      recount by 2, which will result in calling release at label Done (put_device).
      
      kobject_unregister should be superseded by kobject_del.
      Here is a patch:
      1248a637
    • Greg Kroah-Hartman's avatar
    • Greg Kroah-Hartman's avatar
  3. 03 Jun, 2004 32 commits