unexelf.c maybe broke between 21.1 and 21.2

unexelf.c maybe broke between 21.1 and 21.2

[Tom Horsley]

The unexelf.c in emacs-21.2 fails to build a functional object file on my
system. The resulting emacs always coredumps because none of its globals
actually have correctly initialized values in them.

When I copy the old emacs-21.1/src/unexelf.c file into my 21.2 directory and
rebuild, the resulting emacs seems to work perfectly.

Unfortunately, when I compare the old and new code, I see no obvious reason
for it to act any differently, perhaps it is just an accident that one works
and the other doesn't because the size of the executable changes with
different code and things come out aligned better, but I thought I should
report it anyway in case other folks have elf dumping problems, perhaps we
can figure out why someday (but there is no way I have enough time to debug
it now, especially since I came up with the workaround of uisng the old code
:-).
--
Tom.Horsley@mail.ccur.com                \\\\      Will no one rid me of
Concurrent Computers, Ft. Lauderdale, FL    \\\\     this troublesome
Me: http://home.att.net/~Tom.Horsley/          \\\\     autoconf?
Project Vote Smart: http://www.vote-smart.org     \\\\    !!!!!

Re: unexelf.c maybe broke between 21.1 and 21.2

[Eli Zaretskii]

On Wed, 28 Aug 2002, Tom Horsley wrote:

> The unexelf.c in emacs-21.2 fails to build a functional object file on my
> system. The resulting emacs always coredumps because none of its globals
> actually have correctly initialized values in them.

Thank you for your report, but please tell what system is that.  (M-x 
report-emacs-bug RET would provide this and other relevant info.)

RE: unexelf.c maybe broke between 21.1 and 21.2

[Horsley Tom]

> > The unexelf.c in emacs-21.2 fails to build a functional object file on
my
> > system. The resulting emacs always coredumps because none of its globals
> > actually have correctly initialized values in them.
> 
> Thank you for your report, but please tell what system is that.  (M-x 
> report-emacs-bug RET would provide this and other relevant info.)

I could tell you, but it wouldn't really help because it isn't a system
that emacs knows about anyway :-). (It is far less trouble to apply the
patches to each releases configure scripts than to try to find all the
lawyers I need to submit the patches permanently to the FSF).

However, here is what it reports:

In GNU Emacs 21.2.2 (powerpc-concurrent-powermax, Motif Version 2.1.0)
 of 2002-08-28 on amber2
configured using `configure  --prefix=/usr/tools/emacs-21.2 --with-x
--with-x-toolkit=motif --x-libraries=/usr/lib --x-includes=/usr/include'
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: nil
  locale-coding-system: nil
  default-enable-multibyte-characters: t

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

All I know for sure is that if I debug temacs and stop at the beginning
of the unexec routine, I can look at various local variables
(like Vmessage_buffer_name, etc) and see reasonable values.

If I debug emacs and look at the same global variables, they
contain trash.

Re: unexelf.c maybe broke between 21.1 and 21.2

[Eli Zaretskii]

> From: Horsley Tom <Tom.Horsley@ccur.com>
> Date: Wed, 28 Aug 2002 10:16:53 -0400
> 
> > > The unexelf.c in emacs-21.2 fails to build a functional object file on
> my
> > > system. The resulting emacs always coredumps because none of its globals
> > > actually have correctly initialized values in them.
> > 
> > Thank you for your report, but please tell what system is that.  (M-x 
> > report-emacs-bug RET would provide this and other relevant info.)
> 
> I could tell you, but it wouldn't really help because it isn't a system
> that emacs knows about anyway :-). (It is far less trouble to apply the
> patches to each releases configure scripts than to try to find all the
> lawyers I need to submit the patches permanently to the FSF).
> 
> However, here is what it reports:
> 
> In GNU Emacs 21.2.2 (powerpc-concurrent-powermax, Motif Version 2.1.0)
>  of 2002-08-28 on amber2

Could you see if the reason for the problems is the change in unexelf
which makes it use read/write instead of mmap?

Re: unexelf.c maybe broke between 21.1 and 21.2

[Richard Stallman]

    Unfortunately, when I compare the old and new code, I see no obvious reason
    for it to act any differently,

When you can't tell by reading the code why it fails,
the only thing left is to debug it with a debugger.
If you can debug what the two versions of unexec actually do
differently, you could perhaps fix it.

You could also see how the executable files differ.

RE: unexelf.c maybe broke between 21.1 and 21.2

[Horsley Tom]

[-- 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

RE: unexelf.c maybe broke between 21.1 and 21.2

[Horsley Tom]

> 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?

OK, I realize that question doesn't make sense either :-).
If I round up the address you'd think it would be more
likely to show up as following the new data section,
not less likely. Perhaps what really happened was
the new data section was rounded up more than the
if statement was rounding up the address of the old
section, so in this particular combination it didn't
look like it needed to be moved.

I still think the logic I replace the whole test with
make more sense :-).