kgdb: rename i386-stub.c to kgdb.c

kgdb: rename i386-stub.c to kgdb.c

[Pavel Machek]

Hi!

kgdb uses really confusing names for arch-dependend parts. This fixes
it. Okay to commit?
								Pavel

? big.diff
? big.patch
? patchit
Index: core-lite.patch
===================================================================
RCS file: /cvsroot/kgdb/kgdb-2/core-lite.patch,v
retrieving revision 1.3
diff -u -u -r1.3 core-lite.patch
--- core-lite.patch	23 Feb 2004 21:48:55 -0000	1.3
+++ core-lite.patch	24 Feb 2004 12:58:08 -0000
@@ -209,8 +209,8 @@
  	do_basic_setup();
  
  	prepare_namespace();
---- clean.2.5/kernel/kgdbstub.c	2004-02-17 11:38:39.000000000 +0100
-+++ linux-mm/kernel/kgdbstub.c	2004-02-22 21:49:11.000000000 +0100
+--- clean.2.5/kernel/kgdb.c	2004-02-17 11:38:39.000000000 +0100
++++ linux-mm/kernel/kgdb.c	2004-02-22 21:49:11.000000000 +0100
 @@ -0,0 +1,1268 @@
 +/*
 + * This program is free software; you can redistribute it and/or modify it
@@ -1488,7 +1488,7 @@
  obj-$(CONFIG_COMPAT) += compat.o
  obj-$(CONFIG_IKCONFIG) += configs.o
  obj-$(CONFIG_IKCONFIG_PROC) += configs.o
-+obj-$(CONFIG_KGDB) += kgdbstub.o
++obj-$(CONFIG_KGDB) += kgdb.o
  
  ifneq ($(CONFIG_IA64),y)
  # According to Alan Modra <alan@linuxcare.com.au>, the -fno-omit-frame-pointer is
Index: i386-lite.patch
===================================================================
RCS file: /cvsroot/kgdb/kgdb-2/i386-lite.patch,v
retrieving revision 1.2
diff -u -u -r1.2 i386-lite.patch
--- i386-lite.patch	23 Feb 2004 21:48:55 -0000	1.2
+++ i386-lite.patch	24 Feb 2004 12:58:45 -0000
@@ -23,8 +23,8 @@
  config FRAME_POINTER
  	bool "Compile the kernel with frame pointers"
  	help
---- clean.2.5/arch/i386/kernel/i386-stub.c	2004-02-17 11:39:06.000000000 +0100
-+++ linux-mm/arch/i386/kernel/i386-stub.c	2004-02-22 21:42:55.000000000 +0100
+--- clean.2.5/arch/i386/kernel/kgdb.c	2004-02-17 11:39:06.000000000 +0100
++++ linux-mm/arch/i386/kernel/kgdb.c	2004-02-22 21:42:55.000000000 +0100
 @@ -0,0 +1,373 @@
 +/*
 + *
@@ -407,7 +407,7 @@
  obj-$(CONFIG_ACPI_SRAT) 	+= srat.o
  obj-$(CONFIG_HPET_TIMER) 	+= time_hpet.o
  obj-$(CONFIG_EFI) 		+= efi.o efi_stub.o
-+obj-$(CONFIG_KGDB)		+= i386-stub.o
++obj-$(CONFIG_KGDB)		+= kgdb.o
  
  EXTRA_AFLAGS   := -traditional
  
Index: x86_64.patch
===================================================================
RCS file: /cvsroot/kgdb/kgdb-2/x86_64.patch,v
retrieving revision 1.2
diff -u -u -r1.2 x86_64.patch
--- x86_64.patch	19 Feb 2004 08:52:25 -0000	1.2
+++ x86_64.patch	24 Feb 2004 12:58:50 -0000
@@ -119,7 +119,7 @@
  obj-$(CONFIG_DUMMY_IOMMU)	+= pci-nommu.o pci-dma.o
  
  obj-$(CONFIG_MODULES)		+= module.o
-+obj-$(CONFIG_KGDB)		+= x86_64-stub.o
++obj-$(CONFIG_KGDB)		+= kgdb.o
  
  obj-y				+= topology.o
  
@@ -208,10 +208,10 @@
  	notify_die(DIE_DEBUG, "debug", regs, error_code, 1, SIGTRAP);
  	return;
  
-Index: linux-2.6.3-kgdb/arch/x86_64/kernel/x86_64-stub.c
+Index: linux-2.6.3-kgdb/arch/x86_64/kernel/kgdb.c
 ===================================================================
---- linux-2.6.3-kgdb.orig/arch/x86_64/kernel/x86_64-stub.c	2003-01-30 15:54:37.000000000 +0530
-+++ linux-2.6.3-kgdb/arch/x86_64/kernel/x86_64-stub.c	2004-02-19 14:09:24.234743240 +0530
+--- linux-2.6.3-kgdb.orig/arch/x86_64/kernel/kgdb.c	2003-01-30 15:54:37.000000000 +0530
++++ linux-2.6.3-kgdb/arch/x86_64/kernel/kgdb.c	2004-02-19 14:09:24.234743240 +0530
 @@ -0,0 +1,454 @@
 +/*
 + *

-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: kgdb: rename i386-stub.c to kgdb.c

[Amit S. Kale]

On Tuesday 24 Feb 2004 6:36 pm, Pavel Machek wrote:
> Hi!
>
> kgdb uses really confusing names for arch-dependend parts. This fixes
> it. Okay to commit?

Why is arch/$x/kernel/$x-stub.c confusing? The name $x-stub.c is indicative of 
architecture dependent code in it. Err, well so is the path.

PPC and sparc stubs in present vanilla kernel use this naming convention. 
That's why I adopted it.

I find kernel/kgdbstub.c, arch/$x/kernel/$x-stub.c more consistent compared to 
kernel/kgdbstub.c, arch/$x/kernel/kgdb.c

-Amit

> 								Pavel
>
> ? big.diff
> ? big.patch
> ? patchit
> Index: core-lite.patch
> ===================================================================
> RCS file: /cvsroot/kgdb/kgdb-2/core-lite.patch,v
> retrieving revision 1.3
> diff -u -u -r1.3 core-lite.patch
> --- core-lite.patch	23 Feb 2004 21:48:55 -0000	1.3
> +++ core-lite.patch	24 Feb 2004 12:58:08 -0000
> @@ -209,8 +209,8 @@
>   	do_basic_setup();
>
>   	prepare_namespace();
> ---- clean.2.5/kernel/kgdbstub.c	2004-02-17 11:38:39.000000000 +0100
> -+++ linux-mm/kernel/kgdbstub.c	2004-02-22 21:49:11.000000000 +0100
> +--- clean.2.5/kernel/kgdb.c	2004-02-17 11:38:39.000000000 +0100
> ++++ linux-mm/kernel/kgdb.c	2004-02-22 21:49:11.000000000 +0100
>  @@ -0,0 +1,1268 @@
>  +/*
>  + * This program is free software; you can redistribute it and/or modify
> it @@ -1488,7 +1488,7 @@
>   obj-$(CONFIG_COMPAT) += compat.o
>   obj-$(CONFIG_IKCONFIG) += configs.o
>   obj-$(CONFIG_IKCONFIG_PROC) += configs.o
> -+obj-$(CONFIG_KGDB) += kgdbstub.o
> ++obj-$(CONFIG_KGDB) += kgdb.o
>
>   ifneq ($(CONFIG_IA64),y)
>   # According to Alan Modra <alan@linuxcare.com.au>, the
> -fno-omit-frame-pointer is Index: i386-lite.patch
> ===================================================================
> RCS file: /cvsroot/kgdb/kgdb-2/i386-lite.patch,v
> retrieving revision 1.2
> diff -u -u -r1.2 i386-lite.patch
> --- i386-lite.patch	23 Feb 2004 21:48:55 -0000	1.2
> +++ i386-lite.patch	24 Feb 2004 12:58:45 -0000
> @@ -23,8 +23,8 @@
>   config FRAME_POINTER
>   	bool "Compile the kernel with frame pointers"
>   	help
> ---- clean.2.5/arch/i386/kernel/i386-stub.c	2004-02-17 11:39:06.000000000
> +0100 -+++ linux-mm/arch/i386/kernel/i386-stub.c	2004-02-22
> 21:42:55.000000000 +0100 +--- clean.2.5/arch/i386/kernel/kgdb.c	2004-02-17
> 11:39:06.000000000 +0100 ++++ linux-mm/arch/i386/kernel/kgdb.c	2004-02-22
> 21:42:55.000000000 +0100 @@ -0,0 +1,373 @@
>  +/*
>  + *
> @@ -407,7 +407,7 @@
>   obj-$(CONFIG_ACPI_SRAT) 	+= srat.o
>   obj-$(CONFIG_HPET_TIMER) 	+= time_hpet.o
>   obj-$(CONFIG_EFI) 		+= efi.o efi_stub.o
> -+obj-$(CONFIG_KGDB)		+= i386-stub.o
> ++obj-$(CONFIG_KGDB)		+= kgdb.o
>
>   EXTRA_AFLAGS   := -traditional
>
> Index: x86_64.patch
> ===================================================================
> RCS file: /cvsroot/kgdb/kgdb-2/x86_64.patch,v
> retrieving revision 1.2
> diff -u -u -r1.2 x86_64.patch
> --- x86_64.patch	19 Feb 2004 08:52:25 -0000	1.2
> +++ x86_64.patch	24 Feb 2004 12:58:50 -0000
> @@ -119,7 +119,7 @@
>   obj-$(CONFIG_DUMMY_IOMMU)	+= pci-nommu.o pci-dma.o
>
>   obj-$(CONFIG_MODULES)		+= module.o
> -+obj-$(CONFIG_KGDB)		+= x86_64-stub.o
> ++obj-$(CONFIG_KGDB)		+= kgdb.o
>
>   obj-y				+= topology.o
>
> @@ -208,10 +208,10 @@
>   	notify_die(DIE_DEBUG, "debug", regs, error_code, 1, SIGTRAP);
>   	return;
>
> -Index: linux-2.6.3-kgdb/arch/x86_64/kernel/x86_64-stub.c
> +Index: linux-2.6.3-kgdb/arch/x86_64/kernel/kgdb.c
>  ===================================================================
> ---- linux-2.6.3-kgdb.orig/arch/x86_64/kernel/x86_64-stub.c	2003-01-30
> 15:54:37.000000000 +0530 -+++
> linux-2.6.3-kgdb/arch/x86_64/kernel/x86_64-stub.c	2004-02-19
> 14:09:24.234743240 +0530 +---
> linux-2.6.3-kgdb.orig/arch/x86_64/kernel/kgdb.c	2003-01-30
> 15:54:37.000000000 +0530 ++++
> linux-2.6.3-kgdb/arch/x86_64/kernel/kgdb.c	2004-02-19 14:09:24.234743240
> +0530 @@ -0,0 +1,454 @@
>  +/*
>  + *

Re: kgdb: rename i386-stub.c to kgdb.c

[Pavel Machek]

Hi!

> > kgdb uses really confusing names for arch-dependend parts. This fixes
> > it. Okay to commit?
> 
> Why is arch/$x/kernel/$x-stub.c confusing? The name $x-stub.c is indicative of 
> architecture dependent code in it. Err, well so is the path.


Well, looking at i386-stub.c, how do you know it is kgdb-related?

> PPC and sparc stubs in present vanilla kernel use this naming convention. 
> That's why I adopted it.
> 
> I find kernel/kgdbstub.c, arch/$x/kernel/$x-stub.c more consistent compared to 
> kernel/kgdbstub.c, arch/$x/kernel/kgdb.c

I actually made it kernel/kgdb.c and arch/*/kernel/kgdb.c. I believe
there's no point where one could be confused....
								Pavel
