From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?G=C3=A1bor_Boskovits?= Subject: Re: gcc-ddc Date: Tue, 21 Nov 2017 00:16:44 +0100 Message-ID: References: <871skskduj.fsf@gnu.org> <87lgj0wqbd.fsf@elephly.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a1143d330a67650055e72473e" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:42477) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eGvJ3-0006uK-5H for guix-devel@gnu.org; Mon, 20 Nov 2017 18:16:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eGvJ1-0000kF-Ph for guix-devel@gnu.org; Mon, 20 Nov 2017 18:16:49 -0500 In-Reply-To: <87lgj0wqbd.fsf@elephly.net> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ricardo Wurmus Cc: Guix-devel --001a1143d330a67650055e72473e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The only problematic one seems to be standard_libexec_prefix, because that is used in line 3654 of gcc/gcc.c in a real assignment. It is also used in line 64 of gcc/gcc-ar.c. Other uses of all these other symbols could be calculated as compile time realitve paths, and if we can live with these paths staying in the same store directory, then it would be ok. This problematic use pattern is in the from: x=3Dmake_relative_prefix(y,standard_exec_prefix,standard_libexec_prefix); if(!x) x=3Dstandard_libexec_prefix; Code of make_relative_prefix is in libiberty/make-relative-prefix.c. Assuming sane values (not nulls, existing program name, valid GCC_EXEC_PREFIX) we get null in the following cases: 1. GCC_EXEC_PREFIX(or the program name directory component)=3D=3Dstandard_exec_prefix 2. if the path present in standard_exec_prefix and standard_libexec_prefix has no common directories(starting from the beginning) 3. in case of allocation failure. We can safely assume that case 2 does not happen, as we at least have /gnu/store there, I think. Nothing can be done about case 3, I don't think we get too far in that case anyway... So, when this happens we simply have case 1: we are not relocated. In gcc/gcc.c this pattern is guarded by if(gcc_exec_prefix) basically.(it is in an else block) It is not so in gcc/gcc-ar.c. This is how far I could get with it by now. 2017-11-20 23:14 GMT+01:00 Ricardo Wurmus : > > Jan Nieuwenhuizen writes: > > > G=C3=A1bor Boskovits writes: > > > > Hey G=C3=A1bor! > > > > [cc: guix-devel] > > > >> I'm definietly making progress on this. Now I have a working debug > build of gcc. > >> Identified the critical symbols, they are: > > > >> static const char *const standard_exec_prefix =3D STANDARD_EXEC_PREFIX= ; > >> static const char *const standard_libexec_prefix =3D > STANDARD_LIBEXEC_PREFIX; > >> static const char *const standard_bindir_prefix =3D > STANDARD_BINDIR_PREFIX; > > > > Oh nice! > > > >> The problem fundamentally is that they are calculated from prefix > passed to configure. > >> I've checked, that that is the store location. > > > > Right. > > > >> How should we go on with this? > >> > >> Is it possible to pass other value as prefix, or should we keep prefix > as is, and patch the makefile? > >> It is set from line 2092 in gcc/Makefile.in by the way. > > > > Good question. I think we should try patching the Makefile.in. > > I=E2=80=99m just throwing this in, even though I suspect that it is a ter= rible > idea: we could replace these symbols with calls to getenv and provide > the values at runtime with a separate wrapper that would be excluded in > the comparison. > > -- > Ricardo > > GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC > https://elephly.net > > > --001a1143d330a67650055e72473e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The only problematic one seems to be standard_libexec_pref= ix, because that is=C2=A0 used in line 3654 of gcc/gcc.c in a real assignme= nt.
It is also used in line 64 of gcc/gcc-ar.c.

Other= uses of all these other symbols could be calculated as compile time realit= ve paths, and if we can live with these paths staying in the same store dir= ectory, then it would be ok.=C2=A0

This problemati= c use pattern is in the from:

x=3Dmake_relative_pr= efix(y,standard_exec_prefix,standard_libexec_prefix);
if(!x) x=3D= standard_libexec_prefix;

Code of make_relative_pre= fix is in libiberty/make-relative-prefix.c.

Assumi= ng sane values (not nulls, existing program name, valid GCC_EXEC_PREFIX) we= get null in the following cases:
1. GCC_EXEC_PREFIX(or the progr= am name directory component)=3D=3Dstandard_exec_prefix
2. if the = path present in standard_exec_prefix and standard_libexec_prefix has no com= mon directories(starting from the beginning)
3. in case of alloca= tion failure.

We can safely assume that case 2 doe= s not happen, as we at least have /gnu/store there, I think.
Noth= ing can be done about case 3, I don't think we get too far in that case= anyway...

So, when this happens we simply have ca= se 1: we are not relocated.

In gcc/gcc.c this patt= ern is guarded by if(gcc_exec_prefix) basically.(it is in an else block)
It is not so in gcc/gcc-ar.c.

This is how = far I could get with it by now.

<= div class=3D"gmail_quote">2017-11-20 23:14 GMT+01:00 Ricardo Wurmus <reka= do@elephly.net>:

Jan Nieuwenhuizen <janneke@gnu.org> writes:

> G=C3=A1bor Boskovits writes:
>
> Hey G=C3=A1bor!
>
> [cc: guix-devel]
>
>> I'm definietly making progress on this. Now I have a working d= ebug build of gcc.
>> Identified the critical symbols, they are:
>
>> static const char *const standard_exec_prefix =3D STANDARD_EXEC_PR= EFIX;
>> static const char *const standard_libexec_prefix =3D STANDARD_LIBE= XEC_PREFIX;
>> static const char *const standard_bindir_prefix =3D STANDARD_BINDI= R_PREFIX;
>
> Oh nice!
>
>> The problem fundamentally is that they are calculated from prefix = passed to configure.
>> I've checked, that that is the store location.
>
> Right.
>
>> How should we go on with this?
>>
>> Is it possible to pass other value as prefix, or should we keep pr= efix as is, and patch the makefile?
>> It is set from line 2092 in gcc/Makefile.in by the way.
>
> Good question.=C2=A0 I think we should try patching the Makefile.in.
I=E2=80=99m just throwing this in, even though I suspect that it is = a terrible
idea: we could replace these symbols with calls to getenv and provide
the values at runtime with a separate wrapper that would be excluded in
the comparison.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6=C2=A0 2150 197A 5888 235F ACAC
https:= //elephly.net



--001a1143d330a67650055e72473e--