Re: gcc-ddc

[Gábor Boskovits]

The wrapper approach eliminated those three, we still have in prefix.c the prefix used as static initializer. I have to investigate further, but it's only 300 lines, should be tractable.

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