From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: YAMAMOTO Mitsuharu Newsgroups: gmane.emacs.bugs Subject: bug#20614: Segmentation fault when building on Power8 Little Endian Date: Sat, 10 Oct 2015 10:40:39 +0900 Organization: Faculty of Science, Chiba University Message-ID: References: <555C3E3C.4090700@redhat.com> <5613894B.9070902@redhat.com> <5613B614.4090805@redhat.com> <83egh8xczn.fsf@gnu.org> <5614D522.9080900@redhat.com> <56150F86.2070706@redhat.com> <1486765641.67448157.1444310865021.JavaMail.zimbra@redhat.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Trace: ger.gmane.org 1444441298 18747 80.91.229.3 (10 Oct 2015 01:41:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 10 Oct 2015 01:41:38 +0000 (UTC) Cc: 20614@debbugs.gnu.org, Andreas Schwab To: Jaromir Capik Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Oct 10 03:41:27 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from eggs.gnu.org ([208.118.235.92]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZkjA5-0005Dg-Ts for geb-bug-gnu-emacs@m.gmane.org; Sat, 10 Oct 2015 03:41:26 +0200 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zkj9s-0007If-ST for geb-bug-gnu-emacs@m.gmane.org; Fri, 09 Oct 2015 21:41:25 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Original-Received: from lists.gnu.org ([2001:4830:134:3::11]:35184) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zkj9r-0007DY-Hp for geb-bug-gnu-emacs@m.gmane.org; Fri, 09 Oct 2015 21:41:12 -0400 Original-Received: from localhost ([::1]:43208 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zkj9r-0001yJ-AS for geb-bug-gnu-emacs@m.gmane.org; Fri, 09 Oct 2015 21:41:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34614) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zkj9n-0001y5-I4 for bug-gnu-emacs@gnu.org; Fri, 09 Oct 2015 21:41:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zkj9k-0006zF-0C for bug-gnu-emacs@gnu.org; Fri, 09 Oct 2015 21:41:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:45750) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zkj9j-0006yB-IZ for bug-gnu-emacs@gnu.org; Fri, 09 Oct 2015 21:41:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Zkj9j-0006Lr-5K for bug-gnu-emacs@gnu.org; Fri, 09 Oct 2015 21:41:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: YAMAMOTO Mitsuharu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 10 Oct 2015 01:41:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20614 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 20614-submit@debbugs.gnu.org id=B20614.144444125224390 (code B ref 20614); Sat, 10 Oct 2015 01:41:02 +0000 Original-Received: (at 20614) by debbugs.gnu.org; 10 Oct 2015 01:40:52 +0000 Original-Received: from localhost ([127.0.0.1]:34721 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zkj9X-0006LJ-Gw for submit@debbugs.gnu.org; Fri, 09 Oct 2015 21:40:51 -0400 Original-Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]:59353) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zkj9R-0006L3-Pa for 20614@debbugs.gnu.org; Fri, 09 Oct 2015 21:40:47 -0400 Original-Received: from fermat1.math.s.chiba-u.ac.jp (fermat [192.168.32.10]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id 9851FC0561; Sat, 10 Oct 2015 10:40:39 +0900 (JST) In-Reply-To: <1486765641.67448157.1444310865021.JavaMail.zimbra@redhat.com> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?UTF-8?Q?Shij=C5=8D?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 Xref: news.gmane.org gmane.emacs.bugs:107497 Archived-At: >>>>> On Thu, 8 Oct 2015 09:27:45 -0400 (EDT), Jaromir Capik said: >> > By the way .toc is still not fixed. It is specific to ppc64. And it >> > doesn't cause the segfault, though. It has a data and addresses. >> > It seems that unexec corrupted it:( >> >> I guess you mean the entry in >> https://bugzilla.redhat.com/show_bug.cgi?id=1265271#c16 . >> >> .rela.plt -> .plt >> .rela.toc -> empty string >> >> What does the above notation stand for? Is this the output of some >> tool? Then what would be the output for src/temacs? > That is a debug output I put in the relocation udoing loop where > the segfault occured when the section names were compared with listed > literals. > I was printing the section names of REL/RELA sections and their > PROGBITS/NOBITS counterparts. The segfault occured when accessing > 'old_section_names + NEW_SECTION_H (section.sh_info).sh_name' where > section.sh_name was '.rela.toc'. That means it was pointing to > an invalid address. When the .plt evaluation was fixed, the segfault > disappeared, but the NEW_SECTION_H (section.sh_info).sh_type is NULL > now and the section name is empty. The question is whether this is ok > or not. After looking at the complete list of sections it seems to be > a PPC specific oddity and I'm looking at the code to make myself sure > it doesn't need a special care. So, right now it requires no attention > from your side. Well, according to the output of "readelf -S ./temacs" shown in https://bugzilla.redhat.com/show_bug.cgi?id=1265271#c8 , the "Info" column, which seems to correspond to the sh_info member, for the .rela.toc section already points to the 0th (NULL) section even for temacs. So I think it is OK for the dumped executable to have the same value. Andreas, do you know if the change I proposed in http://lists.gnu.org/archive/html/bug-gnu-emacs/2015-10/msg00382.html does not break your fix for PowerPC64 in 2005 below? http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=825dad898e2d43eb2802c070fd4ce08816f907df Do you happen to have the output of "readelf -S temacs" or something like that as of your fix? YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp