Multiple breakpoint issue when debugging loadable kernel module

Multiple breakpoint issue when debugging loadable kernel module

[Vimal]

Hi,

I have a loadable kernel module, and I am facing issues when setting
breakpoints.

I am using gdb 7.3.1 from ftp://ftp.gnu.org/gnu/gdb.

1. I start the kernel under qemu-kvm and load the kernel module.  The
kernel module was compiled with CFLAGS=-O0 -g

2. I generate the add-symbol-path command by using section address
information from /sys/module/$mod/sections/.*

3. I enter the add-symbol-path command into gdb, which is connected to
qemu's gdb stub via "target remote" command.

4. After loading the symbols, I do: "info line function" and am able
to see the function name's line number.   Also, "list function" shows
the source code from the correct file.

5. I do "break function", I see this message:
    Breakpoint 1 at address (2 locations)

After the last step, if I run "info line function", I see "No line
number information available for address..."

When I type "info break", I see the two breakpoints inserted at
"function+4" and "function+31".

This error does not happen in gdb-7.1.   The reason I am using
gdb-7.3.1 is that I want to use gdb.Breakpoint from a python script.

Is there a way to fix this error?   Why are two breakpoints being set?
  This error happens across a few kernel modules that I tested.

Thanks,
-- 
Vimal

Re: Multiple breakpoint issue when debugging loadable kernel module

[Vimal]

Just to add:  the error also happens with

    gdb-7.3.50.20111023

Thanks,
-- 
Vimal

Re: Multiple breakpoint issue when debugging loadable kernel module

[Vimal]

Hi,

With some suggestions from IRC folks sergiodj and SamB, I ran a git
bisect on the HEAD of git://sourceware.org/git/gdb.git.

It seems like the first bad commit is:
2cdbbe44126601596aad7891de05cb7fc6bb21c8, which seems pretty big
~6000lines.

Quoted below is my first mail to the list, with few details about the
problem.  Also, here's an output from an actual run:
http://pastebin.com/4PhDAHwW...

Tom Tromey: is this a known issue?

Thanks,
--
Vimal


On 23 October 2011 20:16, Vimal <j.vimal@gmail.com> wrote:
> Hi,
>
> I have a loadable kernel module, and I am facing issues when setting
> breakpoints.
>
> I am using gdb 7.3.1 from ftp://ftp.gnu.org/gnu/gdb.
>
> 1. I start the kernel under qemu-kvm and load the kernel module.  The
> kernel module was compiled with CFLAGS=-O0 -g
>
> 2. I generate the add-symbol-path command by using section address
> information from /sys/module/$mod/sections/.*
>
> 3. I enter the add-symbol-path command into gdb, which is connected to
> qemu's gdb stub via "target remote" command.
>
> 4. After loading the symbols, I do: "info line function" and am able
> to see the function name's line number.   Also, "list function" shows
> the source code from the correct file.
>
> 5. I do "break function", I see this message:
>    Breakpoint 1 at address (2 locations)
>
> After the last step, if I run "info line function", I see "No line
> number information available for address..."
>
> When I type "info break", I see the two breakpoints inserted at
> "function+4" and "function+31".
>
> This error does not happen in gdb-7.1.   The reason I am using
> gdb-7.3.1 is that I want to use gdb.Breakpoint from a python script.
>
> Is there a way to fix this error?   Why are two breakpoints being set?
>  This error happens across a few kernel modules that I tested.
>
> Thanks,
> --
> Vimal
>



-- 
Vimal

Re: Multiple breakpoint issue when debugging loadable kernel module

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1124 bytes --]

On 2011-10-25 04:57, Vimal wrote:
> Hi,
> 
> With some suggestions from IRC folks sergiodj and SamB, I ran a git
> bisect on the HEAD of git://sourceware.org/git/gdb.git.
> 
> It seems like the first bad commit is:
> 2cdbbe44126601596aad7891de05cb7fc6bb21c8, which seems pretty big
> ~6000lines.

Wow, that saved me a lot of time. I just ran into the same issue and was
close to getting mad over the effect.

Maybe the commit is only that big because cvs-to-git conversion merged
too much into a single commit. I can't imagine that such a huge change
is done in one step.

