From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7152 Path: news.gmane.org!not-for-mail From: stephen Turner Newsgroups: gmane.comp.compilers.pcc,gmane.linux.lib.musl.general Subject: Re: [musl] segfault in libc.so Date: Thu, 5 Mar 2015 13:45:02 -0500 Message-ID: References: <20150303114639.GF16260@port70.net> <20150305042548.GN23507@brightrain.aerifal.cx> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3065728641968170722==" X-Trace: ger.gmane.org 1425581137 16933 80.91.229.3 (5 Mar 2015 18:45:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 5 Mar 2015 18:45:37 +0000 (UTC) To: musl@lists.openwall.com, pcc@lists.ludd.ltu.se Original-X-From: pcc-bounces+gccp-pcc-list=gmane.org@lists.ludd.ltu.se Thu Mar 05 19:45:33 2015 Return-path: Envelope-to: gccp-pcc-list@gmane.org Original-Received: from mail.ludd.ltu.se ([130.240.16.30]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YTaly-0000Ut-Ev for gccp-pcc-list@gmane.org; Thu, 05 Mar 2015 19:45:26 +0100 Original-Received: from mail.ludd.ltu.se (localhost [127.0.0.1]) by mail.ludd.ltu.se (Postfix) with ESMTP id CF3E7742D8 for ; Thu, 5 Mar 2015 19:45:25 +0100 (CET) Original-Received: from nospam.ludd.ltu.se (nospam.ludd.ltu.se [130.240.16.32]) by mail.ludd.ltu.se (Postfix) with ESMTP id 83907740F5 for ; Thu, 5 Mar 2015 19:45:10 +0100 (CET) Original-Received: from localhost (localhost [127.0.0.1]) by nospam.ludd.ltu.se (Postfix) with ESMTP id 65F5E2273A for ; Thu, 5 Mar 2015 19:45:10 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at nospam.ludd.ltu.se X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-9999 required=10.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Original-Received: from nospam.ludd.ltu.se ([127.0.0.1]) by localhost (nospam.ludd.ltu.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vy9v1Jhf7XQf for ; Thu, 5 Mar 2015 19:45:05 +0100 (CET) Original-Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) by nospam.ludd.ltu.se (Postfix) with ESMTPS for ; Thu, 5 Mar 2015 19:45:05 +0100 (CET) Original-Received: by yhot59 with SMTP id t59so9893896yho.5 for ; Thu, 05 Mar 2015 10:45:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=t5cfNU/EXdosSsBuuQGSSNg/NJzjZLLRMtO3TnM85Y0=; b=oyeD2CUozv829dB4TcEFTI3UZ6sXB75nx/mIDW/d8IcyPTGtSgEFvkyyl77xO9lYKZ VzR3XGKKfrn8acb+L0VUXKn5MTX2zMOZuMXAeFy8DP37DrECqWOSKD334OKFiHoYQgO9 Xq2XYEQdzgU1CVfHdqx88fG8sAMPKWiTlOZZ+Od+OQKjdYVs/P4/33mshC/oo68nhctn f7mGKrcw1adO9ouDGibBAPlqdwiLoHkh4gtFcq/jBwhRkZtWbVYOAGw0XRpuOyIUYbyU k/Dul9G/bbdI7dUpJFNgLgaT8j1VlHJjqw1OL5AlPppWhGoHRdycPhiMuLd8mReBWnQV pKAA== X-Received: by 10.236.30.98 with SMTP id j62mr8370549yha.105.1425581102374; Thu, 05 Mar 2015 10:45:02 -0800 (PST) Original-Received: by 10.170.190.193 with HTTP; Thu, 5 Mar 2015 10:45:02 -0800 (PST) In-Reply-To: X-BeenThere: pcc@lists.ludd.ltu.se X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions about PCC List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , Errors-To: pcc-bounces+gccp-pcc-list=gmane.org@lists.ludd.ltu.se Original-Sender: "Pcc" Xref: news.gmane.org gmane.comp.compilers.pcc:3539 gmane.linux.lib.musl.general:7152 Archived-At: --===============3065728641968170722== Content-Type: multipart/alternative; boundary=089e0118388234a24f05108ef720 --089e0118388234a24f05108ef720 Content-Type: text/plain; charset=UTF-8 This is what i have found so far on the libc.so corruption now also known to involve libfl.so.2. Im copying both musl (for an update) and pcc however this appears to be a pcc specific bug and this email is mostly for that purpose. > What I know so far is > > * the corruption appears to be limited to libc.so only and once a bad > libc.so is replaced with a glibc/gcc built libc.so everything is fine. > I have to correct this statement, i have now found a second corrupted lib after running a few compiles, libfl.so.2 generated by binutils for the use of atleast the "ar" program the error however when ar is reported is said to be in libc.so, knowing better at this point i "ldd ar" and found that lib and when i "ldd libfl.so.2" i get the output yylex symbol not found. > * Libc.a gets smaller when compilled by pcc while libc.so gets bigger. > Minute as it may be. > * Everything can be compiled and work dynamic by pcc except libc.so (what > makes it so differant from libc.a and everything else?) > * everything on/before pcc 20150101 returns a visible error when compiling > musl that I dont recall atm but will report tomorrow (back to 20141201 > atleast) > the error is error /usr/libexec/ccom terminated with status 1 recipe for target src/complex/catanf.lo faild compiler error bad STCALL hidden reg I attached the strace from this process which failed in musl-libc and per your suggestion Rich im also looking into the use of gdb now as well. Since this is a older version of pcc (albiet not by much) I wonder if this STCALL reg could point to the corruption by pcc? > * version 20150110 musl compiles (possibly corrupted havent checked) but > make4.0 breaks, again visibly in jobs.o > * version 20150120 everything compiled (but libc.so is corrupt) same for > the latest version. > > Your on the pcc list too so im sure you have noticed no response yet. I > read that one person is away, I didnt pay attention to the name but im > guessing one of the main programmers. > > So I have shown today that its not a musl issue, though I doubted it was > anyways, no one has reported a corruption issue. But I found these details > that will hopefully help identify the root issue eventually. > > Thanks > Stephen > The errors im finding at this point are 2 and 3 generations deep, I build a static system with gcc/glibc on debian and move everything to a initrd. I rebuild in this environment to be a dynamic musl-libc create another initrd and its with this dynamic initrd building my 3rd gen (or second dynamic) i get my breakage. Thanks for your time, I hope to hear back from someone about fixing pcc soon. Stephen --089e0118388234a24f05108ef720 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is what i have found so far on the libc.so corruption now also known = to involve libfl.so.2. Im copying both musl (for an update) and pcc however= this appears to be a pcc specific bug and this email is mostly for that pu= rpose.

