From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Petr Hracek Newsgroups: gmane.emacs.bugs Subject: bug#20614: Segmentation fault when building on Power8 Little Endian Date: Wed, 23 Sep 2015 13:00:03 +0200 Message-ID: <56028633.3000303@redhat.com> References: <555C3E3C.4090700@redhat.com> <1gpp5vi5xn.fsf@fencepost.gnu.org> <555DD5D3.3020207@redhat.com> <55A3A08A.9060905@redhat.com> <55A4BFB7.3010208@redhat.com> <55F95275.4040209@redhat.com> <56012AA6.7010702@redhat.com> <56025D9A.9080608@redhat.com> <838u7xlbsn.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------040005000304090609070605" X-Trace: ger.gmane.org 1443006082 25014 80.91.229.3 (23 Sep 2015 11:01:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 23 Sep 2015 11:01:22 +0000 (UTC) Cc: 20614@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Sep 23 13:01:13 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZehnU-0008OT-DF for geb-bug-gnu-emacs@m.gmane.org; Wed, 23 Sep 2015 13:01:12 +0200 Original-Received: from localhost ([::1]:47027 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZehnT-0000S3-QE for geb-bug-gnu-emacs@m.gmane.org; Wed, 23 Sep 2015 07:01:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42273) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZehnP-0000Rk-Rs for bug-gnu-emacs@gnu.org; Wed, 23 Sep 2015 07:01:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZehnL-0001WO-0G for bug-gnu-emacs@gnu.org; Wed, 23 Sep 2015 07:01:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:50165) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZehnK-0001W3-U5 for bug-gnu-emacs@gnu.org; Wed, 23 Sep 2015 07:01:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZehnK-0007Yu-Iy for bug-gnu-emacs@gnu.org; Wed, 23 Sep 2015 07:01:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Petr Hracek Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 23 Sep 2015 11:01: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.144300601728957 (code B ref 20614); Wed, 23 Sep 2015 11:01:02 +0000 Original-Received: (at 20614) by debbugs.gnu.org; 23 Sep 2015 11:00:17 +0000 Original-Received: from localhost ([127.0.0.1]:42375 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zehma-0007Wx-Gk for submit@debbugs.gnu.org; Wed, 23 Sep 2015 07:00:17 -0400 Original-Received: from mx1.redhat.com ([209.132.183.28]:55122) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZehmV-0007Vj-S1 for 20614@debbugs.gnu.org; Wed, 23 Sep 2015 07:00:14 -0400 Original-Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id C013191586; Wed, 23 Sep 2015 11:00:05 +0000 (UTC) Original-Received: from [10.34.4.133] (unused-4-133.brq.redhat.com [10.34.4.133]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8NB03hY003877; Wed, 23 Sep 2015 07:00:04 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 In-Reply-To: <838u7xlbsn.fsf@gnu.org> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 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-Received-From: 208.118.235.43 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 Xref: news.gmane.org gmane.emacs.bugs:106825 Archived-At: This is a multi-part message in MIME format. --------------040005000304090609070605 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 09/23/2015 11:34 AM, Eli Zaretskii wrote: >> From: Petr Hracek >> Date: Wed, 23 Sep 2015 10:06:50 +0200 >> >> Is there any possibility how to suppress dumping emacs? >> Shall I add something to ./configure script or even to make? > You could try adding -DCANNOT_DUMP=1 to preprocessor command-line > switches. But it would be much better if you try figuring out why it > segfaults, then we might be able to come up with a solution that > preserves the dumping capability. Well, I will try to summarize it. And sorry for my english. I would like to build emacs also under ppc64le architecture for RHEL-7 system All other architecture seems to be working well. I have add a patch to our emacs downstream package which comments row http://git.savannah.gnu.org/cgit/emacs.git/tree/src/unexelf.c?h=emacs-24#n869 so that I did not see message like: Dumping under the name emacs emacs: Program segment above .bss in /builddir/build/BUILD/emacs-24.3/build-gtk/src/temacs make[2]: *** [bootstrap-emacs] Error 1 Patch looks like: |diff --git a/src/unexelf.c b/src/unexelf.c index d365940..69b0237 100644 --- a/src/unexelf.c +++ b/src/unexelf.c @@ -853,11 +853,15 @@ unexec (const char *new_name, const char *old_name) when the executable doesn't have an sbss section. */ if (old_sbss_index != -1) #endif /* __sgi */ - if (NEW_PROGRAM_H (n).p_vaddr + NEW_PROGRAM_H (n).p_filesz + // This was commented out because we are not able to build it + // under PPC64LE. + /*if (NEW_PROGRAM_H (n).p_vaddr + NEW_PROGRAM_H (n).p_filesz > (old_sbss_index == -1 ? old_bss_addr : round_up (old_bss_addr, alignment))) fatal ("Program segment above .bss in %s\n", old_name, 0); + */ + if (NEW_PROGRAM_H (n).p_type == PT_LOAD && (round_up ((NEW_PROGRAM_H (n)).p_vaddr @@ -866,8 +870,8 @@ unexec (const char *new_name, const char *old_name) == round_up (old_bss_addr, alignment))) break; } - if (n < 0) - fatal ("Couldn't find segment next to .bss in %s\n", old_name, 0); + //if (n < 0) + //fatal ("Couldn't find segment next to .bss in %s\n", old_name, 0); /* Make sure that the size includes any padding before the old .bss section. */| And I KNOW that this is TOTALLY wrong and weird workaround, though. 1) binutils-2.23.52.0.1-30.ael7b.ppc64le all works fine and emacs is packaged on ppc64le architecture gcc-4.8.3-9.el7.ppc64le glibc-2.17-102.el7.ppc64le 2) binutils-2.23.52.0.1-44.el7.ppc64le with "weird" patch I am able to packaged emacs on ppc64le architecture gcc-4.8.3-9.el7.ppc64le glibc-2.17-85.ael7b.ppc64le Nowadays with binutils-2.23.52.0.1-54 I am not able to build emacs at all. What I can do is to add several tracking information like traces which can be added to source code during the build. Any advice would be welcome and I will do it really soon. Question from my side, how to add traces so that I am able to see data? I have seen that there were several patches done by Paul Eggert like: http://git.savannah.gnu.org/cgit/emacs.git/commit/src/unexelf.c?h=emacs-24&id=f269bc61c10320cf020e0751e6643fbbb5f059a2 http://git.savannah.gnu.org/cgit/emacs.git/commit/src/unexelf.c?h=emacs-24&id=5ee94506f6ee4f5142bfeabc9409f95e370d38e3 But I don't think that there are relevant. Unfortunately I don't have a deep knowledge about ELF and .data or .bss segments which are mentioned in file unexelf.c My colleagues told me if there is any possibility to remove unexelf.c file and replace them with "mapping a file with pre-compiled byte code." But I don't understand it at all. Sorry folks. I would like to send a patch to upstream for solving it but I don't have an idea how. -- Petr Hracek Software Engineer Developer Experience Red Hat, Inc Mob: +420777056169 email: phracek@redhat.com --------------040005000304090609070605 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit
On 09/23/2015 11:34 AM, Eli Zaretskii wrote:
From: Petr Hracek <phracek@redhat.com>
Date: Wed, 23 Sep 2015 10:06:50 +0200