> 
> Quoted below is my first mail to the list, with few details about the
> problem.  Also, here's an output from an actual run:
> http://pastebin.com/4PhDAHwW...
> 
> Tom Tromey: is this a known issue?

At least it is a critical one as it makes kernel module debugging nearly
impossible. I'm preparing a LinuxCon talk about how cool kernel
debugging with gdb and qemu can be - looks like I have to skip this
part... ;)

If there is anything to be done that could help analyzing the issue,
please let us know.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: Multiple breakpoint issue when debugging loadable kernel module

[Vimal]

Hi Jan,

Well, I am glad that the bug is reproduced by someone else. :)

On 26 October 2011 17:10, Jan Kiszka <jan.kiszka@web.de> wrote:
>
> Maybe the commit is only that big because cvs-to-git conversion merged
> too much into a single commit. I can't imagine that such a huge change
> is done in one step.
>

Could be, but it points to a bunch of commits that could be a potential problem.

>
> At least it is a critical one as it makes kernel module debugging nearly
> impossible. I'm preparing a LinuxCon talk about how cool kernel
> debugging with gdb and qemu can be - looks like I have to skip this
> part... ;)

Maybe you can use gdb version before that particular commit?

I've filed a bug report, which lists some variants of the bug:
http://sourceware.org/bugzilla/show_bug.cgi?id=13346

Thanks,
-- 
Vimal

Re: Multiple breakpoint issue when debugging loadable kernel module

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1098 bytes --]

On 2011-10-27 02:22, Vimal wrote:
> Hi Jan,
> 
> Well, I am glad that the bug is reproduced by someone else. :)
> 
> On 26 October 2011 17:10, Jan Kiszka <jan.kiszka@web.de> wrote:
>>
>> Maybe the commit is only that big because cvs-to-git conversion merged
>> too much into a single commit. I can't imagine that such a huge change
>> is done in one step.
>>
> 
> Could be, but it points to a bunch of commits that could be a potential problem.
> 
>>
>> At least it is a critical one as it makes kernel module debugging nearly
>> impossible. I'm preparing a LinuxCon talk about how cool kernel
>> debugging with gdb and qemu can be - looks like I have to skip this
>> part... ;)
> 
> Maybe you can use gdb version before that particular commit?

That's what I'm doing right now, but I'd like to use [1] and maybe write
some more helpers. :)

> 
> I've filed a bug report, which lists some variants of the bug:
> http://sourceware.org/bugzilla/show_bug.cgi?id=13346

Thanks, will have an eye on it.

Jan

[1] http://permalink.gmane.org/gmane.comp.gdb.devel/25898


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: Multiple breakpoint issue when debugging loadable kernel module

[Vimal]

On 27 October 2011 01:10, Jan Kiszka <jan.kiszka@web.de> wrote:
>
> That's what I'm doing right now, but I'd like to use [1] and maybe write
> some more helpers. :)

Jan,

I have written a script for listing loaded modules as well and it is
possible with the gdb version 7.1, just before the faulty commit.

I am not sure if gdb.selected_frame() is available, but, since
"modules" is a global variable, you could just use parse_and_eval.
That should work. :)

Good luck on your presentation!

-- 
Vimal

Re: Multiple breakpoint issue when debugging loadable kernel module

[Jan Kiszka]

On 2011-10-27 16:47, Vimal wrote:
> On 27 October 2011 01:10, Jan Kiszka <jan.kiszka@web.de> wrote:
>>
>> That's what I'm doing right now, but I'd like to use [1] and maybe write
>> some more helpers. :)
> 
> Jan,
> 
> I have written a script for listing loaded modules as well and it is
> possible with the gdb version 7.1, just before the faulty commit.
> 
> I am not sure if gdb.selected_frame() is available, but, since
> "modules" is a global variable, you could just use parse_and_eval.
> That should work. :)

Yeah, I just had to hack that version to accept python 2.7 - all
features there, and my script works as-is.

> 
> Good luck on your presentation!
> 

Thanks!
Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: Multiple breakpoint issue when debugging loadable kernel module

[Tom Tromey]

>>>>> "Jan" == Jan Kiszka <jan.kiszka@web.de> writes:

