Hello Dmitry, I checked on http://lxr.linux.no/ and found pci_disable_device() is not a macro nor inline function. I mean it does not have inline modifier. But it may be optimized as an inline function because of its size. What optimization you specify? -O0? Good lock and happy debugging. -caz
-----Original Message----- From: Dmitry Mikhin [mailto:[email protected]] Sent: Thursday, April 30, 2009 5:40 AM To: Caz Yokoyama Cc: 'Dmitry Mikhin'; [email protected] Subject: Re: [Kgdb-bugreport] debugging kernel modules with kgdb-light in 2.6.29.1 Sorry, I'm going to vacation till 10th May, I can answer only then. You can try to find it on http://lxr.linux.no/ site. Best Regards, Dmitry. Caz Yokoyama wrote: > Is pci_disable_device(pdev) a macro? Is pci_disable_device(pdev) an inline > function? > -caz > > -----Original Message----- > From: Dmitry Mikhin [mailto:[email protected]] > Sent: Thursday, April 30, 2009 2:31 AM > To: Caz Yokoyama > Cc: [email protected] > Subject: Re: [Kgdb-bugreport] debugging kernel modules with kgdb-light in > 2.6.29.1 > > And another observation about debugging, it seems that 'step' and 'next' > do the same thing with kgdb: > *** > Breakpoint 5, ath_pci_probe (pdev=0xdf8e6c00, id=0xe155f24c) at > /root/dev/madwifi-9999/ath/if_ath_pci.c:230 > 230 pci_disable_device(pdev); > *** > > I don't want to step in pci_disable_device function, I want to pass over > it, so I press 'next' command: > *** > (kgdb) n > pci_disable_device (dev=0xdf8e6c00) at drivers/pci/pci.c:1018 > 1018 { > *** > > but as your see, I'm inside pci_disable_device function. I want to step > out, so I use 'finish' command: > *** > (kgdb) finish > Run till exit from #0 pci_disable_device (dev=0xdf8e6c00) at > drivers/pci/pci.c:1018 > Warning: > Cannot insert breakpoint 0. > Error accessing memory address 0xff6085c7: Unknown error 4294967295. > *** > > but it shows error. Of course I can work without it, using my own > breakpoints, but it is inconvinient. > > Regards, > Dmitry. > > Dmitry Mikhin wrote: > >> Hello, >> >> I solved the problem, it was my mistake. >> In first case breakpoint doesn't work because I haven't executed 'info >> shared'. >> In second case breakpoint doesn't work, because of 'rmmod and modprobe >> again' - >> this operation clears all SW breakpoints hooks on target. >> >> So I inserted sleep operation before ath_attach function: >> *** >> set_current_state(TASK_INTERRUPTIBLE); >> schedule_timeout (15000); >> *** >> During this sleep operation I'm connecting to target, executing info >> shared, and then >> setting breakpoint on ath_attach, and finally it works :) >> >> Regards, >> Dmitry. >> >> Caz Yokoyama wrote: >> >>> Hello Dmitry, >>> Please clarify if you can set a break point after "info shared". It is >>> known >>> that symbol reading is done on "info shared". -caz >>> >>> -----Original Message----- >>> From: Dmitry Mikhin [mailto:[email protected]] Sent: Wednesday, April >>> 29, 2009 9:32 AM >>> To: Mithlesh Thukral >>> Cc: [email protected]; Caz Yokoyama >>> Subject: Re: [Kgdb-bugreport] debugging kernel modules with kgdb-light in >>> 2.6.29.1 >>> >>> Thanks Mithlesh, it helps me. >>> >>> Caz, but after series of experiments I came up to fact, that >>> breakpoints doesn't work in modules :( >>> I do the following: >>> >>> 1. boot up target with no modules loaded >>> 2. connect gdb-kgdblight to target >>> 3. in gdb I'm setting breakpoint: >>> *** >>> (kgdb) b ath_attach >>> Function "ath_attach" not defined. >>> Make breakpoint pending on future shared library load? (y or [n]) y >>> Breakpoint 1 (ath_attach) pending. >>> *** >>> 4. then I'm loading module on target: >>> *** >>> modprobe ath_pci >>> *** >>> and I see printk messages from ath_attach (this function is executed >>> on module load), breakpoint doen't work in this case. >>> 5. then in gdb I do following: >>> *** >>> (kgdb) d >>> Delete all breakpoints? (y or n) y >>> (kgdb) info shared >>> Reading symbols from /root/dev/objs/ath_pci.ko...expanding to full >>> symbols...done. >>> Loaded symbols for /root/dev/objs/ath_pci.ko >>> Reading symbols from /root/dev/objs/ath_rate_ctrl.ko...expanding to >>> full symbols...done. >>> Loaded symbols for /root/dev/objs/ath_rate_ctrl.ko >>> Reading symbols from /root/dev/objs/wlan.ko...expanding to full >>> symbols...done. >>> Loaded symbols for /root/dev/objs/wlan.ko >>> Reading symbols from /root/dev/objs/ath_dfs.ko...expanding to full >>> symbols...done. >>> Loaded symbols for /root/dev/objs/ath_dfs.ko >>> Reading symbols from /root/dev/objs/ath_hal.ko...expanding to full >>> symbols...done. >>> Loaded symbols for /root/dev/objs/ath_hal.ko >>> From To Syms Read Shared Object Library >>> 0xe0766000 0xe07660f4 Yes /root/dev/objs/pcspkr.ko >>> 0xe076b000 0xe076e714 Yes /root/dev/objs/e100.ko >>> 0xe13df000 0xe13ecec0 Yes /root/dev/objs/ath_pci.ko >>> 0xe1236000 0xe1237950 Yes /root/dev/objs/ath_rate_ctrl.ko >>> 0xe1024000 0xe103ea34 Yes /root/dev/objs/wlan.ko >>> 0xe0a17000 0xe0a1ab9c Yes /root/dev/objs/ath_dfs.ko >>> 0xe0934000 0xe0952968 Yes /root/dev/objs/ath_hal.ko >>> (kgdb) b ath_attach >>> Breakpoint 3 at 0xe13e8cb0: file /root/dev/madwifi-9999/ath/if_ath.c, >>> line 426. >>> *** >>> 6. then on target i do rmmod and modprobe again, and even in this case >>> I see printk messages from ath_attach so breakpoint didn't stop code >>> execution what is wrong. >>> >>> Regards, >>> Dmitry. >>> >>> Mithlesh Thukral wrote: >>> >>>> These messages are coming because you turned enabled remote debugging >>>> by : >>>> "set debug remote 1" >>>> >>>> HTH, >>>> Mithlesh Thukral >>>> >>> >> > > > ------------------------------------------------------------------------------ Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf _______________________________________________ Kgdb-bugreport mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
