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 17:36:51 +0100 Message-ID: References: <871skskduj.fsf@gnu.org> <87lgj0wqbd.fsf@elephly.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="94eb2c0551a46442d4055e80cffc" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:39385) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eHBXc-00022C-4a for guix-devel@gnu.org; Tue, 21 Nov 2017 11:36:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eHBXa-0001qi-LD for guix-devel@gnu.org; Tue, 21 Nov 2017 11:36:56 -0500 In-Reply-To: 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 --94eb2c0551a46442d4055e80cffc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The wrapper approach eliminated those three, we still have in prefix.c the prefix used as static initializer. I have to investigate further, but it's only 300 lines, should be tractable. 2017-11-21 0:16 GMT+01:00 G=C3=A1bor Boskovits : > The only problematic one seems to be standard_libexec_prefix, because tha= t > 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_prefi= x > 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_PREFI= X; >> >> 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 prefi= x >> 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 te= rrible >> 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 >> >> >> > --94eb2c0551a46442d4055e80cffc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The wrapper approach eliminated those three, we still have= in prefix.c the prefix used as static initializer. I have to investigate f= urther, but it's only 300 lines, should be tractable.

2017-11-21 0:16 GMT+01:00 G= =C3=A1bor Boskovits <boskovits@gmail.com>:
The only problematic one seems to be st= andard_libexec_prefix, because that is=C2=A0 used in line 3654 of gcc/gcc.c= in a real assignment.
It is also used in line 64 of gcc/gcc-ar.c.
<= br>
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.=C2=A0

<= div>This problematic use pattern is in the from:

x= =3Dmake_relative_prefix(y,standard_exec_prefix,standard_libexec_p= refix);
if(!x) x=3Dstandard_libexec_prefix;

<= div>Code of make_relative_prefix is in libiberty/make-relative-prefix.= c.

Assuming sane values (not nulls, existing progr= am name, valid GCC_EXEC_PREFIX) we get null in the following cases:
1. GCC_EXEC_PREFIX(or the program name directory component)=3D=3Dstandar= d_exec_prefix
2. if the path present in standard_exec_prefix= and standard_libexec_prefix has no common directories(starting from the be= ginning)
3. in case of allocation failure.

We can safely assume that case 2 does not happen, as we at least have /g= nu/store there, I think.
Nothing can be done about case 3, I don&= #39;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.
<= br>
2017-11-20 23:14 GMT+01:00 Ricardo Wurmus <= rekado@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




--94eb2c0551a46442d4055e80cffc--