Re: gcc-ddc

["Gábor Boskovits" <boskovits@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2843 bytes --]

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
>
>
>

[-- Attachment #2: Type: text/html, Size: 3710 bytes --]