-- 
Horseback riding is like software...
...vgf orggre jura vgf serr.

Re: kgdb: rename i386-stub.c to kgdb.c

[Amit S. Kale]

On Wednesday 25 Feb 2004 4:07 pm, Pavel Machek wrote:
> Hi!
>
> > > kgdb uses really confusing names for arch-dependend parts. This fixes
> > > it. Okay to commit?
> >
> > Why is arch/$x/kernel/$x-stub.c confusing? The name $x-stub.c is
> > indicative of architecture dependent code in it. Err, well so is the
> > path.
>
> Well, looking at i386-stub.c, how do you know it is kgdb-related?

hmm... I see what you meant by "confusing". The confusing part is file name 
not representing contents. Agreed.

> > PPC and sparc stubs in present vanilla kernel use this naming convention.
> > That's why I adopted it.
> >
> > I find kernel/kgdbstub.c, arch/$x/kernel/$x-stub.c more consistent
> > compared to kernel/kgdbstub.c, arch/$x/kernel/kgdb.c
>
> I actually made it kernel/kgdb.c and arch/*/kernel/kgdb.c. I believe

OOPS I didn't notice that.

> there's no point where one could be confused....

kernel/kgdb.c and arch/*kernel/kgdb.c have same file name appearing in two 
places :-( mainline kernel also does it (e.g. ptrace.c)

Let's  go with the convention followed in mainline kernel.
OK from me.

-Amit

Re: kgdb: rename i386-stub.c to kgdb.c

[Pavel Machek]

Hi!

> > > > kgdb uses really confusing names for arch-dependend parts. This fixes
> > > > it. Okay to commit?
> > >
> > > Why is arch/$x/kernel/$x-stub.c confusing? The name $x-stub.c is
> > > indicative of architecture dependent code in it. Err, well so is the
> > > path.
> >
> > Well, looking at i386-stub.c, how do you know it is kgdb-related?
> 
> hmm... I see what you meant by "confusing". The confusing part is file name 
> not representing contents. Agreed.
> 
> > > PPC and sparc stubs in present vanilla kernel use this naming convention.
> > > That's why I adopted it.
> > >
> > > I find kernel/kgdbstub.c, arch/$x/kernel/$x-stub.c more consistent
> > > compared to kernel/kgdbstub.c, arch/$x/kernel/kgdb.c
> >
> > I actually made it kernel/kgdb.c and arch/*/kernel/kgdb.c. I believe
> 
> OOPS I didn't notice that.
> 
> > there's no point where one could be confused....
> 
> kernel/kgdb.c and arch/*kernel/kgdb.c have same file name appearing in two 
> places :-( mainline kernel also does it (e.g. ptrace.c)
> 
> Let's  go with the convention followed in mainline kernel.
> OK from me.

Now you confused me :-). I commited rename of arch/*/kernel/*-stub.c
into arch/*/kernel/kgdb.c.

