[PATCH] Incremental merge for ppc-vx6

[Douglas B Rupp]

This patch implements merging of sections created by -ffunction-sections
and -fdata-sections on ppc-vx6.

If the sections are not merged, gdb malfunctions when printing the
address of a runtime symbol.

The problem can be fixed in gdb (but not easily) for the WTX protocol
used for older vxworks targets but not for newer vxworks (e.g. vxworks7)
because the protocol is different and not under gdb control.

Future patch submissions will make use of this merge capability for
other vxworks6 targets, and also vxworks7 ports

Tested on x86-linux, and also locally tested on ppc-vx6 using the
AdaCore cross-testsuite.

I don't have write access, so if approved please apply when convenient.

--Douglas Rupp

[Alan Modra]

This patch implements merging of sections created by -ffunction-sections and
-fdata-sections on ppc-vx6.

Which means you are breaking ld --gc-sections if you use ld -r in any
intermediate step on the way to link a final executable. It's bad
enough that ld -r merges sections of like names, let alone merging
.text.* into .text.

If the sections are not merged, gdb malfunctions when printing the address
of a runtime symbol.

Presumably you are talking about a gdb problem only when trying to
debug kernel modules or similar objects that haven't undergone a final
link. If address are a problem, have you considered modifying ld -r
to instead not set section VMAs to zero? That would mean removing all
${RELOCATING-0} from elf.sc and modifying lang_insert_orphan to not
use "address = exp_intop (0)" for ld -r. If that cures the vxworks
gdb problem, I'd much rather remove a hack from GNU ld for Solaris
than add a new hack for vxworks.

The problem can be fixed in gdb (but not easily) for the WTX protocol used
for older vxworks targets but not for newer vxworks (e.g. vxworks7) because
the protocol is different and not under gdb control.

I find it hard to believe a host/target communication protocol has any
bearing on this problem.