guix-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]