Should I commit rename of kernel/kgdbstub.c into kernel/kgdb.c, too?

								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: kgdb: rename i386-stub.c to kgdb.c

[Amit S. Kale]

On Wednesday 25 Feb 2004 4:40 pm, Pavel Machek wrote:
> Hi!
>
> > > > > kgdb uses really confusing names for arch-dependend parts. This
> > > > > fixes it. Okay to commit?
> > > >
> > > > Why is arch/$x/kernel/$x-stub.c confusing? The name $x-stub.c is
> > > > indicative of architecture dependent code in it. Err, well so is the
> > > > path.
> > >
> > > Well, looking at i386-stub.c, how do you know it is kgdb-related?
> >
> > hmm... I see what you meant by "confusing". The confusing part is file
> > name not representing contents. Agreed.
> >
> > > > PPC and sparc stubs in present vanilla kernel use this naming
> > > > convention. That's why I adopted it.
> > > >
> > > > I find kernel/kgdbstub.c, arch/$x/kernel/$x-stub.c more consistent
> > > > compared to kernel/kgdbstub.c, arch/$x/kernel/kgdb.c
> > >
> > > I actually made it kernel/kgdb.c and arch/*/kernel/kgdb.c. I believe
> >
> > OOPS I didn't notice that.
> >
> > > there's no point where one could be confused....
> >
> > kernel/kgdb.c and arch/*kernel/kgdb.c have same file name appearing in
> > two places :-( mainline kernel also does it (e.g. ptrace.c)
> >
> > Let's  go with the convention followed in mainline kernel.
> > OK from me.
>
> Now you confused me :-). I commited rename of arch/*/kernel/*-stub.c
> into arch/*/kernel/kgdb.c.
>
> Should I commit rename of kernel/kgdbstub.c into kernel/kgdb.c, too?

