The bug with the new unexelf.c appears to be related to the following
glitch:

Using the old unexelf, I see the following section header info in the
resulting object file:

[20]	PBIT    WA-	0x302b6b00   0x2b6b00     0x1e1920     	.data
	0	0	0x100        0            

[21]	NOBI    WA-	0x30498420   0x498420     0            	.bss
	0	0	0x4          0            

[22]	PBIT    ---	0            0x498420     0x556c       	.debug_abbrev
	0	0	0x4          0            

[23]	PBIT    ---	0            0x49d98c     0x10b760     	.debug_info
	0	0	0x4          0            

Note that the .debug_abbrev section is not loaded into the program,
but does exist in the program file, and in this version of unexelf,
it has been shifted in the file to a position following the new .data
section created by unexelf.

Using the new unexelf, the resulting object file has section headers
that look like this:

[20]	PBIT    WA-	0x302b6c00   0x2b6c00     0x1e1920     	.data
	0	0	0x100        0            

[21]	NOBI    WA-	0x30498520   0x498520     0            	.bss
	0	0	0x4          0            

[22]	PBIT    ---	0            0x2b6b00     0x556c       	.debug_abbrev
	0	0	0x4          0            

[23]	PBIT    ---	0            0x49d98c     0x10b788     	.debug_info
	0	0	0x4          0            

BZZZT! The .debug_abbrev section resides on disk at the same location as the
new .data section. Apparently the new unexelf neglects to shift that debug
section down in the file to make room for the new .data section (but the
immediately following debug section did get shifted).

In the original temacs file, the sections look like:

[20]	NOBI    WA-	0x302b6c00   0x2b6b00     0x4191c      	.bss
	0	0	0x100        0            

[21]	PBIT    ---	0            0x2b6b00     0x556c       	.debug_abbrev
	0	0	0x4          0            

[22]	PBIT    ---	0            0x2bc06c     0x10b788     	.debug_info
	0	0	0x4          0            

The key may be that the file offset of .debug_abbrev is exactly equal to
the .bss section (which makes sense since .bss isn't in the file), and I do
see some logic in unexelf doing a > instead of >= comparison, but I still
can't figure why the old unexelf works, because it appears to have identical
logic, but at least I see what is happening to the file.

This patch also seems to fix the problem (even though it is to logic that is
unchanged from the old version :-):

*** unexelf.c.orig	Mon Jan 28 11:33:22 2002
--- unexelf.c	Wed Aug 28 19:54:22 2002
***************
*** 986,994 ****
--- 986,1002 ----
  	      >= OLD_SECTION_H (old_bss_index-1).sh_offset)
  	    NEW_SECTION_H (nn).sh_offset += new_data2_size;
  #else
+ 	  /* This code makes absolutely no sense to me. What does
+ 	     rounding have to do with anything? The section either
+ 	     comes after the bss section or it doesn't. Right? */
+ #if 0
  	  if (round_up (NEW_SECTION_H (nn).sh_offset,
  			OLD_SECTION_H (old_bss_index).sh_addralign)
  	      >= new_data2_offset)
+ 	    NEW_SECTION_H (nn).sh_offset += new_data2_size;
+ #endif
+ 	  if (NEW_SECTION_H (nn).sh_offset >= 
+ 	      OLD_SECTION_H (old_bss_index).sh_offset)
  	    NEW_SECTION_H (nn).sh_offset += new_data2_size;
  #endif
  	  /* Any section that was originally placed after the section