From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: eliz@gnu.org
Cc: muller@ics.u-strasbg.fr, brobecker@adacore.com,
gdb-patches@sourceware.org, gdb@sourceware.org
Subject: Re: [RFC] GDB ARIndex Linux rule cleanup
Date: Wed, 15 Apr 2009 17:34:00 -0000 [thread overview]
Message-ID: <200904151734.n3FHY8Fv015852@d12av02.megacenter.de.ibm.com> (raw)
In-Reply-To: <83tz4plx93.fsf@gnu.org> from "Eli Zaretskii" at Apr 15, 2009 07:03:52 PM
Eli Zaretskii wrote:
> > Eli Zaretskii wrote:
> > > I think GDB's "target" is always the OS kernel, not the OS itself.
> > >
> > > The distinction FSF asks for is between the GNU/Linux as a whole
> > > system, which includes all the main applications and libraries, and
> > > Linux as the bare-bones OS. GDB targets the latter, not the former.
> >
> > Huh? I'd say a large part of what makes up a GDB target is unrelated
> > to the OS kernel:
> > - Processor properties (register names/types/groups)
>
> That's hardware, and as such, unrelated to our discussion.
>
> > - ABI elements (data types, function calling convention, stack unwinding,
> > C++ ABI, platform-specific debug format details, ...)
>
> Which has nothing to do with GNU.
>
> > - Shared library support, thread support (those may depend on kernel
> > details, but may also -in particular on Linux- depend on strictly
> > user-space library-implemented details ...)
>
> That's not part of the ``target'', in the sense that we were talking
> about.
As the whole discussion started over a -tdep.c file, I was intending to
refer to a "target architecture", i.e. a gdbarch structure (which also
more or less corresponds to what the user specifies as --target= when
configuring GDB). This struct does indeed contain all the elements I
mention above; and my point was simply that its contents are influenced
by the full target operating system (ABI, system libraries, kernel),
and *not* solely the kernel.
The word "target" is unfortunately quite overloaded; when referring to
the "target stack", the situation is somewhat different, but even there
I'd argue that, say, the "Linux native target" implements support for
running GDB natively on the GNU/Linux operating system, not just the kernel
(e.g. due to native thread and shared library support).
> > If you were to write a program using a completely different user-space
> > ABI, it might run just fine on the Linux kernel, but GDB configured
> > for a -linux target would not really be able to successfully debug the
> > program.
>
> We are talking about a specific file, not about the whole of GDB built
> for native debugging.
Yes, the ppc-linux-tdep.c file, which defines the gdbarch struct to be used
when debugging an application built for GNU/Linux on the PowerPC platform,
in either native, remote, or core file debugging mode.
In fact, in this specific file, some elements of the gdbarch struct are
clearly kernel-related (e.g. the ppc_linux_write_pc method to properly
restart interrupted system calls, or the signal trampoline unwinders), some
elements have nothing whatsoever to do with the kernel (e.g. the
ppc_linux_memory_remove_breakpoint method that deals with the fact that
ld.so on powerpc modifies code, or the ppc64_skip_trampoline_code method
which recognizes linker-generated stubs, or the
ppc64_linux_convert_from_func_ptr_addr method that interprets the function
pointer ABI), and some could be considered either way (e.g. the core file
register set definitions -- a core file may be generated by the kernel,
but also other tools, including GDB itself).
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com
next prev parent reply other threads:[~2009-04-15 17:34 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-26 15:29 GDB ARIndex cleanup Pierre Muller
2009-03-26 20:53 ` Eli Zaretskii
2009-03-27 8:23 ` Pierre Muller
2009-03-27 8:47 ` Eli Zaretskii
2009-03-27 14:12 ` Eli Zaretskii
2009-03-27 15:35 ` Eli Zaretskii
2009-04-02 15:12 ` Thiago Jung Bauermann
2009-04-02 19:40 ` Eli Zaretskii
2009-04-02 20:34 ` Joel Brobecker
2009-03-26 23:18 ` Joel Brobecker
2009-03-27 2:22 ` Daniel Jacobowitz
2009-03-27 8:43 ` Pierre Muller
2009-03-27 16:04 ` Joel Brobecker
2009-03-27 16:46 ` Daniel Jacobowitz
2009-04-14 23:06 ` [RFC] GDB ARIndex Linux rule cleanup Pierre Muller
2009-04-14 23:23 ` Mark Kettenis
2009-04-14 23:38 ` Pedro Alves
2009-04-14 23:41 ` Joel Brobecker
2009-04-15 7:06 ` Pierre Muller
2009-04-15 7:33 ` Eli Zaretskii
2009-04-15 14:00 ` Ulrich Weigand
2009-04-15 14:21 ` Pedro Alves
2009-04-15 15:32 ` Ulrich Weigand
2009-04-15 15:54 ` Pedro Alves
2009-04-15 14:25 ` Eli Zaretskii
2009-04-15 15:15 ` Daniel Jacobowitz
2009-04-15 15:23 ` Ulrich Weigand
2009-04-15 15:34 ` Mark Kettenis
2009-04-15 16:00 ` Eli Zaretskii
2009-04-15 16:04 ` Eli Zaretskii
2009-04-15 17:34 ` Ulrich Weigand [this message]
2009-04-15 18:07 ` Eli Zaretskii
2009-04-15 18:55 ` Ulrich Weigand
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=200904151734.n3FHY8Fv015852@d12av02.megacenter.de.ibm.com \
--to=uweigand@de.ibm.com \
--cc=brobecker@adacore.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=gdb@sourceware.org \
--cc=muller@ics.u-strasbg.fr \
/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