Yes, please do.

-Amit

Re: [Kgdb-bugreport] Re: kgdb: rename i386-stub.c to kgdb.c

[George Anzinger]

Pavel Machek wrote:
> Hi!
> 
> 
>>>kgdb uses really confusing names for arch-dependend parts. This fixes
>>>it. Okay to commit?
>>
>>Why is arch/$x/kernel/$x-stub.c confusing? The name $x-stub.c is indicative of 
>>architecture dependent code in it. Err, well so is the path.
> 
> 
> 
> Well, looking at i386-stub.c, how do you know it is kgdb-related?
> 
> 
>>PPC and sparc stubs in present vanilla kernel use this naming convention. 
>>That's why I adopted it.
>>
>>I find kernel/kgdbstub.c, arch/$x/kernel/$x-stub.c more consistent compared to 
>>kernel/kgdbstub.c, arch/$x/kernel/kgdb.c
> 
> 
> I actually made it kernel/kgdb.c and arch/*/kernel/kgdb.c. I believe
> there's no point where one could be confused....

gdb itself gets confused with this.  Try, for example, time.c which, on the x86, 
is in both arch and common code.  I use emacs with kgdb and it gets confused 
when I point at a location in the source and tell it to set a break point.

Please, lets have only one of each name.


-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml

Re: [Kgdb-bugreport] Re: kgdb: rename i386-stub.c to kgdb.c

[Pavel Machek]

Hi!

> >>>kgdb uses really confusing names for arch-dependend parts. This fixes
> >>>it. Okay to commit?
> >>
> >>Why is arch/$x/kernel/$x-stub.c confusing? The name $x-stub.c is 
> >>indicative of architecture dependent code in it. Err, well so is the path.
> >
> >
> >
> >Well, looking at i386-stub.c, how do you know it is kgdb-related?
> >
> >
> >>PPC and sparc stubs in present vanilla kernel use this naming convention. 
> >>That's why I adopted it.
> >>
> >>I find kernel/kgdbstub.c, arch/$x/kernel/$x-stub.c more consistent 
> >>compared to kernel/kgdbstub.c, arch/$x/kernel/kgdb.c
> >
> >
> >I actually made it kernel/kgdb.c and arch/*/kernel/kgdb.c. I believe
> >there's no point where one could be confused....
> 
> gdb itself gets confused with this.  Try, for example, time.c which, on the 
> x86, is in both arch and common code.  I use emacs with kgdb and it gets 
> confused when I point at a location in the source and tell it to set a 
> break point.

