This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: gdb & gdbserver for s390 31 & 64 bit
- To: Denis Joseph Barrow <DJBARROW at de dot ibm dot com>
- Subject: Re: gdb & gdbserver for s390 31 & 64 bit
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Fri, 28 Sep 2001 13:33:29 -0400
- Cc: gdb-patches at sourceware dot cygnus dot com
- References: <OFFEACF1CF.065C9A78-ONC1256AD5.003C16DD@de.ibm.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