From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Horsley Tom Newsgroups: gmane.emacs.bugs Subject: RE: unexelf.c maybe broke between 21.1 and 21.2 Date: Thu, 29 Aug 2002 07:58:42 -0400 Sender: bug-gnu-emacs-admin@gnu.org Message-ID: NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C24F53.6B6ADAC0" X-Trace: main.gmane.org 1030622307 27875 127.0.0.1 (29 Aug 2002 11:58:27 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 29 Aug 2002 11:58:27 +0000 (UTC) Cc: bug-gnu-emacs@gnu.org Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 17kNwK-0007FA-00 for ; Thu, 29 Aug 2002 13:58:20 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 17kNxi-0003aX-00; Thu, 29 Aug 2002 07:59:46 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17kNwq-0003Yy-00 for bug-gnu-emacs@gnu.org; Thu, 29 Aug 2002 07:58:52 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17kNwn-0003Ym-00 for bug-gnu-emacs@gnu.org; Thu, 29 Aug 2002 07:58:51 -0400 Original-Received: from mail.ccur.com ([208.248.32.212] helo=exchange.ccur.com) by monty-python.gnu.org with esmtp (Exim 4.10) id 17kNwn-0003Yi-00 for bug-gnu-emacs@gnu.org; Thu, 29 Aug 2002 07:58:49 -0400 Original-Received: by exchange.ccur.com with Internet Mail Service (5.5.2653.19) id ; Thu, 29 Aug 2002 07:58:48 -0400 Original-To: 'Eli Zaretskii' , Horsley Tom X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: bug-gnu-emacs-admin@gnu.org X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Bug reports for GNU Emacs, the Swiss army knife of text editors List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.bugs:3353 X-Report-Spam: http://spam.gmane.org/gmane.emacs.bugs:3353 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C24F53.6B6ADAC0 Content-Type: text/plain; charset="iso-8859-1" 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. ------_=_NextPart_000_01C24F53.6B6ADAC0 Content-Type: text/plain; name="dabug.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="dabug.txt" The bug with the new unexelf.c appears to be related to the = following=0A= glitch:=0A= =0A= Using the old unexelf, I see the following section header info in = the=0A= resulting object file:=0A= =0A= [20] PBIT WA- 0x302b6b00 0x2b6b00 0x1e1920 .data=0A= 0 0 0x100 0 =0A= =0A= [21] NOBI WA- 0x30498420 0x498420 0 .bss=0A= 0 0 0x4 0 =0A= =0A= [22] PBIT --- 0 0x498420 0x556c = .debug_abbrev=0A= 0 0 0x4 0 =0A= =0A= [23] PBIT --- 0 0x49d98c 0x10b760 .debug_info=0A= 0 0 0x4 0 =0A= =0A= Note that the .debug_abbrev section is not loaded into the program,=0A= but does exist in the program file, and in this version of unexelf,=0A= it has been shifted in the file to a position following the new = .data=0A= section created by unexelf.=0A= =0A= Using the new unexelf, the resulting object file has section headers=0A= that look like this:=0A= =0A= [20] PBIT WA- 0x302b6c00 0x2b6c00 0x1e1920 .data=0A= 0 0 0x100 0 =0A= =0A= [21] NOBI WA- 0x30498520 0x498520 0 .bss=0A= 0 0 0x4 0 =0A= =0A= [22] PBIT --- 0 0x2b6b00 0x556c = .debug_abbrev=0A= 0 0 0x4 0 =0A= =0A= [23] PBIT --- 0 0x49d98c 0x10b788 .debug_info=0A= 0 0 0x4 0 =0A= =0A= BZZZT! The .debug_abbrev section resides on disk at the same location = as the=0A= new .data section. Apparently the new unexelf neglects to shift that = debug=0A= section down in the file to make room for the new .data section (but = the=0A= immediately following debug section did get shifted).=0A= =0A= In the original temacs file, the sections look like:=0A= =0A= [20] NOBI WA- 0x302b6c00 0x2b6b00 0x4191c .bss=0A= 0 0 0x100 0 =0A= =0A= [21] PBIT --- 0 0x2b6b00 0x556c = .debug_abbrev=0A= 0 0 0x4 0 =0A= =0A= [22] PBIT --- 0 0x2bc06c 0x10b788 .debug_info=0A= 0 0 0x4 0 =0A= =0A= The key may be that the file offset of .debug_abbrev is exactly equal = to=0A= the .bss section (which makes sense since .bss isn't in the file), and = I do=0A= see some logic in unexelf doing a > instead of >=3D comparison, but I = still=0A= can't figure why the old unexelf works, because it appears to have = identical=0A= logic, but at least I see what is happening to the file.=0A= =0A= This patch also seems to fix the problem (even though it is to logic = that is=0A= unchanged from the old version :-):=0A= =0A= *** unexelf.c.orig Mon Jan 28 11:33:22 2002=0A= --- unexelf.c Wed Aug 28 19:54:22 2002=0A= ***************=0A= *** 986,994 ****=0A= --- 986,1002 ----=0A= >=3D OLD_SECTION_H (old_bss_index-1).sh_offset)=0A= NEW_SECTION_H (nn).sh_offset +=3D new_data2_size;=0A= #else=0A= + /* This code makes absolutely no sense to me. What does=0A= + rounding have to do with anything? The section either=0A= + comes after the bss section or it doesn't. Right? */=0A= + #if 0=0A= if (round_up (NEW_SECTION_H (nn).sh_offset,=0A= OLD_SECTION_H (old_bss_index).sh_addralign)=0A= >=3D new_data2_offset)=0A= + NEW_SECTION_H (nn).sh_offset +=3D new_data2_size;=0A= + #endif=0A= + if (NEW_SECTION_H (nn).sh_offset >=3D =0A= + OLD_SECTION_H (old_bss_index).sh_offset)=0A= NEW_SECTION_H (nn).sh_offset +=3D new_data2_size;=0A= #endif=0A= /* Any section that was originally placed after the section=0A= ------_=_NextPart_000_01C24F53.6B6ADAC0--