While debugging a dump problem, I found a compiler bug in egcs-1.1.2-16 on (at least) sparc (an ultra if it matters). Test program coming by e-mail.
As long as you were compling for sparc32 (which is the default), it shouldn't matter whether it is an Ultra. Looking forward to seeing your test case.
*** Bug 3272 has been marked as a duplicate of this bug. *** Local backups work, but remote backups fail. Consider the output from the command run on host mowgli, doing a remote backup to itself: [The outcome is the same when doing this between different hosts] /sbin/dump 0f mowgli:/dev/st1 / DUMP: Date of this level 0 dump: Wed Jun 2 12:03:14 1999 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/sda1 (/) to /dev/st1 on host mowgli DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 62627 tape blocks on 1.61 tape(s). /sbin/dump: Lost connection to remote host. DUMP: Bad return code from dump: 1 The problem turns out to be that dump tries to invoke /sbin/rmt as rmt, but does not find it because /sbin is not in the default path. dump envokes rmt using an rcmd call [dumprmt.c line159]. The argument of the remote program to run is set in compat/include/pathnames.h line 49 as #define _PATH_RMT "rmt" The problem is that the rmt program /sbin/rmt is NOT in the default path, and so dump connects to a program that does not exist. Unfortunately, the rcmd call does not fail, nor does the first write to the pipe opened by the rcmd call. The first error is encountered when trying to read the reply from the first write (which is the command to instruct rmt to open the specified device file). This leads to the very misleading error message "lost connection" shown above. Multiple solutions are possible. 1) _PATH_RMT can be defined to be "/etc/rmt" instead of "rmt". This is the solution used by tar-1.12 to find rmt. On all the hosts I checked this appears to be a symbolic link to the real location of rmt [HP-UX, SunOS, Solaris, Linux/Redhat, Linux/Debian]. The only exception I found was AIX, and that is just a weird OS anyway. I figure if it is good enough for tar, it is good enough for me. 2) Change the default path to include /sbin. This way rcmd will find rmt OK. This does not appear to be a good idea since it could have a bunch of side effects. 3) Link /sbin/rmt to /bin/rmt or move rmt to the /bin. This appears to be a good solution but since the /etc/rmt link is already required for tar, this seems to be a proliferation of links that is unnecessary. Any of the above solutions solve the problem, and you could probably find better ones, but #1 appears to be the preferred solution. Here is a patch file: --------------------------------------------------------- --- dump-0.4b4/compat/include/pathnames.h.0 +++ dump-0.4b4/compat/include/pathnames.h @@ -46,4 +46,4 @@ #define _PATH_DTMP "/etc/dtmp" #define _PATH_DUMPDATES "/etc/dumpdates" #define _PATH_LOCK "/tmp/dumplockXXXXXX" -#define _PATH_RMT "rmt" +#define _PATH_RMT "/etc/rmt" --------------------------------------------------------- It is probably worth adding to the dump docs that the /etc/rmt linkis needed so that if the remote host is AIX or something weird that there is a pointer However, I am concerned that there is a problem somewhere in the rcmd code that should report the failure earlier on and somehow does not, leading to the misleading error message. This is probably worth investigating.
Please disregard the wrong duplicate (fat fingers).
I believe I've verified this on alpha egcs also.
OK, I was able to verify that this test case was generating bad RTL. Jeff Law's 29 Jun fix to emit_block_move would seem to exactly match this situation - block moves with a postincrement as an argument. This is the fix that I already added to egcs-1.1.2-17 as a fix for bugzilla #3971, and the current (4281) test case works if I use egcs-1.1.2-17. So in summary: upgrade to egcs-1.1.2-17.