GNU bug report logs - #20614
Segmentation fault when building on Power8 Little Endian

Previous Next

Full log

View this message in rfc822 format

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: Jaromir Capik <jcapik <at> redhat.com>
Cc: Petr Hracek <phracek <at> redhat.com>, Eli Zaretskii <eliz <at> gnu.org>, 20614 <at> debbugs.gnu.org, YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>, Andreas Schwab <schwab <at> suse.de>
Subject: bug#20614: Segmentation fault when building on Power8 Little Endian
Date: Sat, 10 Oct 2015 10:40:39 +0900

>>>>> On Thu, 8 Oct 2015 09:27:45 -0400 (EDT), Jaromir Capik <jcapik <at> redhat.com> 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 <at> math.s.chiba-u.ac.jp

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.