Re: RFA: AIX 64-bit mega-patch

[Nick Duffek <nsd at redhat dot com>]

On 11-Jun-2000, Andrew Cagney wrote:

>Whats happening now?  I would expect the action:
>
>	(gdb) file foo
>
>to set everything up for foo so that a later:
>
>	(gdb) run
>
>didn't change things - the architecture hadn't changed.

That is what's happening now, as far as I know, but I didn't know whether
there was an explicit policy to that effect.

Here's an example that could be used to argue against that policy:

Suppose GDB running natively on an i386 is asked to debug a binary that
contains Pentium Pro instructions.  Before starting an inferior process,
it might be reasonable for the disassemble command to decode those Pentium
Pro instructions, i.e. for GDB to set its architecture to match the
binary.

However, when running an inferior i386 process, it's arguably more
reasonable for GDB's disassembly to identify those Pentium Pro
instructions as illegal, since the i386 process being debugged will see
them that way.  As a result, when the i386 process gets a SIGILL and the
user types "disas $pc", it'll be obvious where the problem lies.  This
is accomplished by GDB setting its architecture to match the process.

I can imagine a more radical example where two slightly-different CPUs
interpret the same instruction as valid but different, but I don't know
whether such CPU pairs exist.

Anyway, in my previous message, I was arguing in favor of GDB initializing
its architecture to match processes rather than binaries, and it sounds
like that's already the policy.

Similarly, if a core file is present, I would argue that GDB should
initialize its architecture from the process represented by the core file
rather than from the binary.

Is this all hashed out in a document somewhere?  Maybe I'm wasting time by
working through already-resolved issues.

Nick