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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.