bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: YAMAMOTO Mitsuharu
Subject: bug#20614: Segmentation fault when building on Power8 Little Endian
Date: Sat, 10 Oct 2015 10:40:39 +0900
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (Shijō) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI)

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]