What I know so far is=C2= =A0

* the corruption appears to be limited to libc.so only and once a bad libc.= so is replaced with a glibc/gcc built libc.so everything is fine.

I have to correct this statement, i have now found a = second corrupted lib after running a few compiles, libfl.so.2 generated by = binutils for the use of atleast the "ar" program

the error however when ar is reported is said to be in libc.so, kn= owing better at this point i "ldd ar" and found that lib and when= i "ldd libfl.so.2" i get the output yylex symbol not found.=C2= =A0

* Libc.a gets smaller when compill= ed by pcc while libc.so gets bigger. Minute as it may be.
* Everything can be compiled and work dynamic by pcc except libc.so (what m= akes it so differant from libc.a and everything else?)
* everything on/before pcc 20150101 returns a visible error when compiling = musl that I dont recall atm but will report tomorrow (back to 20141201 atle= ast)

the error is=C2=A0
error /usr/libe= xec/ccom terminated with status 1
recipe for target src/complex/c= atanf.lo faild
compiler error bad STCALL hidden reg
I a= ttached the strace from this process which failed in musl-libc and per your= suggestion Rich im also looking into the use of gdb now as well. Since thi= s is a older version of pcc (albiet not by much) I wonder if this STCALL re= g could point to the corruption by pcc?
=C2=A0

* version 20150110 musl compiles (possibly corrupted havent checked) but ma= ke4.0 breaks, again visibly in jobs.o
* version 20150120 everything compiled (but libc.so is corrupt) same for th= e latest version.

Your on the pcc list too so im sure you have noticed no resp= onse yet. I read that one person is away, I didnt pay attention to the name= but im guessing one of the main programmers.

So I have shown today that its not a musl issue, though I do= ubted it was anyways, no one has reported a corruption issue. But I found t= hese details that will hopefully help identify the root issue eventually.

Thanks
Stephen

The errors im finding at this point are 2 and 3 generati= ons deep, I build a static system with gcc/glibc on debian and move everyth= ing to a initrd. I rebuild in this environment to be a dynamic musl-libc cr= eate another initrd and its with this dynamic initrd building my 3rd gen (o= r second dynamic) i get my breakage.

Thanks for your time, I hope to hear back fr= om someone about fixing pcc soon.

Stephen
--089e0118388234a24f05108ef720-- --===============3065728641968170722== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pcc mailing list Pcc@lists.ludd.ltu.se https://lists.ludd.ltu.se/cgi-bin/mailman/listinfo/pcc --===============3065728641968170722==--