RE: unexelf.c maybe broke between 21.1 and 21.2

[Horsley Tom <Tom.Horsley@ccur.com>]

[-- Attachment #1: Type: text/plain, Size: 1112 bytes --]

I did more debugging on this last night, and found an
if statement that made no sense at all to me. It is
checking to see if an old section needs to be moved
because it came after the point where the new section
was inserted, and the if test is first rounding up
the old section file offset. Huh? The old section
either started after the new section or it didn't.
What on earth does rounding the offset up accomplish
other than failing to move a section that should
have been moved? (which is what happened to me :-).
Even if rounding makes sense for some reason I
can't understand, it is using the alignment
requirement from the old bss section to round
this completely different section which may have
a completely different alignment requirement.
Again, Huh?. Anyway, the only reason the old code
worked was because it was a different size
so the file layout happened to be one that worked
despite the silly logic.

I'm attaching (because outlook persistently screws
up line wrapping :-) a text file with all the
analysis showing what happened and the patch
I applied to unexelf.c which made it work for
me.


[-- Attachment #2: dabug.txt --]
[-- Type: text/plain, Size: 3342 bytes --]

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