From: Steve Kranz <skranz@ridgerun.com>
To: linux-mips@oss.sgi.com, linux-mips@fnet.fr
Subject: remote GDB debugging and the __init macro of init.h
Date: Fri, 27 Oct 2000 09:24:17 -0600 [thread overview]
Message-ID: <39F99E20.8EE47072@ridgerun.com> (raw)
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
skranz@ridgerun.com
Senior Kernel Developer
RidgeRun Inc.
next reply other threads:[~2000-10-27 15:24 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-10-27 15:24 Steve Kranz [this message]
2000-10-27 15:50 ` remote GDB debugging and the __init macro of init.h Kevin D. Kissell
2000-10-27 15:50 ` Kevin D. Kissell
2000-10-28 1:53 ` Ralf Baechle
2000-10-30 17:53 ` Jun Sun
2000-10-31 4:12 ` Ralf Baechle
2000-10-28 1:54 ` Keith Owens
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=39F99E20.8EE47072@ridgerun.com \
--to=skranz@ridgerun.com \
--cc=linux-mips@fnet.fr \
--cc=linux-mips@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox