Re: gcc-ddc

[Gábor Boskovits]

Hello!

Jan, I can now pass the test you have in the original patch, which basically builds gcc-4.7.4 twice, and  checks if gcc/bin are identical.

I'm using the getenv approach Ricardo suggested. I've not written a wrapper yet, the environment variables are set from the build.

As the gcc binary depends on the program name (argv[0]) we should leave it as is, so the wrapper should be gcc-wrapper, and also gcc-ar-wrapper.

Or something like that, and link the wrappers ot the profile as gcc, gcc-ar... I think we recently had a discussion on that.

I'd like to know if someone is willing to do this with the wrapper, or at least can point me to some packages already doing this.

I'd like some help with choosing appropriate names for these environment variables.

One thing we still miss, is that the gcc-ddc package does not produce output if the comparison is successful, so we have build failed then too.

It would be great, if we could store the diffoscope output in a file in the output directory anyway. Would you mind changing it that way?

Now I changed the test to compare the full build trees, and we have several files, where these same problems arose.

We also have several differences coming from section .gnu_debuglink. I guess that we don't need that anyway.

Clone location is: https://github.com/Boskovits/guix.git

Branch gcc-ddc.

I guess I will go on with this and try to make the gcc-4.7.4 build fully reproducible. Once that is done we can try the clang one, and see if some things are still missing or not.

We have the definition in place for that at least.

I cannot paste the text of the patch because of limitations in my current mail client, I will work on it, though.

The patch should be applied no top of the one sent by janneke.

2017-11-21 17:48 GMT+01:00 Gábor Boskovits <address@hidden>:

I just pushed what I have right now. It's on branch gcc-ddc on my github. Should I post a patch here? 

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

0001-Added-changes.patch
Description: Text Data