Is there any possibility how to suppress dumping emacs?
Shall I add something to ./configure script or even to make?

You could try adding -DCANNOT_DUMP=1 to preprocessor command-line
switches.  But it would be much better if you try figuring out why it
segfaults, then we might be able to come up with a solution that
preserves the dumping capability.
Well, I will try to summarize it. And sorry for my english.
I would like to build emacs also under ppc64le architecture for RHEL-7 system
All other architecture seems to be working well.

I have add a patch to our emacs downstream package which comments
row http://git.savannah.gnu.org/cgit/emacs.git/tree/src/unexelf.c?h=emacs-24#n869
so that I did not see message like:
Dumping under the name emacs
emacs: Program segment above .bss in /builddir/build/BUILD/emacs-24.3/build-gtk/src/temacs
make[2]: *** [bootstrap-emacs] Error 1
Patch looks like:
diff --git a/src/unexelf.c b/src/unexelf.c
index d365940..69b0237 100644
--- a/src/unexelf.c
+++ b/src/unexelf.c
@@ -853,11 +853,15 @@ unexec (const char *new_name, const char *old_name)
 	     when the executable doesn't have an sbss section.  */
       if (old_sbss_index != -1)
 #endif /* __sgi */
-      if (NEW_PROGRAM_H (n).p_vaddr + NEW_PROGRAM_H (n).p_filesz
+      // This was commented out because we are not able to build it
+      // under PPC64LE.
+      /*if (NEW_PROGRAM_H (n).p_vaddr + NEW_PROGRAM_H (n).p_filesz
 	  > (old_sbss_index == -1
 	     ? old_bss_addr
 	     : round_up (old_bss_addr, alignment)))
 	  fatal ("Program segment above .bss in %s\n", old_name, 0);
+      */
+
 
       if (NEW_PROGRAM_H (n).p_type == PT_LOAD
 	  && (round_up ((NEW_PROGRAM_H (n)).p_vaddr
@@ -866,8 +870,8 @@ unexec (const char *new_name, const char *old_name)
 	      == round_up (old_bss_addr, alignment)))
 	break;
     }
-  if (n < 0)
-    fatal ("Couldn't find segment next to .bss in %s\n", old_name, 0);
+  //if (n < 0)
+   //fatal ("Couldn't find segment next to .bss in %s\n", old_name, 0);
 
   /* Make sure that the size includes any padding before the old .bss
      section.  */

And I KNOW that this is TOTALLY wrong and weird workaround, though.

1) binutils-2.23.52.0.1-30.ael7b.ppc64le all works fine and emacs is packaged on ppc64le architecture
gcc-4.8.3-9.el7.ppc64le
glibc-2.17-102.el7.ppc64le
2) binutils-2.23.52.0.1-44.el7.ppc64le with "weird" patch I am able to packaged emacs on ppc64le architecture
gcc-4.8.3-9.el7.ppc64le
glibc-2.17-85.ael7b.ppc64le

Nowadays with binutils-2.23.52.0.1-54 I am not able to build emacs at all.

What I can do is to add several tracking information like traces which can be added to source code during the build.
Any advice would be welcome and I will do it really soon.
Question from my side, how to add traces so that I am able to see data?

I have seen that there were several patches done by Paul Eggert like:
http://git.savannah.gnu.org/cgit/emacs.git/commit/src/unexelf.c?h=emacs-24&id=f269bc61c10320cf020e0751e6643fbbb5f059a2
http://git.savannah.gnu.org/cgit/emacs.git/commit/src/unexelf.c?h=emacs-24&id=5ee94506f6ee4f5142bfeabc9409f95e370d38e3

But I don't think that there are relevant.

Unfortunately I don't have a deep knowledge about ELF and .data or .bss segments which are mentioned in file unexelf.c
My colleagues told me if there is any possibility to remove unexelf.c file and replace them with "mapping a file with pre-compiled byte code."
But I don't understand it at all. Sorry folks.

I would like to send a patch to upstream for solving it but I don't have an idea how.
-- 
Petr Hracek
Software Engineer
Developer Experience
Red Hat, Inc
Mob: +420777056169
email: phracek@redhat.com
--------------040005000304090609070605--