Re: gcc-ddc

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

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

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

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