Re: gdb & gdbserver for s390 31 & 64 bit

[Andrew Cagney <ac131313@cygnus.com>]

> 
> Setting GDB_MULTI_ARCH to 1 in /config/s390.mt & /config/s390x.mt
> does work & compile correctly on 31 & 64 bit,

Ok, thanks.  I'll set it to 1.

> However I think the tm-sysv4.h change should stay.
> 
> If you look at the definition in tm-sysv4.h in the code ( see below ) it should
> still be identical for PPC even after preprocessing as SKIP_TRAMPOLINE_CODE is still defined for
> GDB_MULTI_ARCH_PARTIAL
> 
> However there will be a duplicate definitions compile error between gdbarch.h
> & tm-sysv4.h if you switch the multi arch level to 2 & you don't put this fix in.
> I don't see how this fix can cause problems.

Hmm, the mechanism was introduced around 2001-06-17 so likely postdates 
your code.

To explain the rationale.

Level 2 or (multi-arch tm) is intended strictly for a GDB developer's 
local sources.  It is there as an aid when performing maintenance on a 
target's multi-arch code.  It is expected that the maintainer will set 
multi-arch to 2, do a build, fix all the compilation errors caused by 
mult-arch clashes with methods that post date the target, revert the 
setting back to 1.

If tm-sysv4.h were to get the addition you suggest then this mechanism 
would be defeated for other maintainers - they would silently get the 
uninitialized multi-arch version of SKIP_TRAMPOLINE_CODE instead of a 
compilation error alerting them to the need for maintenance.

I should note, this isn't hypothetical - the mechanism was introduced in 
response to a mysterious solaris/sparc breakage.  A multi-arch macro 
overruled a tm macro and quietly broke that platforms gdb.

Any way, for these common files, I think it is better if each individual 
target addresses the problem separatly - #undef ... or better eliminate 
the #include pulling in the header.

enjoy,
Andrew