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