This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: S390 gdb patches
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Subject: Re: S390 gdb patches
- From: Jim Blandy <jimb at zwingli dot cygnus dot com>
- Date: 21 Nov 2000 21:56:10 -0500
- Cc: DJBARROW at de dot ibm dot com, gdb-patches at sourceware dot cygnus dot com, BOAS at de dot ibm dot com, Jim Blandy <jimb at cygnus dot com>
- References: <C125699E.005663DF.00@d12mta09.de.ibm.com><3A1B157F.200B96EF@cygnus.com>
> > > I'm not clear on the copyright status of the files:
> > > s390-gdbregs.
> > > s390-regs-common.h
> > > sigcontext.h
> > > which were lifted from the Linux kernel.
> > >
> > > Does IBM currently control the copyright on those
> > > files?
> > I'm no legal genius,
> > Well they are under GPL so I think Richard Stallman
> > & Linus can fight about ownership & may the best loyar win.
> > The files are required to.
> > 1) To keep the kernels register formats compatible with gdb.
> > 2) Remote debugging.
> > 3) Backchaining out of signal handlers.
>
> I'm not a lawyer either. However, I do know (and I'm probably going to
> get flamed for suggesting this) that the Linux kernel group are no where
> near as strict as the FSF is when it comes to copyright assignment.
> Because something is in the Linux kernel, it isn't safe to assume that
> the FSF own the code and it can be included in the GDB sources.
Unless you can assign all copyright interest in those files to the
Free Software Foundation, we can't include them in GDB. It's not an
issue of egotism or territory; it's legally necessary, to allow the
FSF to prosecute license violations in court.
For native debugging, the standard approach is to drop these files
into /usr/src/linux/include/asm-s390 (or whatever you're calling it).
Then, /usr/include/asm is a symlink to /usr/src/linux/include/asm,
which is a symlink to .../asm-s390, so GDB can #include
<asm/sigcontext.h>, and get the right file. That way, you don't have
two versions to keep in sync, and the copyright issues are irrelevant.
Remote debugging, as Andrew says, is an unresolved issue. But you
usually can't use the native header files in that context anyway ---
you don't know what the host's word size or endianness is, so struct
declarations are useless.