bug#20614: Segmentation fault when building on Power8 Little Endian

[Petr Hracek <phracek@redhat.com>]

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

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


[-- Attachment #2: Type: text/html, Size: 6842 bytes --]