Re: gcc-ddc

[Jan Nieuwenhuizen <janneke@gnu.org>]

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 <boskovits@gmail.com>:
>
>     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 <rekado@elephly.net>:
>
>         Jan Nieuwenhuizen <janneke@gnu.org> 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 <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com