Subject: remote GDB debugging and the __init macro of init.h

From: Steve Kranz <[email-masked]>
Date: Fri, 27 Oct 2000 09:24:17 -0600

Note:

  I had to make a change to allow remote MIPS kernel
  debugging (GDB). The change I found necessary was in the
  file:

    include/linux/init.h     (2.4.0-test9)

  As you can see from the snippet below the change
  involves conditionally defining the "__init" macro as
  a function of whether remote debugging is enabled or
  not. Am I missing something, or does this seem like a
  reasonable change?

===========
Was this...
===========
/*
 * Mark functions and data as being only used at initialization
 * or exit time.
 */
#define __init  __attribute__ ((__section__ (".text.init")))

==================================
I changed my local copy to this...
==================================
/*
 * Mark functions and data as being only used at initialization
 * or exit time.
 */
#ifdef CONFIG_REMOTE_DEBUG
// Note: While running the mips-linux-elf-gdb (GNU gdb 5.0), RidgeRun
Inc
// noticed that gdb could not correctly derive the true address of any
symbol
// declared with the __init pragma. This prevented being able to
correctly
// set breakpoints on any of those functions. So, if we are building
// with the GDB remote debugger in mind, then null out the __init
// definition making those functions look like a normal functions
// since this seems to satisfy things for remote kernel debugging.
// Incidentally, for reference, the GDB being used at the time of this
writing
// was configured as "--host=i686-pc-linux-gnu --target=mips-linux-elf".

// and the mips-linux-gcc crosscompiler being used is egcs-2.90.29
980515
// (egcs-1.0.3 release) with binutils version 2.8.1. (These tools
running on
// a x86 host producing code for target CONFIG_CPU_R5000).
#define __init
#else
#define __init  __attribute__ ((__section__ (".text.init")))
#endif

Steve Kranz
[email-masked]
Senior Kernel Developer
RidgeRun Inc.

---

From: "Kevin D. Kissell" <[email-masked]>
Date: Fri, 27 Oct 2000 17:50:50 +0200

What you've done should solve the problem, but note
that it has the side effect of preventing the text and data
sections in question from getting freed up at the end
of initialization.  I probably should have done so myself
last year when I was struggling with debugging some init 
code using kgdb, but instead I simply got used to finding 
the address in the symbol table and setting the breakpoints 
by hex address instead of by symbol.

The real fix would be to  teach gdb to treat symbols
in the init section as valid targets.

            Kevin K.

---

From: Ralf Baechle <[email-masked]>
Date: Sat, 28 Oct 2000 03:53:16 +0200

> in the init section as valid targets.

Did somebody look into porting KDB?

  Ralf

---

From: Keith Owens <[email-masked]>
Date: Sat, 28 Oct 2000 12:54:18 +1100

On Fri, 27 Oct 2000 09:24:17 -0600, 
>  not. Am I missing something, or does this seem like a

It would be better to teach kgdb that the kernel has symbols in
sections other than .text.  Even with your patch, you do not get all
the symbols, there is also code in sections .setup.init, .initcall.init
and .exitcall.exit, with similar sections for data.  You cannot remove
.initcall.init without destroying the kernel initialization procedure.

Recent versions of kgdb for ix86 use a modified version of gdb that
knows about multiple sections for modules.  I do not know if they have
the same functionality for the kernel.

---

From: Jun Sun <[email-masked]>
Date: Mon, 30 Oct 2000 09:53:59 -0800

> by hex address instead of by symbol.

Kevin,

A dumb question - how do you set breakpoint at specified address?  I was
trying to do that with "b 0xabcdabcd" or "b @0xabcdabcd", none of them
worked.

Jun

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 31 Oct 2000 05:12:04 +0100

> trying to do that with "b 0xabcdabcd" or "b @0xabcdabcd", none of them

b *0xabcdabcd

Try ``help break'' :-)

  Ralf