Jan> At least it is a critical one as it makes kernel module debugging nearly
Jan> impossible. I'm preparing a LinuxCon talk about how cool kernel
Jan> debugging with gdb and qemu can be - looks like I have to skip this
Jan> part... ;)

Well, we can't let that happen.

Jan> If there is anything to be done that could help analyzing the issue,
Jan> please let us know.

A recipe to reproduce the bug.  I know nothing about the kernel, so if
it requires extensive setup, precise instructions would be best.

We've been poking at it a bit on irc but, aside from a lot of weird and
inexplicable gdb behavior, we haven't seen anything too useful.

Tom

Re: Multiple breakpoint issue when debugging loadable kernel module

[Tom Tromey]

>>>>> "Jan" == Jan Kiszka <jan.kiszka@web.de> writes:

Jan> [1] http://permalink.gmane.org/gmane.comp.gdb.devel/25898

Nice.

To answer your question there:

Jan> (does someone know how to switch of the add-symbol-file output?)

From Python you can to gdb.execute(..., to_string = True).
I forget when we added this parameter.

From the CLI you can use the 'set logging' family of commands to
temporarily disable output.


From the code:

def offset_of(type, field):
	return gdb.parse_and_eval('(unsigned long)&( (' + str(type) + ' *)0)->' + str(field))

You can look up the field in the type and get the offset more directly.
But this works too.

Tom

Re: Multiple breakpoint issue when debugging loadable kernel module

[Vimal]

On 27 October 2011 13:31, Tom Tromey <tromey@redhat.com> wrote:
>
> A recipe to reproduce the bug.  I know nothing about the kernel, so if
> it requires extensive setup, precise instructions would be best.
>
> We've been poking at it a bit on irc but, aside from a lot of weird and
> inexplicable gdb behavior, we haven't seen anything too useful.

I was poking around the gdb-7.3 code from your branch and noticed the
following behaviour:

As you suggested, I set breakpoint at decode_variable.  Then, followed
some function calls to see the function that's returning the sal.
Turns out it's this function: find_pc_sect_line.  So, in that
function, I introduced some print statements and noticed the
following:

1. info scope function, before setting a breakpoint, prints the following:

(gdb) info scope vport_receive
exploring s=0x20fb810
filename=/home/nikhilh/openvswitch/datapath/linux/vport.c
section=0x1cff988, pc=0xffffffffa00d5ba3
best_symtab: 0x20fb810, in
filename=/home/nikhilh/openvswitch/datapath/linux/vport.c
found best_symtab 0x20fb810
exploring s=0x20fb810
filename=/home/nikhilh/openvswitch/datapath/linux/vport.c
section=(nil), pc=0xffffffffa00d5ba3
best_symtab: 0x20fb810, in
filename=/home/nikhilh/openvswitch/datapath/linux/vport.c
found best_symtab 0x20fb810
exploring s=0x20fb810
filename=/home/nikhilh/openvswitch/datapath/linux/vport.c
section=0x1cff988, pc=0xffffffffa00d5ba7
best_symtab: 0x20fb810, in
filename=/home/nikhilh/openvswitch/datapath/linux/vport.c
found best_symtab 0x20fb810
exploring s=0x20fb810
filename=/home/nikhilh/openvswitch/datapath/linux/vport.c
section=0x1cff988, pc=0xffffffffa00d5bb8
best_symtab: 0x20fb810, in
filename=/home/nikhilh/openvswitch/datapath/linux/vport.c
found best_symtab 0x20fb810
[Prints the correct scope information]

