OK, more info. All cut and pasted (with bits moved and removed) from an email.
For Nios I, there was no direct tool support for multiprocessor systems. The user could make multiple processors, but the tools had no inherent knowledge of how to keep them from interfering with each other. The customer is right that there is a lot of hand-massaging to do for Nios I.
The best way to prevent conflict is to give the CPUs different reset and interrupt vectors (with enough room for code/vector table), and by targeting the SDKs to compile in different memory components, and to check the objdumps for overlap. Unless the customer is a master of GCC linking, this is probably the only thing they can do.
For Nios II, the IDE (not the Legacy SDK) has a minimal knowledge of multiprocessor systems-- enough to prevent some basic conflicts. The CPUs still need to be set to different reset and interrupt vectors (very important that they are!). The exception address has a secondary function in that it is used by the Nios II IDE as a guideline on where to target elfs. I think if you set your exception address half-way through a memory, you'll find that the Nios II IDE will compile the elf for the area after the exception vector. When linking, the IDE does a better job of sharing memories between CPUs, but I'm not certain exactly how.