Reporting unsupported things.

On Mon, 2006-04-24 at 16:55 -0400, Daniel Jacobowitz wrote:
> We want to say that reverse execution is not supported.

I have been given a similar request.  My users want to see a
message
like "a 32-bit ppc GDB can't debug a 64-bit ppc
target program".

In general, it would be nice if GDB could detect that it was
being asked
to do something it can't do as soon as it was asked.

This kind of intersects with the multi-arch idea.  With
that, GDB
conceptually has a binary matrix where each column would
represent a
different target and each row a different host and the cell
value would
be true if the GDB configured for the given host could debug
the given
target.

If the target is remote, it could tell GDB which column of
the matrix is
appropriate.

For a native configuration, perhaps the appropriate row of
the matrix
could be built by some config script and the appropriate
column could be
chosen based on the type of the executable and/or corefile. 
And
'attach' muddies up the water a bit.

I guess what I am suggesting is that GDB have a concrete
matrix like
this and consult it as soon as it's known what the user is
trying to do.
Of course the 'matrix' would probably really be a hash.

What do you think?

-=# Paul #=-

PS:  In theory, a 32-bit GDB running on a 64-bit ppc host
could debug a
64-bit target: "ptrace" allegedly supports this.
 The current ppc port,
however, does not.

PPS: Do you know of any other "biarch"
configurations of GDB?

> From: PAUL GILLIAM <pgilliamus.ibm.com>
> Date: Mon, 24 Apr 2006 17:00:44 -0700
> 
> On Mon, 2006-04-24 at 16:55 -0400, Daniel Jacobowitz
wrote:
> > We want to say that reverse execution is not
supported.
> 
> I have been given a similar request.  My users want to
see a message
> like "a 32-bit ppc GDB can't debug a 64-bit ppc
target program".

They probably would see that message if the 64-bit powerpc
support was
seperated out from the 32-bit code, and GDB was configured
for
powerpc-ibm-linux-gnu instead of powerpc64-ibm-linux-gnu. 
The former
would probably be a good thing to do (I've done it for
sparc/sparc64),
the latter is a bit harder to accomplish since config.guess
will
probably report powerpc64-ibm-linux-gnu even if only only
the kernel
is 64-bit and all of userland is 32-bit.  It would really
help if the
Linux distributions got their act together and reported the
canonical
system name of the development environment instead of the
kernel.

> In general, it would be nice if GDB could detect that
it was being asked
> to do something it can't do as soon as it was asked.
> 
> This kind of intersects with the multi-arch idea.  With
that, GDB
> conceptually has a binary matrix where each column
would represent a
> different target and each row a different host and the
cell value would
> be true if the GDB configured for the given host could
debug the given
> target.

Do you mean target in the sense if "ISA target"
or "debugging interface"?

The long-term goal defenitely is for GDB to be able to debug
all ISA
targets on all hosts.  But the native debugging interface
may only
support a subset of the host's "personalities".
 Where by personality
here may mean 64-bit or 32-bit personalities for the native
operating
system, but also operating systems that can be emulated by
the host.
On some of the BSD's for example, it is possible to debug
Linux binaries.

> If the target is remote, it could tell GDB which column
of the matrix is
> appropriate.
> 
> For a native configuration, perhaps the appropriate row
of the matrix
> could be built by some config script and the
appropriate column could be
> chosen based on the type of the executable and/or
corefile.  And
> 'attach' muddies up the water a bit.
> 
> I guess what I am suggesting is that GDB have a
concrete matrix like
> this and consult it as soon as it's known what the
user is trying to do.
> Of course the 'matrix' would probably really be a
hash.
> 
> What do you think?

Unfortunately, I think the matrix idea doesn't really work.
 There are
subtle differences between native targets (even Linux native
targets)
that make 32-bitX64-bit debugging unfasable.

> PS:  In theory, a 32-bit GDB running on a 64-bit ppc
host could debug a
> 64-bit target: "ptrace" allegedly supports
this.  The current ppc port,
> however, does not.
> 
> PPS: Do you know of any other "biarch"
configurations of GDB?

i386/amd64
sparc/sparc64

On Mon, Apr 24, 2006 at 05:00:44PM -0700, PAUL GILLIAM
wrote:
> On Mon, 2006-04-24 at 16:55 -0400, Daniel Jacobowitz
wrote:
> > We want to say that reverse execution is not
supported.
> 
> I have been given a similar request.  My users want to
see a message
> like "a 32-bit ppc GDB can't debug a 64-bit ppc
target program".

This is not at all the same problem.  You could just refuse
to create
one if GDB was configured inappropriately.

> In general, it would be nice if GDB could detect that
it was being asked
> to do something it can't do as soon as it was asked.

The problem is "where does it become obvious that we
can't do what the
user wants"?  A powerpc-linux GDB can probably remote
debug a 64-bit
binary.  It's native debug that presents a problem.

> PS:  In theory, a 32-bit GDB running on a 64-bit ppc
host could debug a
> 64-bit target: "ptrace" allegedly supports
this.  The current ppc port,
> however, does not.

Richard Henderson posted patches for this months ago.  They
should be
looked at again.  I've done similar for MIPS.

-- 
Daniel Jacobowitz
CodeSourcery