Dump failure on Solaris 8

[YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>]

I experienced a failure in dumping on Solaris 8 with gcc 3.4.2.  The
dumped .data section was overwritten by the succeeding .symtab
section.  This is due to a part of this change:

2009-02-02  Andreas Schwab  <schwab@suse.de>

	* unexelf.c (unexec): Handle unaligned bss offset.

*** unexelf.c	2009/01/08 03:16:02	1.69
--- unexelf.c	2009/02/02 16:07:00	1.70

***************
*** 970,985 ****
        else
  	{
  	  /* Any section that was originally placed after the .bss
! 	     section should now be off by NEW_DATA2_SIZE.  If a
  	     section overlaps the .bss section, consider it to be
  	     placed after the .bss section.  Overlap can occur if the
  	     section just before .bss has less-strict alignment; this
  	     was observed between .symtab and .bss on Solaris 2.5.1
  	     (sparc) with GCC snapshot 960602.  */
  
! 	  if (NEW_SECTION_H (nn).sh_offset + NEW_SECTION_H (nn).sh_size
! 	      > new_data2_offset)
! 	    NEW_SECTION_H (nn).sh_offset += new_data2_size;
  
  	  /* Any section that was originally placed after the section
  	     header table should now be off by the size of one section
--- 980,994 ----
        else
  	{
  	  /* Any section that was originally placed after the .bss
! 	     section should now be off by NEW_DATA2_INCR.  If a
  	     section overlaps the .bss section, consider it to be
  	     placed after the .bss section.  Overlap can occur if the
  	     section just before .bss has less-strict alignment; this
  	     was observed between .symtab and .bss on Solaris 2.5.1
  	     (sparc) with GCC snapshot 960602.  */
  
! 	  if (NEW_SECTION_H (nn).sh_offset >= old_bss_offset)
! 	    NEW_SECTION_H (nn).sh_offset += new_data2_incr;
  
  	  /* Any section that was originally placed after the section
  	     header table should now be off by the size of one section

If I restore the if-condition (not including the then-clause) in the
hunk above, the dumping process works again.  Actually, the comment
above the if-condition seems to tell about this case.  The output of
"dump -h temacs" becomes as follows and the offset of the .bss section
(0x315158) is greater than that of the succeeding .symtab section
(0x315154).

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

src/temacs:

	   **** SECTION HEADER TABLE ****
[No]	Type	Flags	Addr         Offset       Size        	Name
	Link	Info	Adralgn      Entsize

[1]	1	2	0x100d4      0xd4         0x11         	.interp
	0	0	0x1          0            

[2]	5	2	0x100e8      0xe8         0xafa8       	.hash
	3	0	0x4          0x4          

[3]	11	2	0x1b090      0xb090       0x15f10      	.dynsym
	4	1	0x4          0x10         

[4]	3	34	0x30fa0      0x20fa0      0x167bf      	.dynstr
	0	0	0x1          0            

[5]	1879048190	2	0x47760      0x37760      0x1a0        	.SUNW_version
	4	12	0x4          0            

[6]	4	66	0x47900      0x37900      0x30         	.rela.got
	3	14	0x4          0xc          

[7]	4	66	0x47930      0x37930      0xc          	.rela.data
	3	17	0x4          0xc          

[8]	4	66	0x4793c      0x3793c      0x12c        	.rela.bss
	3	23	0x4          0xc          

[9]	4	66	0x47a68      0x37a68      0x17f4       	.rela.plt
	3	15	0x4          0xc          

[10]	1	6	0x4925c      0x3925c      0x1815f0     	.text
	0	0	0x4          0            

[11]	1	6	0x1ca84c     0x1ba84c     0x1c         	.init
	0	0	0x4          0            

[12]	1	6	0x1ca868     0x1ba868     0x14         	.fini
	0	0	0x4          0            

[13]	1	2	0x1ca880     0x1ba880     0x1aa78      	.rodata
	0	0	0x8          0            

[14]	1	3	0x1f52f8     0x1d52f8     0x34         	.got
	0	0	0x4          0x4          

[15]	1	7	0x1f532c     0x1d532c     0x1828       	.plt
	0	0	0x4          0xc          

[16]	6	3	0x1f6b54     0x1d6b54     0x170        	.dynamic
	4	0	0x4          0x8          

[17]	1	3	0x1f6cc8     0x1d6cc8     0x13e470     	.data
	0	0	0x8          0            

[18]	1	3	0x335138     0x315138     0x8          	.ctors
	0	0	0x4          0            

[19]	1	3	0x335140     0x315140     0x8          	.dtors
	0	0	0x4          0            

[20]	1	3	0x335148     0x315148     0x4          	.eh_frame
	0	0	0x4          0            

[21]	1	3	0x33514c     0x31514c     0x4          	.jcr
	0	0	0x4          0            

[22]	1	3	0x335150     0x315150     0x4          	.data.rel.local
	0	0	0x4          0            

[23]	8	3	0x335158     0x315158     0x42720      	.bss
	0	0	0x8          0            

[24]	2	0	0            0x315154     0x1c9d0      	.symtab
	25	1709	0x4          0x10         

[25]	3	32	0            0x331b24     0x1d406      	.strtab
	0	0	0x1          0            

[26]	1	0	0            0x34ef2a     0x1c0f       	.comment
	0	0	0x1          0            

[27]	1	0	0            0x350b3c     0x24         	.stab.index
	37	0	0x4          0xc          

[28]	1	0	0            0x350b60     0x11359      	.debug_abbrev
	0	0	0x1          0            

[29]	1	0	0            0x361eb9     0x1f35a7     	.debug_info
	0	0	0x1          0            

[30]	1	0	0            0x555460     0x12c356     	.debug_line
	0	0	0x1          0            

[31]	1	0	0            0x6817b8     0x15d50      	.debug_frame
	0	0	0x4          0            

[32]	1	0	0            0x697508     0x1aa7c      	.debug_pubnames
	0	0	0x1          0            

[33]	1	0	0            0x6b1f84     0xa00        	.debug_aranges
	0	0	0x1          0            

[34]	1	0	0            0x6b2984     0x14478      	.debug_ranges
	0	0	0x1          0            

[35]	1	0	0            0x6c6dfc     0xd033       	.debug_str
	0	0	0x1          0            

[36]	3	32	0            0x6d3e2f     0x14f        	.shstrtab
	0	0	0x1          0            

[37]	3	0	0            0x6d3f7e     0x176        	.stab.indexstr
	0	0	0x1          0