That's a gdb bug, surely?

My gdb seems to work okay:

(gdb) b time.c:3
Breakpoint 1 at 0xc01e8b30: file fs/ntfs/time.c, line 3.
(gdb) b kernel/time.c:3
Breakpoint 2 at 0xc0122540: file kernel/time.c, line 3.
(gdb)

....that seems more or less right.

> Please, lets have only one of each name.

You can't have that, anyway.. Filenames are already repeating.

Well, I already commited it. It is possible to revert last change, and
we'll get kernel/kgdbstub.c but arch/*/kernel/kgdb.c.
								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: kgdb: rename i386-stub.c to kgdb.c

[Tom Rini]

On Wed, Feb 25, 2004 at 01:17:15PM -0800, George Anzinger wrote:
> Pavel Machek wrote:
> >Hi!
> >
> >
> >>>kgdb uses really confusing names for arch-dependend parts. This fixes
> >>>it. Okay to commit?
> >>
> >>Why is arch/$x/kernel/$x-stub.c confusing? The name $x-stub.c is 
> >>indicative of architecture dependent code in it. Err, well so is the path.
> >
> >
> >
> >Well, looking at i386-stub.c, how do you know it is kgdb-related?
> >
> >
> >>PPC and sparc stubs in present vanilla kernel use this naming convention. 
> >>That's why I adopted it.
> >>
> >>I find kernel/kgdbstub.c, arch/$x/kernel/$x-stub.c more consistent 
> >>compared to kernel/kgdbstub.c, arch/$x/kernel/kgdb.c
> >
> >
> >I actually made it kernel/kgdb.c and arch/*/kernel/kgdb.c. I believe
> >there's no point where one could be confused....
> 
> gdb itself gets confused with this.  Try, for example, time.c which, on the 
> x86, is in both arch and common code.  I use emacs with kgdb and it gets 
> confused when I point at a location in the source and tell it to set a 
> break point.
> 
> Please, lets have only one of each name.

We can't.  We've had various things (most notably MODVERSIONS prior to
2.6) which are unhappy with that, and in the end, the problem ends up
being fixed elsewhere.  In fact, this should be able to as well.  Using
your time.c example:
(gdb) break arch/i386/kernel/time.c:set_rtc_mmss
Breakpoint 3 at 0xc010ee90: file arch/i386/kernel/time.c, line 174.
(gdb) break kernel/time.c:sys_time 
Breakpoint 4 at 0xc011f0cc: file time.h, line 301.

So shouldn't it be a matter of somehow just not having a time.c
reference as well in the debug data?

-- 
Tom Rini
http://gate.crashing.org/~trini/

Re: kgdb: rename i386-stub.c to kgdb.c

[George Anzinger]

Tom Rini wrote:
> On Wed, Feb 25, 2004 at 01:17:15PM -0800, George Anzinger wrote:
> 
>>Pavel Machek wrote:
>>
>>>Hi!
>>>
>>>
>>>
>>>>>kgdb uses really confusing names for arch-dependend parts. This fixes
>>>>>it. Okay to commit?
>>>>
>>>>Why is arch/$x/kernel/$x-stub.c confusing? The name $x-stub.c is 
>>>>indicative of architecture dependent code in it. Err, well so is the path.
>>>
>>>
>>>
>>>Well, looking at i386-stub.c, how do you know it is kgdb-related?
>>>
>>>
>>>
>>>>PPC and sparc stubs in present vanilla kernel use this naming convention. 
>>>>That's why I adopted it.
>>>>
>>>>I find kernel/kgdbstub.c, arch/$x/kernel/$x-stub.c more consistent 
>>>>compared to kernel/kgdbstub.c, arch/$x/kernel/kgdb.c
>>>
>>>
>>>I actually made it kernel/kgdb.c and arch/*/kernel/kgdb.c. I believe
>>>there's no point where one could be confused....
>>
>>gdb itself gets confused with this.  Try, for example, time.c which, on the 
>>x86, is in both arch and common code.  I use emacs with kgdb and it gets 
>>confused when I point at a location in the source and tell it to set a 
>>break point.
>>
>>Please, lets have only one of each name.
> 
> 
> We can't.  We've had various things (most notably MODVERSIONS prior to
> 2.6) which are unhappy with that, and in the end, the problem ends up
> being fixed elsewhere.  In fact, this should be able to as well.  Using
> your time.c example:
> (gdb) break arch/i386/kernel/time.c:set_rtc_mmss
> Breakpoint 3 at 0xc010ee90: file arch/i386/kernel/time.c, line 174.
> (gdb) break kernel/time.c:sys_time 
> Breakpoint 4 at 0xc011f0cc: file time.h, line 301.
> 
> So shouldn't it be a matter of somehow just not having a time.c
> reference as well in the debug data?

