[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gcc-ddc
From: |
Jan Nieuwenhuizen |
Subject: |
Re: gcc-ddc |
Date: |
Tue, 21 Nov 2017 23:01:04 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) |
Gábor 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?
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ábor Boskovits <address@hidden>:
>
> 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=make_relative_prefix(y,standard_exec_prefix,standard_libexec_prefix);
> if(!x) x=standard_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)==standard_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 <address@hidden>:
>
> Jan Nieuwenhuizen <address@hidden> writes:
>
> > Gábor Boskovits writes:
> >
> > Hey Gábor!
> >
> > [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 =
> STANDARD_EXEC_PREFIX;
> >> static const char *const standard_libexec_prefix =
> STANDARD_LIBEXEC_PREFIX;
> >> static const char *const standard_bindir_prefix =
> 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’m 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 2150 197A 5888 235F ACAC
> https://elephly.net
>
--
Jan Nieuwenhuizen <address@hidden> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
- Re: gcc-ddc, Jan Nieuwenhuizen, 2017/11/20
- Re: gcc-ddc, Ricardo Wurmus, 2017/11/21
- Re: gcc-ddc, Gábor Boskovits, 2017/11/20
- Re: gcc-ddc, Gábor Boskovits, 2017/11/21
- Re: gcc-ddc, Gábor Boskovits, 2017/11/21
- Re: gcc-ddc,
Jan Nieuwenhuizen <=
- Re: gcc-ddc, Gábor Boskovits, 2017/11/22
- Re: gcc-ddc, Jan Nieuwenhuizen, 2017/11/22
- Re: gcc-ddc, Ricardo Wurmus, 2017/11/23
- Re: gcc-ddc, Gábor Boskovits, 2017/11/23
- Re: gcc-ddc, Gábor Boskovits, 2017/11/29
- Re: gcc-ddc, Gábor Boskovits, 2017/11/29
- Re: gcc-ddc, Jan Nieuwenhuizen, 2017/11/29
- Re: gcc-ddc, Gábor Boskovits, 2017/11/30