Here's the portion I made change in the gdb/symtab.c:find_pc_sect_line(..)

   printf("exploring s=%p filename=%s section=%p, pc=%p\n", s,
s?s->filename:NULL, section, (void*)pc);
   ALL_OBJFILE_SYMTABS (objfile, s) { ...

The variable 's' is obtained via find_pc_sect_symtab().

When I set a breakpoint for the same function vport_receive, I see the
same output as above.

But, after setting a breakpoint, when I do "info scope vport_receive",
I see this:

(gdb) info scope vport_receive
exploring s=0x2294cc0 filename=arch/x86/kernel/hpet.c
section=0x1cff988, pc=0xffffffffa00d5ba3
count't find best_symtab :(, s=(nil), filename=(null)
exploring s=0x2294cc0 filename=arch/x86/kernel/hpet.c section=(nil),
pc=0xffffffffa00d5ba3
count't find best_symtab :(, s=(nil), filename=(null)
exploring s=0x2294cc0 filename=arch/x86/kernel/hpet.c
section=0x1cff988, pc=0xffffffffa00d5ba7
count't find best_symtab :(, s=(nil), filename=(null)

Notice that the 's' variable has changed!  section and pc variables
haven't.   It's looking for the function vport_receive in a
_different_ file; I don't understand why! :(   It seems like
find_pc_sect_symtab() is the culprit.   Let me step through that
function and see what the problem is....

Thanks,
-- 
Vimal

Re: Multiple breakpoint issue when debugging loadable kernel module

[Vimal]

Some more info.  This looks interesting.

1. find_pc_sect_symtab has changed quite a bit between the faulty
commit noted above (sha 2cdbbe44) and its parent (2cdbbe44^)!

2. Since the module is loaded into the kernel address space,
find_pc_sect_symtab seems to think the vmlinux module's symbol table
has symbol information for the function I am breaking into.   Some
prints from find_pc_sect_symtab for a LKM function seems to return
vmlinux's symtab! :(

find_pc_sect_symtab(pc=0xffffffffa00d5bb8,sec=0x20fb988)
objfile=0x11cbc40, name=/usr/src/linux-cfs-bw/vmlinux
Returning 0x2690cc0 (objfile=0x11cbc40)  # Which is vmlinux

So, I checked the BLOCK_START and BLOCK_END for the vmlinux image.  I got this:
start=0xffffffff8102eb10
end=0xffffffffff60017f

and pc=0xffffffffa00d5bb8 was very well within start and end, so it
chose vmlinux. :(

So, I tired this (without loading vmlinux's symbols)

(gdb) target remote localhost:1234
(gdb) add-symbol-file (for module)
(gdb) info scope module_function
(got info)
(gdb) break module_function
(correct break)
(gdb) info scope module_function
(got correct info!  it works!)

All locals/args info is retained.

So, to combat this, I presently do this (load vmlinux _after_ loading
module symbols)

gdb (without vmlinux)
(gdb) target remote ...
(gdb) add-symbol-file (for module)
(gdb) file vmlinux
(gdb) break vport_receive
Breakpoint 1, vport_receive (vport=0xffff880115fa7200,
skb=0xffff880117580900) at
/home/nikhilh/openvswitch/datapath/linux/vport.c:643
643             if (vport->ops->flags & VPORT_F_GEN_STATS) {

With full information.

I am also able to break into Linux functions, like sys_write for e.g.

Jan: can you try this and tell us if it works?

Thanks,
-- 
Vimal

Re: Multiple breakpoint issue when debugging loadable kernel module

[Jan Kiszka]

On 2011-10-28 05:39, Vimal wrote:
> Some more info.  This looks interesting.
> 
> 1. find_pc_sect_symtab has changed quite a bit between the faulty
> commit noted above (sha 2cdbbe44) and its parent (2cdbbe44^)!
> 
> 2. Since the module is loaded into the kernel address space,
> find_pc_sect_symtab seems to think the vmlinux module's symbol table
> has symbol information for the function I am breaking into.   Some
> prints from find_pc_sect_symtab for a LKM function seems to return
> vmlinux's symtab! :(
> 
> find_pc_sect_symtab(pc=0xffffffffa00d5bb8,sec=0x20fb988)
> objfile=0x11cbc40, name=/usr/src/linux-cfs-bw/vmlinux
> Returning 0x2690cc0 (objfile=0x11cbc40)  # Which is vmlinux
> 
> So, I checked the BLOCK_START and BLOCK_END for the vmlinux image.  I got this:
> start=0xffffffff8102eb10
> end=0xffffffffff60017f
> 
> and pc=0xffffffffa00d5bb8 was very well within start and end, so it
> chose vmlinux. :(
> 
> So, I tired this (without loading vmlinux's symbols)
> 
> (gdb) target remote localhost:1234
> (gdb) add-symbol-file (for module)
> (gdb) info scope module_function
> (got info)
> (gdb) break module_function
> (correct break)
> (gdb) info scope module_function
> (got correct info!  it works!)
> 
> All locals/args info is retained.
> 
> So, to combat this, I presently do this (load vmlinux _after_ loading
> module symbols)
> 
> gdb (without vmlinux)
> (gdb) target remote ...
> (gdb) add-symbol-file (for module)
> (gdb) file vmlinux
> (gdb) break vport_receive
> Breakpoint 1, vport_receive (vport=0xffff880115fa7200,
> skb=0xffff880117580900) at
> /home/nikhilh/openvswitch/datapath/linux/vport.c:643
> 643             if (vport->ops->flags & VPORT_F_GEN_STATS) {
> 
> With full information.
> 
> I am also able to break into Linux functions, like sys_write for e.g.
> 
> Jan: can you try this and tell us if it works?

Yes, that works (around the bug). But it does not help me as it's
unhandy (gdb assumes 32-bit by default, my kernels are 64 usually) and
automatic module loading depends on the kernel symbols already being
present.

Tom, do you still like to have a description of the full reproduction
scenario or are you debugging via Vimal?

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: Multiple breakpoint issue when debugging loadable kernel module

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 843 bytes --]

On 2011-10-27 21:38, Tom Tromey wrote:
>>>>>> "Jan" == Jan Kiszka <jan.kiszka@web.de> writes:
> 
> Jan> [1] http://permalink.gmane.org/gmane.comp.gdb.devel/25898
> 
> Nice.
> 
> To answer your question there:
> 
> Jan> (does someone know how to switch of the add-symbol-file output?)
> 
> From Python you can to gdb.execute(..., to_string = True).
> I forget when we added this parameter.
> 
> From the CLI you can use the 'set logging' family of commands to
> temporarily disable output.
> 
> 
> From the code:
> 
> def offset_of(type, field):
> 	return gdb.parse_and_eval('(unsigned long)&( (' + str(type) + ' *)0)->' + str(field))
> 
> You can look up the field in the type and get the offset more directly.
> But this works too.

Yeah, works nicely. Was unfortunately not yet available in 7.1.

Thanks,
Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: Multiple breakpoint issue when debugging loadable kernel module

[Tom Tromey]

>>>>> "Jan" == Jan Kiszka <jan.kiszka@siemens.com> writes:

Jan> Tom, do you still like to have a description of the full reproduction
Jan> scenario or are you debugging via Vimal?

I'd still like a way to reproduce it myself.

Tom

Re: Multiple breakpoint issue when debugging loadable kernel module

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2636 bytes --]

On 2011-10-31 21:53, Tom Tromey wrote:
>>>>>> "Jan" == Jan Kiszka <jan.kiszka@siemens.com> writes:
> 
> Jan> Tom, do you still like to have a description of the full reproduction
> Jan> scenario or are you debugging via Vimal?
> 
> I'd still like a way to reproduce it myself.

Here we go:

The setup is not that simple, in fact (unless I miss a much simpler
scenario). You need a target Linux system on which you can install a
kernel (with modules) which has debug symbols enabled. Either (re-)build
your own or use a -debug package from a distro.

Then you need to decide which gdbserver to use: either kgdb on a live
system or (I think that's easier) qemu with it's gdb stub. Boot the
kernel on the target/guest for which you have the corresponding debug
objects on the host. If you feel brave, run qemu as root and let it pick
up your host's disk for the guest - in no-modification mode:

qemu-system-x86_64 /dev/sda -snapshot -m 1G -s

Don't forget the -snapshot or host and guest will use the same disk...

If you have VT-x/AMD-V on your host: modprobe kvm-intel/kvm-amd first,
and then append -enable-kvm to the qemu command line (the qemu fork
qemu-kvm will imply this and refuse to work with kvm modules).

Once the target is up, check /proc/modules for some used module and its
start address. Pick one, say mac80211, and note the address (or use my
script later on). Also pick some function in that module (see
/proc/kallsyms, e.g. ieee80211_register_hw in the mac80211 case).

Next fire up the debugger (the kernel comes with kgdb docbook section,
qemu just requires the "-s" command line switch) and attach to the
target (kgdb via serial console, qemu is listening on TCP port 1234 by
default).

Now we get to the point. Load the module symbols at the right address
(or use my script) and perform the following steps:

(gdb) add-symbol-file /path/to/some/module.ko 0x...
(gdb) l ieee80211_register_hw
624             return local_to_hw(local);
625     }
626     EXPORT_SYMBOL(ieee80211_alloc_hw);
627
628     int ieee80211_register_hw(struct ieee80211_hw *hw)
629     {
630             struct ieee80211_local *local = hw_to_local(hw);
631             int result;
632             enum ieee80211_band band;
633             int channels, max_bitrates;
(gdb) b ieee80211_register_hw
Breakpoint 1 at 0xffffffffa01b31a0: file
/data/linux/net/mac80211/main.c, line 646.
(gdb) l ieee80211_register_hw
No line number known for ieee80211_register_hw.

That's the bug.

Hope that's manageable - somehow. Feel free to ask if you run into
problems with the setup.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: Multiple breakpoint issue when debugging loadable kernel module

[Jan Kratochvil]

On Tue, 01 Nov 2011 16:31:29 +0100, Jan Kiszka wrote:
> (gdb) b ieee80211_register_hw
> Breakpoint 1 at 0xffffffffa01b31a0: file
> /data/linux/net/mac80211/main.c, line 646.
> (gdb) l ieee80211_register_hw
> No line number known for ieee80211_register_hw.

It reminds me a binutils bug, maybe you could check your
/path/to/some/module.ko with readelf if it has its .debug_ranges right:
	https://bugzilla.redhat.com/show_bug.cgi?id=714824#c6

Sure it also may be a completely different bug and it may really be in GDB.


Thanks,
Jan

Re: Multiple breakpoint issue when debugging loadable kernel module

[Vimal]

Oops, somehow missed this thread.

On 1 November 2011 14:12, Jan Kratochvil <jan.kratochvil@redhat.com> wrote:
>
> It reminds me a binutils bug, maybe you could check your
> /path/to/some/module.ko with readelf if it has its .debug_ranges right:
>        https://bugzilla.redhat.com/show_bug.cgi?id=714824#c6
>
> Sure it also may be a completely different bug and it may really be in GDB.

As I am not experienced enough with this, would love some more
pointers.   Are you suggesting gcc does not insert debug information
correctly?   Though this is possible, does it explain the fact that
the same .ko file without recompilation, works with gdb-7.1?

-- 
Vimal

Re: Multiple breakpoint issue when debugging loadable kernel module

[Vimal]

On 31 October 2011 11:16, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>
> Yes, that works (around the bug). But it does not help me as it's
> unhandy (gdb assumes 32-bit by default, my kernels are 64 usually) and
> automatic module loading depends on the kernel symbols already being
> present.
>

I use 64-bit kernels as well, and I do a "set arch i386:x86_64:intel"
before issuing any commands.

How do you do automatic module loading?   Maybe you could disable that :-)

-- 
Vimal

Re: Multiple breakpoint issue when debugging loadable kernel module

[Jan Kratochvil]

On Sat, 05 Nov 2011 03:06:50 +0100, Vimal wrote:
> As I am not experienced enough with this, would love some more
> pointers.

You can also send me offlist the .ko file.

> Are you suggesting gcc does not insert debug information correctly?

Yes.

> Though this is possible, does it explain the fact that
> the same .ko file without recompilation, works with gdb-7.1?

Yes, as this buggy information is there only to direct GDB which CUs
(Compilation Units) need to be expanded, if GDB expands them excessively it
does not need this information, if GDB expands them optimally then the debug
info bug starts to expose.

I do not say this is the bug but I find it probable and checking the debug
info is the most easy first step while troubleshooting it.


Thanks,
Jan

Re: Multiple breakpoint issue when debugging loadable kernel module

[Jan Kratochvil]

On Tue, 01 Nov 2011 21:12:47 +0100, Jan Kratochvil wrote:
> Sure it also may be a completely different bug and it may really be in GDB.

it was; fix posted at:
	[patch] Fix overlapping objfiles with discontiguous CUs (PR 13346)
	http://sourceware.org/ml/gdb-patches/2011-11/msg00166.html


Thanks,
Jan