No it is related to the point and grunt option in emacs:

I would guess it is a problem in the emacs interface where one points at a 
location in the code window and enters a command to set a break point ( I think 
it is "^x " (control X space)).  It would appear that emacs then only sends the 
file name to gdb rather than the full path.

This is not a show stopping problem, only confusing.  Once gdb figures out the 
right source, all is well.  I usually do it by setting a break point at the 
function by name, thus avoiding the point and grunt thing.
> 

-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml

Re: kgdb: rename i386-stub.c to kgdb.c

[Daniel Jacobowitz]

On Wed, Feb 25, 2004 at 02:31:12PM -0800, George Anzinger wrote:
> I would guess it is a problem in the emacs interface where one points at a 
> location in the code window and enters a command to set a break point ( I 
> think it is "^x " (control X space)).  It would appear that emacs then only 
> sends the file name to gdb rather than the full path.
> 
> This is not a show stopping problem, only confusing.  Once gdb figures out 
> the right source, all is well.  I usually do it by setting a break point at 
> the function by name, thus avoiding the point and grunt thing.

This is a known problem in the emacs interfaces; it will be fixed, but
I have no idea when the fixed version will be available :)

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: kgdb: rename i386-stub.c to kgdb.c

[George Anzinger]

Daniel Jacobowitz wrote:
> On Wed, Feb 25, 2004 at 02:31:12PM -0800, George Anzinger wrote:
> 
>>I would guess it is a problem in the emacs interface where one points at a 
>>location in the code window and enters a command to set a break point ( I 
>>think it is "^x " (control X space)).  It would appear that emacs then only 
>>sends the file name to gdb rather than the full path.
>>
>>This is not a show stopping problem, only confusing.  Once gdb figures out 
>>the right source, all is well.  I usually do it by setting a break point at 
>>the function by name, thus avoiding the point and grunt thing.
> 
> 
> This is a known problem in the emacs interfaces; it will be fixed, but
> I have no idea when the fixed version will be available :)
> 
I agree AND I have bigger fish to fry with emacs so....
-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml