This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] GDB ARIndex Linux rule cleanup


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]