From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Nieuwenhuizen Subject: Re: gcc-ddc Date: Tue, 21 Nov 2017 23:01:04 +0100 Message-ID: <878tezi95r.fsf@gnu.org> References: <871skskduj.fsf@gnu.org> <87lgj0wqbd.fsf@elephly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:38587) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eHGbW-0005ma-Ec for guix-devel@gnu.org; Tue, 21 Nov 2017 17:01:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eHGbV-0006cH-6c for guix-devel@gnu.org; Tue, 21 Nov 2017 17:01:18 -0500 In-Reply-To: (=?utf-8?Q?=22G=C3=A1bor?= Boskovits"'s message of "Tue, 21 Nov 2017 17:48:21 +0100") 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: =?utf-8?Q?G=C3=A1bor?= Boskovits Cc: Guix-devel G=C3=A1bor Boskovits writes: > I just pushed what I have right now. It's on branch gcc-ddc on my github.= Should I post a patch here?=C2=A0 Great! Yes, that makes commenting on it an easy option. Also, please mention the location to clone from. github is non-free, but cloning from it is ok. janneke > > 2017-11-21 0:16 GMT+01:00 G=C3=A1bor Boskovits : > > The only problematic one seems to be standard_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. >=20=20=20=20 > 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 b= e ok.=C2=A0 >=20=20=20=20 > This problematic use pattern is in the from: >=20=20=20=20 > x=3Dmake_relative_prefix(y,standard_exec_prefix,standard_libexec_pref= ix); > if(!x) x=3Dstandard_libexec_prefix; >=20=20=20=20 > Code of make_relative_prefix is in libiberty/make-relative-prefix.c. >=20=20=20=20 > Assuming sane values (not nulls, existing program name, valid GCC_EXE= C_PREFIX) we get null in the following > cases: > 1. GCC_EXEC_PREFIX(or the program name directory component)=3D=3Dstan= dard_exec_prefix > 2. if the path present in standard_exec_prefix and standard_libexec_p= refix has no common directories > (starting from the beginning) > 3. in case of allocation failure. >=20=20=20=20 > 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 tha= t case anyway... >=20=20=20=20 > So, when this happens we simply have case 1: we are not relocated. >=20=20=20=20 > 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. >=20=20=20=20 > This is how far I could get with it by now. >=20=20=20=20 > 2017-11-20 23:14 GMT+01:00 Ricardo Wurmus : > > Jan Nieuwenhuizen writes: >=20=20=20=20=20=20=20=20 > > 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_EXE= C_PREFIX; > >> static const char *const standard_libexec_prefix =3D STANDARD_= LIBEXEC_PREFIX; > >> static const char *const standard_bindir_prefix =3D STANDARD_B= INDIR_PREFIX; > > > > Oh nice! > > > >> The problem fundamentally is that they are calculated from pre= fix 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 kee= p prefix 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 Makefil= e.in. >=20=20=20=20=20=20=20=20 > 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 pro= vide > the values at runtime with a separate wrapper that would be exclu= ded in > the comparison. >=20=20=20=20=20=20=20=20 > -- > Ricardo >=20=20=20=20=20=20=20=20 > GPG: BCA6 89B6 3655 3801 C3C6=C2=A0 2150 197A 5888 235F ACAC > https://elephly.net > --=20 Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar=C2=AE http://AvatarAcademy.com