[gem5-users] Link error building gem5.fast

[Moussa, Ayman]

How can I check which compiler scons uses? These are the compilers on my system


gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
g++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
Linux 4.4.0-75-generic #96-Ubuntu SMP


________________________________
From: gem5-users <gem5-users-***@gem5.org> on behalf of Jason Lowe-Power <***@lowepower.com>
Sent: 23 May 2017 22:27:34
To: gem5 users mailing list
Subject: Re: [gem5-users] Link error building gem5.fast

I just tried again and still cannot reproduce the error. What compiler are you using?

Jason

On Tue, May 23, 2017 at 3:41 PM Moussa, Ayman <***@imperial.ac.uk<mailto:***@imperial.ac.uk>> wrote:

Hey


I've encountered this exact problem with x86 and it only seems to be for gem5.fast (gem5.opt works fine). I still have problems with a clean build as Jason suggested so I reverted back to some random commit on the gem5 repository and it works but it's not what I was looking for though. Hope this gets fixed soon.



________________________________
From: gem5-users <gem5-users-***@gem5.org<mailto:gem5-users-***@gem5.org>> on behalf of Alec Roelke <***@virginia.edu<mailto:***@virginia.edu>>
Sent: 23 May 2017 21:14:10
To: gem5 users mailing list
Subject: [gem5-users] Link error building gem5.fast

Hi Everyone,

When I try to build gem5.fast using any ISA, I get a lot of multiple definition errors during the final linking stage. For example, with x86:

[ LINK] -> X86/gem5.fast.unstripped
build/X86/arch/x86/bios/lib.fo.partial: In function `Drainable::drainResume()':
(.text+0x5b00): multiple definition of `Drainable::drainResume()'
build/X86/dev/x86/lib.fo.partial:(.text+0x0): first defined here

There are way too many of these to list them all, but they're all multiple definitions of symbols. Has anyone else encountered this?

Thanks,
Alec Roelke

[Gabe Black]

I think this has to do with the interaction between partial linking and
link time optimization. I'll keep looking into it.

Gabe

On Wed, May 24, 2017 at 2:00 PM, Jason Lowe-Power <***@lowepower.com>
wrote:

> Hi everyone,
>
> So I've been able to reproduce the problem. I would bet it's due to the
> new partial linking code (https://gem5.googlesource.com/public/gem5/+/
> 6bdd897f04f4efdf90d0761c6d31d3f960f4eacf). I'm not sure what the solution
> is, yet, or if I'll have time to look at it in the next few day. Gabe might
> have an idea, though, if that is the problem.
>
> Here's a matrix of what compilers are working and which aren't (gcc-4.8 is
> working, too, though not tested on travis).
> https://travis-ci.org/powerjg/gem5-ci-test/builds/235779432
>
> Jason
>
> On Tue, May 23, 2017 at 4:33 PM Moussa, Ayman <
> ***@imperial.ac.uk> wrote:
>
>> How can I check which compiler scons uses? These are the compilers on my
>> system
>>
>>
>> gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
>> g++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
>> Linux 4.4.0-75-generic #96-Ubuntu SMP
>>
>> ------------------------------
>> *From:* gem5-users <gem5-users-***@gem5.org> on behalf of Jason
>> Lowe-Power <***@lowepower.com>
>> *Sent:* 23 May 2017 22:27:34
>>
>> *To:* gem5 users mailing list
>> *Subject:* Re: [gem5-users] Link error building gem5.fast
>>
>> I just tried again and still cannot reproduce the error. What compiler
>> are you using?
>>
>> Jason
>>
>> On Tue, May 23, 2017 at 3:41 PM Moussa, Ayman <
>> ***@imperial.ac.uk> wrote:
>>
>>> Hey
>>>
>>>
>>> I've encountered this exact problem with x86 and it only seems to be for
>>> gem5.fast (gem5.opt works fine). I still have problems with a clean build
>>> as Jason suggested so I reverted back to some random commit on the gem5
>>> repository and it works but it's not what I was looking for though. Hope
>>> this gets fixed soon.
>>>
>>>
>>>
>>> ------------------------------
>>> *From:* gem5-users <gem5-users-***@gem5.org> on behalf of Alec
>>> Roelke <***@virginia.edu>
>>> *Sent:* 23 May 2017 21:14:10
>>> *To:* gem5 users mailing list
>>> *Subject:* [gem5-users] Link error building gem5.fast
>>>
>>> Hi Everyone,
>>>
>>> When I try to build gem5.fast using any ISA, I get a lot of multiple
>>> definition errors during the final linking stage. For example, with x86:
>>>
>>> [ LINK] -> X86/gem5.fast.unstripped
>>> build/X86/arch/x86/bios/lib.fo.partial: In function
>>> `Drainable::drainResume()':
>>> (.text+0x5b00): multiple definition of `Drainable::drainResume()'
>>> build/X86/dev/x86/lib.fo.partial:(.text+0x0): first defined here
>>>
>>> There are way too many of these to list them all, but they're all
>>> multiple definitions of symbols. Has anyone else encountered this?
>>>
>>> Thanks,
>>> Alec Roelke
>>> _______________________________________________
>>> gem5-users mailing list
>>> gem5-***@gem5.org
>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>
>> _______________________________________________
>> gem5-users mailing list
>> gem5-***@gem5.org
>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
>

[Gabe Black]

My workstation doesn't have a version of gcc on it that hits the error, so
it's going to be difficult for me to do very much debugging. The major
difference I see between m5.opt and m5.fast, particularly on gcc of
approximately the right versions, is that LTO is turned on.

Gabe

On Wed, May 24, 2017 at 7:04 PM, Gabe Black <***@google.com> wrote:

> I think this has to do with the interaction between partial linking and
> link time optimization. I'll keep looking into it.
>
> Gabe
>
> On Wed, May 24, 2017 at 2:00 PM, Jason Lowe-Power <***@lowepower.com>
> wrote:
>
>> Hi everyone,
>>
>> So I've been able to reproduce the problem. I would bet it's due to the
>> new partial linking code (https://gem5.googlesource.com
>> /public/gem5/+/6bdd897f04f4efdf90d0761c6d31d3f960f4eacf). I'm not sure
>> what the solution is, yet, or if I'll have time to look at it in the next
>> few day. Gabe might have an idea, though, if that is the problem.
>>
>> Here's a matrix of what compilers are working and which aren't (gcc-4.8
>> is working, too, though not tested on travis).
>> https://travis-ci.org/powerjg/gem5-ci-test/builds/235779432
>>
>> Jason
>>
>> On Tue, May 23, 2017 at 4:33 PM Moussa, Ayman <
>> ***@imperial.ac.uk> wrote:
>>
>>> How can I check which compiler scons uses? These are the compilers on my
>>> system
>>>
>>>
>>> gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
>>> g++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
>>> Linux 4.4.0-75-generic #96-Ubuntu SMP
>>>
>>> ------------------------------
>>> *From:* gem5-users <gem5-users-***@gem5.org> on behalf of Jason
>>> Lowe-Power <***@lowepower.com>
>>> *Sent:* 23 May 2017 22:27:34
>>>
>>> *To:* gem5 users mailing list
>>> *Subject:* Re: [gem5-users] Link error building gem5.fast
>>>
>>> I just tried again and still cannot reproduce the error. What compiler
>>> are you using?
>>>
>>> Jason
>>>
>>> On Tue, May 23, 2017 at 3:41 PM Moussa, Ayman <
>>> ***@imperial.ac.uk> wrote:
>>>
>>>> Hey
>>>>
>>>>
>>>> I've encountered this exact problem with x86 and it only seems to be
>>>> for gem5.fast (gem5.opt works fine). I still have problems with a clean
>>>> build as Jason suggested so I reverted back to some random commit on the
>>>> gem5 repository and it works but it's not what I was looking for though.
>>>> Hope this gets fixed soon.
>>>>
>>>>
>>>>
>>>> ------------------------------
>>>> *From:* gem5-users <gem5-users-***@gem5.org> on behalf of Alec
>>>> Roelke <***@virginia.edu>
>>>> *Sent:* 23 May 2017 21:14:10
>>>> *To:* gem5 users mailing list
>>>> *Subject:* [gem5-users] Link error building gem5.fast
>>>>
>>>> Hi Everyone,
>>>>
>>>> When I try to build gem5.fast using any ISA, I get a lot of multiple
>>>> definition errors during the final linking stage. For example, with x86:
>>>>
>>>> [ LINK] -> X86/gem5.fast.unstripped
>>>> build/X86/arch/x86/bios/lib.fo.partial: In function
>>>> `Drainable::drainResume()':
>>>> (.text+0x5b00): multiple definition of `Drainable::drainResume()'
>>>> build/X86/dev/x86/lib.fo.partial:(.text+0x0): first defined here
>>>>
>>>> There are way too many of these to list them all, but they're all
>>>> multiple definitions of symbols. Has anyone else encountered this?
>>>>
>>>> Thanks,
>>>> Alec Roelke
>>>> _______________________________________________
>>>> gem5-users mailing list
>>>> gem5-***@gem5.org
>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>
>>> _______________________________________________
>>> gem5-users mailing list
>>> gem5-***@gem5.org
>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>
>>
>

[Alec Roelke]

Sorry for the late reply; I've been traveling. I did try this with a clean
build of a fresh clone of the repository, and got the error with both
RISC-V and x86. The version of GCC that I'm using is gcc (Ubuntu
5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609.

On May 24, 2017 10:23 PM, "Gabe Black" <***@google.com> wrote:

> My workstation doesn't have a version of gcc on it that hits the error, so
> it's going to be difficult for me to do very much debugging. The major
> difference I see between m5.opt and m5.fast, particularly on gcc of
> approximately the right versions, is that LTO is turned on.
>
> Gabe
>
> On Wed, May 24, 2017 at 7:04 PM, Gabe Black <***@google.com> wrote:
>
>> I think this has to do with the interaction between partial linking and
>> link time optimization. I'll keep looking into it.
>>
>> Gabe
>>
>> On Wed, May 24, 2017 at 2:00 PM, Jason Lowe-Power <***@lowepower.com>
>> wrote:
>>
>>> Hi everyone,
>>>
>>> So I've been able to reproduce the problem. I would bet it's due to the
>>> new partial linking code (https://gem5.googlesource.com
>>> /public/gem5/+/6bdd897f04f4efdf90d0761c6d31d3f960f4eacf). I'm not sure
>>> what the solution is, yet, or if I'll have time to look at it in the next
>>> few day. Gabe might have an idea, though, if that is the problem.
>>>
>>> Here's a matrix of what compilers are working and which aren't (gcc-4.8
>>> is working, too, though not tested on travis).
>>> https://travis-ci.org/powerjg/gem5-ci-test/builds/235779432
>>>
>>> Jason
>>>
>>> On Tue, May 23, 2017 at 4:33 PM Moussa, Ayman <
>>> ***@imperial.ac.uk> wrote:
>>>
>>>> How can I check which compiler scons uses? These are the compilers on
>>>> my system
>>>>
>>>>
>>>> gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
>>>> g++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
>>>> Linux 4.4.0-75-generic #96-Ubuntu SMP
>>>>
>>>> ------------------------------
>>>> *From:* gem5-users <gem5-users-***@gem5.org> on behalf of Jason
>>>> Lowe-Power <***@lowepower.com>
>>>> *Sent:* 23 May 2017 22:27:34
>>>>
>>>> *To:* gem5 users mailing list
>>>> *Subject:* Re: [gem5-users] Link error building gem5.fast
>>>>
>>>> I just tried again and still cannot reproduce the error. What compiler
>>>> are you using?
>>>>
>>>> Jason
>>>>
>>>> On Tue, May 23, 2017 at 3:41 PM Moussa, Ayman <
>>>> ***@imperial.ac.uk> wrote:
>>>>
>>>>> Hey
>>>>>
>>>>>
>>>>> I've encountered this exact problem with x86 and it only seems to be
>>>>> for gem5.fast (gem5.opt works fine). I still have problems with a clean
>>>>> build as Jason suggested so I reverted back to some random commit on the
>>>>> gem5 repository and it works but it's not what I was looking for though.
>>>>> Hope this gets fixed soon.
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------
>>>>> *From:* gem5-users <gem5-users-***@gem5.org> on behalf of Alec
>>>>> Roelke <***@virginia.edu>
>>>>> *Sent:* 23 May 2017 21:14:10
>>>>> *To:* gem5 users mailing list
>>>>> *Subject:* [gem5-users] Link error building gem5.fast
>>>>>
>>>>> Hi Everyone,
>>>>>
>>>>> When I try to build gem5.fast using any ISA, I get a lot of multiple
>>>>> definition errors during the final linking stage. For example, with x86:
>>>>>
>>>>> [ LINK] -> X86/gem5.fast.unstripped
>>>>> build/X86/arch/x86/bios/lib.fo.partial: In function
>>>>> `Drainable::drainResume()':
>>>>> (.text+0x5b00): multiple definition of `Drainable::drainResume()'
>>>>> build/X86/dev/x86/lib.fo.partial:(.text+0x0): first defined here
>>>>>
>>>>> There are way too many of these to list them all, but they're all
>>>>> multiple definitions of symbols. Has anyone else encountered this?
>>>>>
>>>>> Thanks,
>>>>> Alec Roelke
>>>>> _______________________________________________
>>>>> gem5-users mailing list
>>>>> gem5-***@gem5.org
>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>>
>>>> _______________________________________________
>>>> gem5-users mailing list
>>>> gem5-***@gem5.org
>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>
>>>
>>
>
> _______________________________________________
> gem5-users mailing list
> gem5-***@gem5.org
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>

[Gabe Black]

I was thinking about this, and while I don't have the right compiler
installed to try this myself, the solution might be to filter out the LTO
option when doing the partial link like the -shared option. I *think* what
will happen is that the sections with the GIMPLE (LTO data) will be merged,
and then the LTO will still happen during the final link. I think what
might be happening is that g++ is doing actual LTO during the partial
links, and that's messing things up later since things which should only be
done at the end have been done multiple times before then. This is largely
speculation, but probably worth a try.

Gabe

On Sat, May 27, 2017 at 2:41 PM, Alec Roelke <***@virginia.edu> wrote:

> Sorry for the late reply; I've been traveling. I did try this with a
> clean build of a fresh clone of the repository, and got the error with both
> RISC-V and x86. The version of GCC that I'm using is gcc (Ubuntu
> 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609.
>
> On May 24, 2017 10:23 PM, "Gabe Black" <***@google.com> wrote:
>
>> My workstation doesn't have a version of gcc on it that hits the error,
>> so it's going to be difficult for me to do very much debugging. The major
>> difference I see between m5.opt and m5.fast, particularly on gcc of
>> approximately the right versions, is that LTO is turned on.
>>
>> Gabe
>>
>> On Wed, May 24, 2017 at 7:04 PM, Gabe Black <***@google.com> wrote:
>>
>>> I think this has to do with the interaction between partial linking and
>>> link time optimization. I'll keep looking into it.
>>>
>>> Gabe
>>>
>>> On Wed, May 24, 2017 at 2:00 PM, Jason Lowe-Power <***@lowepower.com>
>>> wrote:
>>>
>>>> Hi everyone,
>>>>
>>>> So I've been able to reproduce the problem. I would bet it's due to the
>>>> new partial linking code (https://gem5.googlesource.com
>>>> /public/gem5/+/6bdd897f04f4efdf90d0761c6d31d3f960f4eacf). I'm not sure
>>>> what the solution is, yet, or if I'll have time to look at it in the next
>>>> few day. Gabe might have an idea, though, if that is the problem.
>>>>
>>>> Here's a matrix of what compilers are working and which aren't (gcc-4.8
>>>> is working, too, though not tested on travis).
>>>> https://travis-ci.org/powerjg/gem5-ci-test/builds/235779432
>>>>
>>>> Jason
>>>>
>>>> On Tue, May 23, 2017 at 4:33 PM Moussa, Ayman <
>>>> ***@imperial.ac.uk> wrote:
>>>>
>>>>> How can I check which compiler scons uses? These are the compilers on
>>>>> my system
>>>>>
>>>>>
>>>>> gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
>>>>> g++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
>>>>> Linux 4.4.0-75-generic #96-Ubuntu SMP
>>>>>
>>>>> ------------------------------
>>>>> *From:* gem5-users <gem5-users-***@gem5.org> on behalf of Jason
>>>>> Lowe-Power <***@lowepower.com>
>>>>> *Sent:* 23 May 2017 22:27:34
>>>>>
>>>>> *To:* gem5 users mailing list
>>>>> *Subject:* Re: [gem5-users] Link error building gem5.fast
>>>>>
>>>>> I just tried again and still cannot reproduce the error. What compiler
>>>>> are you using?
>>>>>
>>>>> Jason
>>>>>
>>>>> On Tue, May 23, 2017 at 3:41 PM Moussa, Ayman <
>>>>> ***@imperial.ac.uk> wrote:
>>>>>
>>>>>> Hey
>>>>>>
>>>>>>
>>>>>> I've encountered this exact problem with x86 and it only seems to be
>>>>>> for gem5.fast (gem5.opt works fine). I still have problems with a clean
>>>>>> build as Jason suggested so I reverted back to some random commit on the
>>>>>> gem5 repository and it works but it's not what I was looking for though.
>>>>>> Hope this gets fixed soon.
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------
>>>>>> *From:* gem5-users <gem5-users-***@gem5.org> on behalf of Alec
>>>>>> Roelke <***@virginia.edu>
>>>>>> *Sent:* 23 May 2017 21:14:10
>>>>>> *To:* gem5 users mailing list
>>>>>> *Subject:* [gem5-users] Link error building gem5.fast
>>>>>>
>>>>>> Hi Everyone,
>>>>>>
>>>>>> When I try to build gem5.fast using any ISA, I get a lot of multiple
>>>>>> definition errors during the final linking stage. For example, with x86:
>>>>>>
>>>>>> [ LINK] -> X86/gem5.fast.unstripped
>>>>>> build/X86/arch/x86/bios/lib.fo.partial: In function
>>>>>> `Drainable::drainResume()':
>>>>>> (.text+0x5b00): multiple definition of `Drainable::drainResume()'
>>>>>> build/X86/dev/x86/lib.fo.partial:(.text+0x0): first defined here
>>>>>>
>>>>>> There are way too many of these to list them all, but they're all
>>>>>> multiple definitions of symbols. Has anyone else encountered this?
>>>>>>
>>>>>> Thanks,
>>>>>> Alec Roelke
>>>>>> _______________________________________________
>>>>>> gem5-users mailing list
>>>>>> gem5-***@gem5.org
>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>>>
>>>>> _______________________________________________
>>>>> gem5-users mailing list
>>>>> gem5-***@gem5.org
>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> gem5-users mailing list
>> gem5-***@gem5.org
>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>
>
> _______________________________________________
> gem5-users mailing list
> gem5-***@gem5.org
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>

[Jason Lowe-Power]

I've spent some time trying to figure this out, but I haven't gotten very
far. I'm not very well versed in gcc LTO or partial linking.

Here's what I've found. I've trimmed out everything except what's relevant
to a single lib.fo.partial error. This was with "gcc (Ubuntu
5.4.1-2ubuntu1~16.04) 5.4.1 20160904". If you want to test this on your
own, you can simply use a docker image to get a different compiler version.
The following command line should "just work" with my docker image. (Note:
it's called gcc-6, but gcc-5 is the default. Oops.)

> docker run -v `pwd`:`pwd` -it powerjg/gem5-gcc-6-build /bin/bash
> cd <your gem5 directory>
> scons ...

One thing stands out to me below. Every single partial linking includes
"-Lbuild/nomali -Lbuild/drampower -Lbuild/iostream3 -Lbuild/libfdt
-Lbuild/libelf -Lbuild/fputils". However, this doesn't seem to be the
problem. It seems like it may be something with header files. Could it be
that all of the functions defined in header files are causing the problem?

The error below is all for the Stats members. Other common errors are
SimObject::drain() and Drainable::drainResume().

I'm grasping at straws here. If anyone has any ideas, we really need to get
this fixed. If we can't solve this (relatively) quickly, we should revert
the partial linking patch so we can use gem5.fast again!

Thanks,
Jason

ERROR:
-------------
build/X86/mem/ruby/profiler/lib.fo.partial:(.rodata+0x3e0): multiple
definition of `typeinfo name for Stats::HistStor::Params'
build/X86/mem/ruby/system/lib.fo.partial:(.rodata+0xdd0): first defined here
build/X86/mem/ruby/profiler/lib.fo.partial:(.rodata+0x0): multiple
definition of `typeinfo name for Stats::DistInfo'
build/X86/mem/ruby/system/lib.fo.partial:(.rodata+0x11c0): first defined
here
build/X86/mem/ruby/profiler/lib.fo.partial:(.rodata+0xa0): multiple
definition of `typeinfo for Stats::InfoProxy<Stats::Histogram,
Stats::DistInfo>'
build/X86/mem/ruby/system/lib.fo.partial:(.rodata+0x1260): first defined
here
build/X86/mem/ruby/profiler/lib.fo.partial:(.rodata+0x60): multiple
definition of `typeinfo name for Stats::DistInfoProxy<Stats::Histogram>'
build/X86/mem/ruby/system/lib.fo.partial:(.rodata+0x1220): first defined
here
build/X86/mem/ruby/profiler/lib.fo.partial: In function
`std::vector<std::vector<Stats::Histogram*,
std::allocator<Stats::Histogram*> >,
std::allocator<std::vector<Stats::Histogram*,
std::allocator<Stats::Histogram*> > > >::~vector()':
(.text.unlikely+0x82): multiple definition of
`std::vector<std::vector<Stats::Histogram*,
std::allocator<Stats::Histogram*> >,
std::allocator<std::vector<Stats::Histogram*,
std::allocator<Stats::Histogram*> > > >::~vector()'
build/X86/mem/ruby/system/lib.fo.partial:(.text.unlikely+0x4d8): first
defined here
build/X86/mem/ruby/profiler/lib.fo.partial:(.rodata+0x430): multiple
definition of `typeinfo for Stats::DistParams'
build/X86/mem/ruby/system/lib.fo.partial:(.rodata+0xe20): first defined here
build/X86/mem/ruby/profiler/lib.fo.partial:(.rodata+0x140): multiple
definition of `typeinfo name for Stats::ScalarInfoProxy<Stats::Scalar>'
build/X86/mem/ruby/system/lib.fo.partial:(.rodata+0x1340): first defined
here
build/X86/mem/ruby/profiler/lib.fo.partial:(.rodata+0x168): multiple
definition of `typeinfo for Stats::ScalarInfo'
build/X86/mem/ruby/system/lib.fo.partial:(.rodata+0x1368): first defined
here
build/X86/mem/ruby/profiler/lib.fo.partial: In function
`Stats::HistStor::Params::~Params()':
(.text+0x7720): multiple definition of `Stats::HistStor::Params::~Params()'
build/X86/mem/ruby/system/lib.fo.partial:(.text+0xf2f0): first defined here
build/X86/mem/ruby/profiler/lib.fo.partial:(.rodata+0x20): multiple
definition of `typeinfo name for Stats::InfoProxy<Stats::Histogram,
Stats::DistInfo>'
build/X86/mem/ruby/system/lib.fo.partial:(.rodata+0x11e0): first defined
here
build/X86/mem/ruby/profiler/lib.fo.partial:(.rodata+0x180): multiple
definition of `typeinfo for Stats::InfoProxy<Stats::Scalar,
Stats::ScalarInfo>'
build/X86/mem/ruby/system/lib.fo.partial:(.rodata+0x1380): first defined
here
build/X86/mem/ruby/profiler/lib.fo.partial:(.rodata+0x400): multiple
definition of `typeinfo name for Stats::DistParams'
build/X86/mem/ruby/system/lib.fo.partial:(.rodata+0xdf0): first defined here
build/X86/mem/ruby/profiler/lib.fo.partial:(.rodata+0xd0): multiple
definition of `typeinfo name for Stats::ScalarInfo'
build/X86/mem/ruby/system/lib.fo.partial:(.rodata+0x12e0): first defined
here
build/X86/mem/ruby/profiler/lib.fo.partial: In function `void
std::vector<std::vector<Stats::Histogram*,
std::allocator<Stats::Histogram*> >,
std::allocator<std::vector<Stats::Histogram*,
std::allocator<Stats::Histogram*> > >
>::emplace_back<std::vector<Stats::Histogram*,
std::allocator<Stats::Histogram*> > >(std::vector<Stats::Histogram*,
std::allocator<Stats::Histogram*> >&&) [clone .constprop.0]':
(.text+0x9e40): multiple definition of `void
std::vector<std::vector<Stats::Histogram*,
std::allocator<Stats::Histogram*> >,
std::allocator<std::vector<Stats::Histogram*,
std::allocator<Stats::Histogram*> > >
>::emplace_back<std::vector<Stats::Histogram*,
std::allocator<Stats::Histogram*> > >(std::vector<Stats::Histogram*,
std::allocator<Stats::Histogram*> >&&) [clone .constprop.0]'
build/X86/mem/ruby/system/lib.fo.partial:(.text+0xc640): first defined here
build/X86/mem/ruby/profiler/lib.fo.partial:(.rodata+0x448): multiple
definition of `vtable for Stats::HistStor::Params'
build/X86/mem/ruby/system/lib.fo.partial:(.rodata+0xe70): first defined here
build/X86/mem/ruby/profiler/lib.fo.partial: In function
`Stats::DistParams::~DistParams()':
(.text+0x8230): multiple definition of `Stats::DistParams::~DistParams()'
build/X86/mem/ruby/system/lib.fo.partial:(.text+0x4d30): first defined here
build/X86/mem/ruby/profiler/lib.fo.partial:(.rodata+0x468): multiple
definition of `vtable for Stats::DistParams'
build/X86/mem/ruby/system/lib.fo.partial:(.rodata+0xe90): first defined here
build/X86/mem/ruby/profiler/lib.fo.partial: In function
`std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > std::operator+<char, std::char_traits<char>,
std::allocator<char> >(std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&, char const*)':
(.text+0xb020): multiple definition of `std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > std::operator+<char,
std::char_traits<char>, std::allocator<char>
>(std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > const&, char const*)'
build/X86/mem/ruby/system/lib.fo.partial:(.text+0x6c10): first defined here
build/X86/mem/ruby/profiler/lib.fo.partial:(.rodata+0x88): multiple
definition of `typeinfo for Stats::DistInfo'
build/X86/mem/ruby/system/lib.fo.partial:(.rodata+0x1248): first defined
here
build/X86/mem/ruby/profiler/lib.fo.partial:(.rodata+0x100): multiple
definition of `typeinfo name for Stats::InfoProxy<Stats::Scalar,
Stats::ScalarInfo>'
build/X86/mem/ruby/system/lib.fo.partial:(.rodata+0x1300): first defined
here

Tracing back:
----------------------
g++ -o build/X86/mem/ruby/profiler/lib.fo.partial -r -nostdlib
build/X86/mem/ruby/profiler/AccessTraceForAddress.fo
build/X86/mem/ruby/profiler/AddressProfiler.fo
build/X86/mem/ruby/profiler/Profiler.fo
build/X86/mem/ruby/profiler/StoreTrace.fo -Lbuild/nomali -Lbuild/drampower
-Lbuild/iostream3 -Lbuild/libfdt -Lbuild/libelf -Lbuild/fputils

g++ -o build/X86/mem/ruby/profiler/AccessTraceForAddress.fo -c -std=c++11
-pipe -fno-strict-aliasing -Wall -Wundef -Wextra -Wno-sign-compare
-Wno-unused-parameter -Wno-error=suggest-override -fno-builtin-malloc
-fno-builtin-calloc -fno-builtin-realloc -fno-builtin-free
-DPROTOBUF_INLINE_NOT_IN_HEADERS=0 -O3 -flto=8 -Werror
-Wno-error=deprecated-declarations -Wno-error=deprecated -DNDEBUG
-DTRACING_ON=0 -Iext/pybind11/include -Ibuild/nomali/include
-Ibuild/drampower/src -Ibuild/iostream3 -Ibuild/libfdt -Ibuild/libelf
-Ibuild/fputils/include -Iext -I/usr/include/python2.7
-I/usr/include/x86_64-linux-gnu/python2.7 -Ibuild/X86
build/X86/mem/ruby/profiler/AccessTraceForAddress.cc

g++ -o build/X86/mem/ruby/profiler/AddressProfiler.fo -c -std=c++11 -pipe
-fno-strict-aliasing -Wall -Wundef -Wextra -Wno-sign-compare
-Wno-unused-parameter -Wno-error=suggest-override -fno-builtin-malloc
-fno-builtin-calloc -fno-builtin-realloc -fno-builtin-free
-DPROTOBUF_INLINE_NOT_IN_HEADERS=0 -O3 -flto=8 -Werror
-Wno-error=deprecated-declarations -Wno-error=deprecated -DNDEBUG
-DTRACING_ON=0 -Iext/pybind11/include -Ibuild/nomali/include
-Ibuild/drampower/src -Ibuild/iostream3 -Ibuild/libfdt -Ibuild/libelf
-Ibuild/fputils/include -Iext -I/usr/include/python2.7
-I/usr/include/x86_64-linux-gnu/python2.7 -Ibuild/X86
build/X86/mem/ruby/profiler/AddressProfiler.cc

g++ -o build/X86/mem/ruby/profiler/Profiler.fo -c -std=c++11 -pipe
-fno-strict-aliasing -Wall -Wundef -Wextra -Wno-sign-compare
-Wno-unused-parameter -Wno-error=suggest-override -fno-builtin-malloc
-fno-builtin-calloc -fno-builtin-realloc -fno-builtin-free
-DPROTOBUF_INLINE_NOT_IN_HEADERS=0 -O3 -flto=8 -Werror
-Wno-error=deprecated-declarations -Wno-error=deprecated -DNDEBUG
-DTRACING_ON=0 -Iext/pybind11/include -Ibuild/nomali/include
-Ibuild/drampower/src -Ibuild/iostream3 -Ibuild/libfdt -Ibuild/libelf
-Ibuild/fputils/include -Iext -I/usr/include/python2.7
-I/usr/include/x86_64-linux-gnu/python2.7 -Ibuild/X86
build/X86/mem/ruby/profiler/Profiler.cc

g++ -o build/X86/mem/ruby/profiler/StoreTrace.fo -c -std=c++11 -pipe
-fno-strict-aliasing -Wall -Wundef -Wextra -Wno-sign-compare
-Wno-unused-parameter -Wno-error=suggest-override -fno-builtin-malloc
-fno-builtin-calloc -fno-builtin-realloc -fno-builtin-free
-DPROTOBUF_INLINE_NOT_IN_HEADERS=0 -O3 -flto=8 -Werror
-Wno-error=deprecated-declarations -Wno-error=deprecated -DNDEBUG
-DTRACING_ON=0 -Iext/pybind11/include -Ibuild/nomali/include
-Ibuild/drampower/src -Ibuild/iostream3 -Ibuild/libfdt -Ibuild/libelf
-Ibuild/fputils/include -Iext -I/usr/include/python2.7
-I/usr/include/x86_64-linux-gnu/python2.7 -Ibuild/X86
build/X86/mem/ruby/profiler/StoreTrace.cc

On Sun, May 28, 2017 at 2:57 PM Gabe Black <***@google.com> wrote:

> I was thinking about this, and while I don't have the right compiler
> installed to try this myself, the solution might be to filter out the LTO
> option when doing the partial link like the -shared option. I *think* what
> will happen is that the sections with the GIMPLE (LTO data) will be merged,
> and then the LTO will still happen during the final link. I think what
> might be happening is that g++ is doing actual LTO during the partial
> links, and that's messing things up later since things which should only be
> done at the end have been done multiple times before then. This is largely
> speculation, but probably worth a try.
>
> Gabe
>
> On Sat, May 27, 2017 at 2:41 PM, Alec Roelke <***@virginia.edu> wrote:
>
>> Sorry for the late reply; I've been traveling. I did try this with a
>> clean build of a fresh clone of the repository, and got the error with both
>> RISC-V and x86. The version of GCC that I'm using is gcc (Ubuntu
>> 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609.
>>
>> On May 24, 2017 10:23 PM, "Gabe Black" <***@google.com> wrote:
>>
>>> My workstation doesn't have a version of gcc on it that hits the error,
>>> so it's going to be difficult for me to do very much debugging. The major
>>> difference I see between m5.opt and m5.fast, particularly on gcc of
>>> approximately the right versions, is that LTO is turned on.
>>>
>>> Gabe
>>>
>>> On Wed, May 24, 2017 at 7:04 PM, Gabe Black <***@google.com>
>>> wrote:
>>>
>>>> I think this has to do with the interaction between partial linking and
>>>> link time optimization. I'll keep looking into it.
>>>>
>>>> Gabe
>>>>
>>>> On Wed, May 24, 2017 at 2:00 PM, Jason Lowe-Power <***@lowepower.com>
>>>> wrote:
>>>>
>>>>> Hi everyone,
>>>>>
>>>>> So I've been able to reproduce the problem. I would bet it's due to
>>>>> the new partial linking code (
>>>>> https://gem5.googlesource.com/public/gem5/+/6bdd897f04f4efdf90d0761c6d31d3f960f4eacf).
>>>>> I'm not sure what the solution is, yet, or if I'll have time to look at it
>>>>> in the next few day. Gabe might have an idea, though, if that is the
>>>>> problem.
>>>>>
>>>>> Here's a matrix of what compilers are working and which aren't
>>>>> (gcc-4.8 is working, too, though not tested on travis).
>>>>> https://travis-ci.org/powerjg/gem5-ci-test/builds/235779432
>>>>>
>>>>> Jason
>>>>>
>>>>> On Tue, May 23, 2017 at 4:33 PM Moussa, Ayman <
>>>>> ***@imperial.ac.uk> wrote:
>>>>>
>>>>>> How can I check which compiler scons uses? These are the compilers on
>>>>>> my system
>>>>>>
>>>>>>
>>>>>> gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
>>>>>> g++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
>>>>>> Linux 4.4.0-75-generic #96-Ubuntu SMP
>>>>>>
>>>>>> ------------------------------
>>>>>> *From:* gem5-users <gem5-users-***@gem5.org> on behalf of Jason
>>>>>> Lowe-Power <***@lowepower.com>
>>>>>> *Sent:* 23 May 2017 22:27:34
>>>>>>
>>>>>> *To:* gem5 users mailing list
>>>>>> *Subject:* Re: [gem5-users] Link error building gem5.fast
>>>>>>
>>>>>> I just tried again and still cannot reproduce the error. What
>>>>>> compiler are you using?
>>>>>>
>>>>>> Jason
>>>>>>
>>>>>> On Tue, May 23, 2017 at 3:41 PM Moussa, Ayman <
>>>>>> ***@imperial.ac.uk> wrote:
>>>>>>
>>>>>>> Hey
>>>>>>>
>>>>>>>
>>>>>>> I've encountered this exact problem with x86 and it only seems to be
>>>>>>> for gem5.fast (gem5.opt works fine). I still have problems with a clean
>>>>>>> build as Jason suggested so I reverted back to some random commit on the
>>>>>>> gem5 repository and it works but it's not what I was looking for though.
>>>>>>> Hope this gets fixed soon.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------
>>>>>>> *From:* gem5-users <gem5-users-***@gem5.org> on behalf of Alec
>>>>>>> Roelke <***@virginia.edu>
>>>>>>> *Sent:* 23 May 2017 21:14:10
>>>>>>> *To:* gem5 users mailing list
>>>>>>> *Subject:* [gem5-users] Link error building gem5.fast
>>>>>>>
>>>>>>> Hi Everyone,
>>>>>>>
>>>>>>> When I try to build gem5.fast using any ISA, I get a lot of multiple
>>>>>>> definition errors during the final linking stage. For example, with x86:
>>>>>>>
>>>>>>> [ LINK] -> X86/gem5.fast.unstripped
>>>>>>> build/X86/arch/x86/bios/lib.fo.partial: In function
>>>>>>> `Drainable::drainResume()':
>>>>>>> (.text+0x5b00): multiple definition of `Drainable::drainResume()'
>>>>>>> build/X86/dev/x86/lib.fo.partial:(.text+0x0): first defined here
>>>>>>>
>>>>>>> There are way too many of these to list them all, but they're all
>>>>>>> multiple definitions of symbols. Has anyone else encountered this?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Alec Roelke
>>>>>>> _______________________________________________
>>>>>>> gem5-users mailing list
>>>>>>> gem5-***@gem5.org
>>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>>>>
>>>>>> _______________________________________________
>>>>>> gem5-users mailing list
>>>>>> gem5-***@gem5.org
>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> gem5-users mailing list
>>> gem5-***@gem5.org
>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>
>>
>> _______________________________________________
>> gem5-users mailing list
>> gem5-***@gem5.org
>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>
>
> _______________________________________________
> gem5-users mailing list
> gem5-***@gem5.org
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

[Jason Lowe-Power]

Hi Alec,

I recently saw another message about this on gem5-users (
https://www.mail-archive.com/gem5-***@gem5.org/msg14291.html). I tested
it on a clean build and didn't see any issues. Do you have this problem
with a clean build?

Jason

On Tue, May 23, 2017 at 3:14 PM Alec Roelke <***@virginia.edu> wrote:

> Hi Everyone,
>
> When I try to build gem5.fast using any ISA, I get a lot of multiple
> definition errors during the final linking stage. For example, with x86:
>
> [ LINK] -> X86/gem5.fast.unstripped
> build/X86/arch/x86/bios/lib.fo.partial: In function
> `Drainable::drainResume()':
> (.text+0x5b00): multiple definition of `Drainable::drainResume()'
> build/X86/dev/x86/lib.fo.partial:(.text+0x0): first defined here
>
> There are way too many of these to list them all, but they're all multiple
> definitions of symbols. Has anyone else encountered this?
>
> Thanks,
> Alec Roelke
> _______________________________________________
> gem5-users mailing list
> gem5-***@gem5.org
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

[Gabe Black]

Did you try filtering out the lto option from the partial link steps like I
suggested? Look at how I do that for -shared as an example.

Gabe

On May 24, 2017 2:00 PM, "Jason Lowe-Power" <***@lowepower.com> wrote:

> Hi everyone,
>
> So I've been able to reproduce the problem. I would bet it's due to the
> new partial linking code (https://gem5.googlesource.com/public/gem5/+/
> 6bdd897f04f4efdf90d0761c6d31d3f960f4eacf). I'm not sure what the solution
> is, yet, or if I'll have time to look at it in the next few day. Gabe might
> have an idea, though, if that is the problem.
>
> Here's a matrix of what compilers are working and which aren't (gcc-4.8 is
> working, too, though not tested on travis).
> https://travis-ci.org/powerjg/gem5-ci-test/builds/235779432
>
> Jason
>
> On Tue, May 23, 2017 at 4:33 PM Moussa, Ayman <
> ***@imperial.ac.uk> wrote:
>
>> How can I check which compiler scons uses? These are the compilers on my
>> system
>>
>>
>> gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
>> g++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
>> Linux 4.4.0-75-generic #96-Ubuntu SMP
>>
>> ------------------------------
>> *From:* gem5-users <gem5-users-***@gem5.org> on behalf of Jason
>> Lowe-Power <***@lowepower.com>
>> *Sent:* 23 May 2017 22:27:34
>>
>> *To:* gem5 users mailing list
>> *Subject:* Re: [gem5-users] Link error building gem5.fast
>>
>> I just tried again and still cannot reproduce the error. What compiler
>> are you using?
>>
>> Jason
>>
>> On Tue, May 23, 2017 at 3:41 PM Moussa, Ayman <
>> ***@imperial.ac.uk> wrote:
>>
>>> Hey
>>>
>>>
>>> I've encountered this exact problem with x86 and it only seems to be for
>>> gem5.fast (gem5.opt works fine). I still have problems with a clean build
>>> as Jason suggested so I reverted back to some random commit on the gem5
>>> repository and it works but it's not what I was looking for though. Hope
>>> this gets fixed soon.
>>>
>>>
>>>
>>> ------------------------------
>>> *From:* gem5-users <gem5-users-***@gem5.org> on behalf of Alec
>>> Roelke <***@virginia.edu>
>>> *Sent:* 23 May 2017 21:14:10
>>> *To:* gem5 users mailing list
>>> *Subject:* [gem5-users] Link error building gem5.fast
>>>
>>> Hi Everyone,
>>>
>>> When I try to build gem5.fast using any ISA, I get a lot of multiple
>>> definition errors during the final linking stage. For example, with x86:
>>>
>>> [ LINK] -> X86/gem5.fast.unstripped
>>> build/X86/arch/x86/bios/lib.fo.partial: In function
>>> `Drainable::drainResume()':
>>> (.text+0x5b00): multiple definition of `Drainable::drainResume()'
>>> build/X86/dev/x86/lib.fo.partial:(.text+0x0): first defined here
>>>
>>> There are way too many of these to list them all, but they're all
>>> multiple definitions of symbols. Has anyone else encountered this?
>>>
>>> Thanks,
>>> Alec Roelke
>>> _______________________________________________
>>> gem5-users mailing list
>>> gem5-***@gem5.org
>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>
>> _______________________________________________
>> gem5-users mailing list
>> gem5-***@gem5.org
>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
>

[Jason Lowe-Power]

I tried passing -no-lto with ['-r', '-nostdlib'] on line SConstruct:688.
However, that caused the error/warning:
"/usr/bin/ld: build/X86/dev/io_device.fo: plugin needed to handle lto
object" for every lib.fo.partial. I guess the -lto option during .cc->.o
puts some data in the .o. Then, when partially linking with -r gcc gets
confused?

Should I filter out the -lto=8 from all of the .cc->.o? I could have
mis-understood how to do this.

Jason

On Sun, Jun 4, 2017 at 4:08 PM Gabe Black <***@google.com> wrote:

> Did you try filtering out the lto option from the partial link steps like
> I suggested? Look at how I do that for -shared as an example.
>
> Gabe
>
> On May 24, 2017 2:00 PM, "Jason Lowe-Power" <***@lowepower.com> wrote:
>
>> Hi everyone,
>>
>> So I've been able to reproduce the problem. I would bet it's due to the
>> new partial linking code (
>> https://gem5.googlesource.com/public/gem5/+/6bdd897f04f4efdf90d0761c6d31d3f960f4eacf).
>> I'm not sure what the solution is, yet, or if I'll have time to look at it
>> in the next few day. Gabe might have an idea, though, if that is the
>> problem.
>>
>> Here's a matrix of what compilers are working and which aren't (gcc-4.8
>> is working, too, though not tested on travis).
>> https://travis-ci.org/powerjg/gem5-ci-test/builds/235779432
>>
>> Jason
>>
>> On Tue, May 23, 2017 at 4:33 PM Moussa, Ayman <
>> ***@imperial.ac.uk> wrote:
>>
>>> How can I check which compiler scons uses? These are the compilers on my
>>> system
>>>
>>>
>>> gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
>>> g++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
>>> Linux 4.4.0-75-generic #96-Ubuntu SMP
>>>
>>> ------------------------------
>>> *From:* gem5-users <gem5-users-***@gem5.org> on behalf of Jason
>>> Lowe-Power <***@lowepower.com>
>>> *Sent:* 23 May 2017 22:27:34
>>>
>>> *To:* gem5 users mailing list
>>> *Subject:* Re: [gem5-users] Link error building gem5.fast
>>>
>>> I just tried again and still cannot reproduce the error. What compiler
>>> are you using?
>>>
>>> Jason
>>>
>>> On Tue, May 23, 2017 at 3:41 PM Moussa, Ayman <
>>> ***@imperial.ac.uk> wrote:
>>>
>>>> Hey
>>>>
>>>>
>>>> I've encountered this exact problem with x86 and it only seems to be
>>>> for gem5.fast (gem5.opt works fine). I still have problems with a clean
>>>> build as Jason suggested so I reverted back to some random commit on the
>>>> gem5 repository and it works but it's not what I was looking for though.
>>>> Hope this gets fixed soon.
>>>>
>>>>
>>>>
>>>> ------------------------------
>>>> *From:* gem5-users <gem5-users-***@gem5.org> on behalf of Alec
>>>> Roelke <***@virginia.edu>
>>>> *Sent:* 23 May 2017 21:14:10
>>>> *To:* gem5 users mailing list
>>>> *Subject:* [gem5-users] Link error building gem5.fast
>>>>
>>>> Hi Everyone,
>>>>
>>>> When I try to build gem5.fast using any ISA, I get a lot of multiple
>>>> definition errors during the final linking stage. For example, with x86:
>>>>
>>>> [ LINK] -> X86/gem5.fast.unstripped
>>>> build/X86/arch/x86/bios/lib.fo.partial: In function
>>>> `Drainable::drainResume()':
>>>> (.text+0x5b00): multiple definition of `Drainable::drainResume()'
>>>> build/X86/dev/x86/lib.fo.partial:(.text+0x0): first defined here
>>>>
>>>> There are way too many of these to list them all, but they're all
>>>> multiple definitions of symbols. Has anyone else encountered this?
>>>>
>>>> Thanks,
>>>> Alec Roelke
>>>> _______________________________________________
>>>> gem5-users mailing list
>>>> gem5-***@gem5.org
>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>
>>> _______________________________________________
>>> gem5-users mailing list
>>> gem5-***@gem5.org
>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>
>>

[Gabe Black]

I was hoping we could leave the lto in the .cc->.o but take it out of the
partial links, and that that would fix the problem. If you have a docker
image I can try this all out on, that would be helpful. If I can get ahold
of that somehow, I can try to figure out how to fix this on Monday. I'd
speculate what's happening is that little inline functions, etc., which I
think are called "common" symbols are showing up more than once. Normally
that's ok and the linker will figure that out and get rid of the extra
copies, but apparently here it isn't doing that. There's a scons variable
which you can use to disable lto in the fast build if you want a workaround
for right now, although using gem5.fast is a bit dangerous in the first
place since I think it disables asserts, etc.

Gabe

On Sun, Jun 4, 2017 at 2:11 PM, Jason Lowe-Power <***@lowepower.com>
wrote:

> I tried passing -no-lto with ['-r', '-nostdlib'] on line SConstruct:688.
> However, that caused the error/warning:
> "/usr/bin/ld: build/X86/dev/io_device.fo: plugin needed to handle lto
> object" for every lib.fo.partial. I guess the -lto option during .cc->.o
> puts some data in the .o. Then, when partially linking with -r gcc gets
> confused?
>
> Should I filter out the -lto=8 from all of the .cc->.o? I could have
> mis-understood how to do this.
>
> Jason
>
> On Sun, Jun 4, 2017 at 4:08 PM Gabe Black <***@google.com> wrote:
>
>> Did you try filtering out the lto option from the partial link steps like
>> I suggested? Look at how I do that for -shared as an example.
>>
>> Gabe
>>
>> On May 24, 2017 2:00 PM, "Jason Lowe-Power" <***@lowepower.com> wrote:
>>
>>> Hi everyone,
>>>
>>> So I've been able to reproduce the problem. I would bet it's due to the
>>> new partial linking code (https://gem5.googlesource.com/public/gem5/+/
>>> 6bdd897f04f4efdf90d0761c6d31d3f960f4eacf). I'm not sure what the
>>> solution is, yet, or if I'll have time to look at it in the next few day.
>>> Gabe might have an idea, though, if that is the problem.
>>>
>>> Here's a matrix of what compilers are working and which aren't (gcc-4.8
>>> is working, too, though not tested on travis).
>>> https://travis-ci.org/powerjg/gem5-ci-test/builds/235779432
>>>
>>> Jason
>>>
>>> On Tue, May 23, 2017 at 4:33 PM Moussa, Ayman <
>>> ***@imperial.ac.uk> wrote:
>>>
>>>> How can I check which compiler scons uses? These are the compilers on
>>>> my system
>>>>
>>>>
>>>> gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
>>>> g++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
>>>> Linux 4.4.0-75-generic #96-Ubuntu SMP
>>>>
>>>> ------------------------------
>>>> *From:* gem5-users <gem5-users-***@gem5.org> on behalf of Jason
>>>> Lowe-Power <***@lowepower.com>
>>>> *Sent:* 23 May 2017 22:27:34
>>>>
>>>> *To:* gem5 users mailing list
>>>> *Subject:* Re: [gem5-users] Link error building gem5.fast
>>>>
>>>> I just tried again and still cannot reproduce the error. What compiler
>>>> are you using?
>>>>
>>>> Jason
>>>>
>>>> On Tue, May 23, 2017 at 3:41 PM Moussa, Ayman <
>>>> ***@imperial.ac.uk> wrote:
>>>>
>>>>> Hey
>>>>>
>>>>>
>>>>> I've encountered this exact problem with x86 and it only seems to be
>>>>> for gem5.fast (gem5.opt works fine). I still have problems with a clean
>>>>> build as Jason suggested so I reverted back to some random commit on the
>>>>> gem5 repository and it works but it's not what I was looking for though.
>>>>> Hope this gets fixed soon.
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------
>>>>> *From:* gem5-users <gem5-users-***@gem5.org> on behalf of Alec
>>>>> Roelke <***@virginia.edu>
>>>>> *Sent:* 23 May 2017 21:14:10
>>>>> *To:* gem5 users mailing list
>>>>> *Subject:* [gem5-users] Link error building gem5.fast
>>>>>
>>>>> Hi Everyone,
>>>>>
>>>>> When I try to build gem5.fast using any ISA, I get a lot of multiple
>>>>> definition errors during the final linking stage. For example, with x86:
>>>>>
>>>>> [ LINK] -> X86/gem5.fast.unstripped
>>>>> build/X86/arch/x86/bios/lib.fo.partial: In function
>>>>> `Drainable::drainResume()':
>>>>> (.text+0x5b00): multiple definition of `Drainable::drainResume()'
>>>>> build/X86/dev/x86/lib.fo.partial:(.text+0x0): first defined here
>>>>>
>>>>> There are way too many of these to list them all, but they're all
>>>>> multiple definitions of symbols. Has anyone else encountered this?
>>>>>
>>>>> Thanks,
>>>>> Alec Roelke
>>>>> _______________________________________________
>>>>> gem5-users mailing list
>>>>> gem5-***@gem5.org
>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>>
>>>> _______________________________________________
>>>> gem5-users mailing list
>>>> gem5-***@gem5.org
>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>
>>>

[Jason Lowe-Power]

Hi Gabe,

I think the follow "just works" by downloading the image from dockerhub.

> docker run -v `pwd`:`pwd` -it powerjg/gem5-gcc-6-build /bin/bash

Or, to just download the image:

> docker pull powerjg/gem5-gcc-6-build

Let me know if that doesn't work for you.

I searched around some to try to track down the issue. It seems that GCC
doesn't love doing LTO and partial linking. There have been a number of
bugs related to this in the past. But, all of the bugs that I found had
been fixed before gcc 5.

Cheers,
Jason

On Sun, Jun 4, 2017 at 4:37 PM Gabe Black <***@google.com> wrote:

> I was hoping we could leave the lto in the .cc->.o but take it out of the
> partial links, and that that would fix the problem. If you have a docker
> image I can try this all out on, that would be helpful. If I can get ahold
> of that somehow, I can try to figure out how to fix this on Monday. I'd
> speculate what's happening is that little inline functions, etc., which I
> think are called "common" symbols are showing up more than once. Normally
> that's ok and the linker will figure that out and get rid of the extra
> copies, but apparently here it isn't doing that. There's a scons variable
> which you can use to disable lto in the fast build if you want a workaround
> for right now, although using gem5.fast is a bit dangerous in the first
> place since I think it disables asserts, etc.
>
> Gabe
>
> On Sun, Jun 4, 2017 at 2:11 PM, Jason Lowe-Power <***@lowepower.com>
> wrote:
>
>> I tried passing -no-lto with ['-r', '-nostdlib'] on line SConstruct:688.
>> However, that caused the error/warning:
>> "/usr/bin/ld: build/X86/dev/io_device.fo: plugin needed to handle lto
>> object" for every lib.fo.partial. I guess the -lto option during .cc->.o
>> puts some data in the .o. Then, when partially linking with -r gcc gets
>> confused?
>>
>> Should I filter out the -lto=8 from all of the .cc->.o? I could have
>> mis-understood how to do this.
>>
>> Jason
>>
>> On Sun, Jun 4, 2017 at 4:08 PM Gabe Black <***@google.com> wrote:
>>
>>> Did you try filtering out the lto option from the partial link steps
>>> like I suggested? Look at how I do that for -shared as an example.
>>>
>>> Gabe
>>>
>>> On May 24, 2017 2:00 PM, "Jason Lowe-Power" <***@lowepower.com> wrote:
>>>
>>>> Hi everyone,
>>>>
>>>> So I've been able to reproduce the problem. I would bet it's due to the
>>>> new partial linking code (
>>>> https://gem5.googlesource.com/public/gem5/+/6bdd897f04f4efdf90d0761c6d31d3f960f4eacf).
>>>> I'm not sure what the solution is, yet, or if I'll have time to look at it
>>>> in the next few day. Gabe might have an idea, though, if that is the
>>>> problem.
>>>>
>>>> Here's a matrix of what compilers are working and which aren't (gcc-4.8
>>>> is working, too, though not tested on travis).
>>>> https://travis-ci.org/powerjg/gem5-ci-test/builds/235779432
>>>>
>>>> Jason
>>>>
>>>> On Tue, May 23, 2017 at 4:33 PM Moussa, Ayman <
>>>> ***@imperial.ac.uk> wrote:
>>>>
>>>>> How can I check which compiler scons uses? These are the compilers on
>>>>> my system
>>>>>
>>>>>
>>>>> gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
>>>>> g++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
>>>>> Linux 4.4.0-75-generic #96-Ubuntu SMP
>>>>>
>>>>> ------------------------------
>>>>> *From:* gem5-users <gem5-users-***@gem5.org> on behalf of Jason
>>>>> Lowe-Power <***@lowepower.com>
>>>>> *Sent:* 23 May 2017 22:27:34
>>>>>
>>>>> *To:* gem5 users mailing list
>>>>> *Subject:* Re: [gem5-users] Link error building gem5.fast
>>>>>
>>>>> I just tried again and still cannot reproduce the error. What compiler
>>>>> are you using?
>>>>>
>>>>> Jason
>>>>>
>>>>> On Tue, May 23, 2017 at 3:41 PM Moussa, Ayman <
>>>>> ***@imperial.ac.uk> wrote:
>>>>>
>>>>>> Hey
>>>>>>
>>>>>>
>>>>>> I've encountered this exact problem with x86 and it only seems to be
>>>>>> for gem5.fast (gem5.opt works fine). I still have problems with a clean
>>>>>> build as Jason suggested so I reverted back to some random commit on the
>>>>>> gem5 repository and it works but it's not what I was looking for though.
>>>>>> Hope this gets fixed soon.
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------
>>>>>> *From:* gem5-users <gem5-users-***@gem5.org> on behalf of Alec
>>>>>> Roelke <***@virginia.edu>
>>>>>> *Sent:* 23 May 2017 21:14:10
>>>>>> *To:* gem5 users mailing list
>>>>>> *Subject:* [gem5-users] Link error building gem5.fast
>>>>>>
>>>>>> Hi Everyone,
>>>>>>
>>>>>> When I try to build gem5.fast using any ISA, I get a lot of multiple
>>>>>> definition errors during the final linking stage. For example, with x86:
>>>>>>
>>>>>> [ LINK] -> X86/gem5.fast.unstripped
>>>>>> build/X86/arch/x86/bios/lib.fo.partial: In function
>>>>>> `Drainable::drainResume()':
>>>>>> (.text+0x5b00): multiple definition of `Drainable::drainResume()'
>>>>>> build/X86/dev/x86/lib.fo.partial:(.text+0x0): first defined here
>>>>>>
>>>>>> There are way too many of these to list them all, but they're all
>>>>>> multiple definitions of symbols. Has anyone else encountered this?
>>>>>>
>>>>>> Thanks,
>>>>>> Alec Roelke
>>>>>> _______________________________________________
>>>>>> gem5-users mailing list
>>>>>> gem5-***@gem5.org
>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>>>
>>>>> _______________________________________________
>>>>> gem5-users mailing list
>>>>> gem5-***@gem5.org
>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>>
>>>>
>

[Gabe Black]

Ok, I did some digging around about this, and while a lot of the talk
between gcc devs sounds like gibberish to me, I did pick out bits and
pieces which makes me think this is just something that's broken in gcc of
particular versions. There's some documentation of the state of things in
gcc version 6 where it says things are fixed to the point where they can be
worked with, and that in version 7 they expect them to be totally fixed up:

https://gcc.gnu.org/gcc-6/changes.html

The problem seems to be that there were assumptions being made in the LTO
gcc plugin that the link was a final link all the time, and that weak
external symbols (the inline functions that might show up multiple times)
should be promoted to regular external symbols. That breaks things since,
in subsequent links, there are more copies of them and they all look like
they're supposed to be unique.

What I think we should do is detect what situation we're in and react
accordingly. In gcc version 5.0-6.0 (maybe 4.9 or 4.8, although 4.8 seems
to work for me) we need to avoid doing either partial linking or LTO since
the combination doesn't work. It would be easier to make scons avoid LTO
since that would just be changing the compiler flags and not structurally
changing how the build flows or how the scons scripts are written.

In versions 6.0 to 7.0, if those release notes are to be believed, we would
need to decide between doing the partial link with gcc or with ld. It
sounds like ld is better since it would still do whole program
optimization, although again it might be more difficult to twist scon's arm
and get it to do things that way since its linker command line uses gcc. We
could pass -r to ld directly by wrapping it in -Wl,-r, but that apparently
caused issues for people on macs.

And then, in the glorious future where we're using gcc v7 which works
properly, or if you're using clang, we can stop worrying about it since -r
and -lto will play nicely together.

Thoughts?

Gabe

On Sun, Jun 4, 2017 at 3:11 PM, Jason Lowe-Power <***@lowepower.com>
wrote:

> Hi Gabe,
>
> I think the follow "just works" by downloading the image from dockerhub.
>
> > docker run -v `pwd`:`pwd` -it powerjg/gem5-gcc-6-build /bin/bash
>
> Or, to just download the image:
>
> > docker pull powerjg/gem5-gcc-6-build
>
> Let me know if that doesn't work for you.
>
> I searched around some to try to track down the issue. It seems that GCC
> doesn't love doing LTO and partial linking. There have been a number of
> bugs related to this in the past. But, all of the bugs that I found had
> been fixed before gcc 5.
>
> Cheers,
> Jason
>
> On Sun, Jun 4, 2017 at 4:37 PM Gabe Black <***@google.com> wrote:
>
>> I was hoping we could leave the lto in the .cc->.o but take it out of the
>> partial links, and that that would fix the problem. If you have a docker
>> image I can try this all out on, that would be helpful. If I can get ahold
>> of that somehow, I can try to figure out how to fix this on Monday. I'd
>> speculate what's happening is that little inline functions, etc., which I
>> think are called "common" symbols are showing up more than once. Normally
>> that's ok and the linker will figure that out and get rid of the extra
>> copies, but apparently here it isn't doing that. There's a scons variable
>> which you can use to disable lto in the fast build if you want a workaround
>> for right now, although using gem5.fast is a bit dangerous in the first
>> place since I think it disables asserts, etc.
>>
>> Gabe
>>
>> On Sun, Jun 4, 2017 at 2:11 PM, Jason Lowe-Power <***@lowepower.com>
>> wrote:
>>
>>> I tried passing -no-lto with ['-r', '-nostdlib'] on line
>>> SConstruct:688. However, that caused the error/warning:
>>> "/usr/bin/ld: build/X86/dev/io_device.fo: plugin needed to handle lto
>>> object" for every lib.fo.partial. I guess the -lto option during .cc->.o
>>> puts some data in the .o. Then, when partially linking with -r gcc gets
>>> confused?
>>>
>>> Should I filter out the -lto=8 from all of the .cc->.o? I could have
>>> mis-understood how to do this.
>>>
>>> Jason
>>>
>>> On Sun, Jun 4, 2017 at 4:08 PM Gabe Black <***@google.com> wrote:
>>>
>>>> Did you try filtering out the lto option from the partial link steps
>>>> like I suggested? Look at how I do that for -shared as an example.
>>>>
>>>> Gabe
>>>>
>>>> On May 24, 2017 2:00 PM, "Jason Lowe-Power" <***@lowepower.com>
>>>> wrote:
>>>>
>>>>> Hi everyone,
>>>>>
>>>>> So I've been able to reproduce the problem. I would bet it's due to
>>>>> the new partial linking code (https://gem5.googlesource.
>>>>> com/public/gem5/+/6bdd897f04f4efdf90d0761c6d31d3f960f4eacf). I'm not
>>>>> sure what the solution is, yet, or if I'll have time to look at it in the
>>>>> next few day. Gabe might have an idea, though, if that is the problem.
>>>>>
>>>>> Here's a matrix of what compilers are working and which aren't
>>>>> (gcc-4.8 is working, too, though not tested on travis).
>>>>> https://travis-ci.org/powerjg/gem5-ci-test/builds/235779432
>>>>>
>>>>> Jason
>>>>>
>>>>> On Tue, May 23, 2017 at 4:33 PM Moussa, Ayman <
>>>>> ***@imperial.ac.uk> wrote:
>>>>>
>>>>>> How can I check which compiler scons uses? These are the compilers on
>>>>>> my system
>>>>>>
>>>>>>
>>>>>> gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
>>>>>> g++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
>>>>>> Linux 4.4.0-75-generic #96-Ubuntu SMP
>>>>>>
>>>>>> ------------------------------
>>>>>> *From:* gem5-users <gem5-users-***@gem5.org> on behalf of Jason
>>>>>> Lowe-Power <***@lowepower.com>
>>>>>> *Sent:* 23 May 2017 22:27:34
>>>>>>
>>>>>> *To:* gem5 users mailing list
>>>>>> *Subject:* Re: [gem5-users] Link error building gem5.fast
>>>>>>
>>>>>> I just tried again and still cannot reproduce the error. What
>>>>>> compiler are you using?
>>>>>>
>>>>>> Jason
>>>>>>
>>>>>> On Tue, May 23, 2017 at 3:41 PM Moussa, Ayman <
>>>>>> ***@imperial.ac.uk> wrote:
>>>>>>
>>>>>>> Hey
>>>>>>>
>>>>>>>
>>>>>>> I've encountered this exact problem with x86 and it only seems to be
>>>>>>> for gem5.fast (gem5.opt works fine). I still have problems with a clean
>>>>>>> build as Jason suggested so I reverted back to some random commit on the
>>>>>>> gem5 repository and it works but it's not what I was looking for though.
>>>>>>> Hope this gets fixed soon.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------
>>>>>>> *From:* gem5-users <gem5-users-***@gem5.org> on behalf of Alec
>>>>>>> Roelke <***@virginia.edu>
>>>>>>> *Sent:* 23 May 2017 21:14:10
>>>>>>> *To:* gem5 users mailing list
>>>>>>> *Subject:* [gem5-users] Link error building gem5.fast
>>>>>>>
>>>>>>> Hi Everyone,
>>>>>>>
>>>>>>> When I try to build gem5.fast using any ISA, I get a lot of multiple
>>>>>>> definition errors during the final linking stage. For example, with x86:
>>>>>>>
>>>>>>> [ LINK] -> X86/gem5.fast.unstripped
>>>>>>> build/X86/arch/x86/bios/lib.fo.partial: In function
>>>>>>> `Drainable::drainResume()':
>>>>>>> (.text+0x5b00): multiple definition of `Drainable::drainResume()'
>>>>>>> build/X86/dev/x86/lib.fo.partial:(.text+0x0): first defined here
>>>>>>>
>>>>>>> There are way too many of these to list them all, but they're all
>>>>>>> multiple definitions of symbols. Has anyone else encountered this?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Alec Roelke
>>>>>>> _______________________________________________
>>>>>>> gem5-users mailing list
>>>>>>> gem5-***@gem5.org
>>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>>>>
>>>>>> _______________________________________________
>>>>>> gem5-users mailing list
>>>>>> gem5-***@gem5.org
>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>>>
>>>>>
>>

[Gabe Black]

I also used this thread/bug as a basis for my diagnosis.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67548

On Mon, Jun 5, 2017 at 2:40 PM, Gabe Black <***@google.com> wrote:

> Ok, I did some digging around about this, and while a lot of the talk
> between gcc devs sounds like gibberish to me, I did pick out bits and
> pieces which makes me think this is just something that's broken in gcc of
> particular versions. There's some documentation of the state of things in
> gcc version 6 where it says things are fixed to the point where they can be
> worked with, and that in version 7 they expect them to be totally fixed up:
>
> https://gcc.gnu.org/gcc-6/changes.html
>
> The problem seems to be that there were assumptions being made in the LTO
> gcc plugin that the link was a final link all the time, and that weak
> external symbols (the inline functions that might show up multiple times)
> should be promoted to regular external symbols. That breaks things since,
> in subsequent links, there are more copies of them and they all look like
> they're supposed to be unique.
>
> What I think we should do is detect what situation we're in and react
> accordingly. In gcc version 5.0-6.0 (maybe 4.9 or 4.8, although 4.8 seems
> to work for me) we need to avoid doing either partial linking or LTO since
> the combination doesn't work. It would be easier to make scons avoid LTO
> since that would just be changing the compiler flags and not structurally
> changing how the build flows or how the scons scripts are written.
>
> In versions 6.0 to 7.0, if those release notes are to be believed, we
> would need to decide between doing the partial link with gcc or with ld. It
> sounds like ld is better since it would still do whole program
> optimization, although again it might be more difficult to twist scon's arm
> and get it to do things that way since its linker command line uses gcc. We
> could pass -r to ld directly by wrapping it in -Wl,-r, but that apparently
> caused issues for people on macs.
>
> And then, in the glorious future where we're using gcc v7 which works
> properly, or if you're using clang, we can stop worrying about it since -r
> and -lto will play nicely together.
>
> Thoughts?
>
> Gabe
>
> On Sun, Jun 4, 2017 at 3:11 PM, Jason Lowe-Power <***@lowepower.com>
> wrote:
>
>> Hi Gabe,
>>
>> I think the follow "just works" by downloading the image from dockerhub.
>>
>> > docker run -v `pwd`:`pwd` -it powerjg/gem5-gcc-6-build /bin/bash
>>
>> Or, to just download the image:
>>
>> > docker pull powerjg/gem5-gcc-6-build
>>
>> Let me know if that doesn't work for you.
>>
>> I searched around some to try to track down the issue. It seems that GCC
>> doesn't love doing LTO and partial linking. There have been a number of
>> bugs related to this in the past. But, all of the bugs that I found had
>> been fixed before gcc 5.
>>
>> Cheers,
>> Jason
>>
>> On Sun, Jun 4, 2017 at 4:37 PM Gabe Black <***@google.com> wrote:
>>
>>> I was hoping we could leave the lto in the .cc->.o but take it out of
>>> the partial links, and that that would fix the problem. If you have a
>>> docker image I can try this all out on, that would be helpful. If I can get
>>> ahold of that somehow, I can try to figure out how to fix this on Monday.
>>> I'd speculate what's happening is that little inline functions, etc., which
>>> I think are called "common" symbols are showing up more than once. Normally
>>> that's ok and the linker will figure that out and get rid of the extra
>>> copies, but apparently here it isn't doing that. There's a scons variable
>>> which you can use to disable lto in the fast build if you want a workaround
>>> for right now, although using gem5.fast is a bit dangerous in the first
>>> place since I think it disables asserts, etc.
>>>
>>> Gabe
>>>
>>> On Sun, Jun 4, 2017 at 2:11 PM, Jason Lowe-Power <***@lowepower.com>
>>> wrote:
>>>
>>>> I tried passing -no-lto with ['-r', '-nostdlib'] on line
>>>> SConstruct:688. However, that caused the error/warning:
>>>> "/usr/bin/ld: build/X86/dev/io_device.fo: plugin needed to handle lto
>>>> object" for every lib.fo.partial. I guess the -lto option during .cc->.o
>>>> puts some data in the .o. Then, when partially linking with -r gcc gets
>>>> confused?
>>>>
>>>> Should I filter out the -lto=8 from all of the .cc->.o? I could have
>>>> mis-understood how to do this.
>>>>
>>>> Jason
>>>>
>>>> On Sun, Jun 4, 2017 at 4:08 PM Gabe Black <***@google.com> wrote:
>>>>
>>>>> Did you try filtering out the lto option from the partial link steps
>>>>> like I suggested? Look at how I do that for -shared as an example.
>>>>>
>>>>> Gabe
>>>>>
>>>>> On May 24, 2017 2:00 PM, "Jason Lowe-Power" <***@lowepower.com>
>>>>> wrote:
>>>>>
>>>>>> Hi everyone,
>>>>>>
>>>>>> So I've been able to reproduce the problem. I would bet it's due to
>>>>>> the new partial linking code (https://gem5.googlesource.com
>>>>>> /public/gem5/+/6bdd897f04f4efdf90d0761c6d31d3f960f4eacf). I'm not
>>>>>> sure what the solution is, yet, or if I'll have time to look at it in the
>>>>>> next few day. Gabe might have an idea, though, if that is the problem.
>>>>>>
>>>>>> Here's a matrix of what compilers are working and which aren't
>>>>>> (gcc-4.8 is working, too, though not tested on travis).
>>>>>> https://travis-ci.org/powerjg/gem5-ci-test/builds/235779432
>>>>>>
>>>>>> Jason
>>>>>>
>>>>>> On Tue, May 23, 2017 at 4:33 PM Moussa, Ayman <
>>>>>> ***@imperial.ac.uk> wrote:
>>>>>>
>>>>>>> How can I check which compiler scons uses? These are the compilers
>>>>>>> on my system
>>>>>>>
>>>>>>>
>>>>>>> gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
>>>>>>> g++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
>>>>>>> Linux 4.4.0-75-generic #96-Ubuntu SMP
>>>>>>>
>>>>>>> ------------------------------
>>>>>>> *From:* gem5-users <gem5-users-***@gem5.org> on behalf of Jason
>>>>>>> Lowe-Power <***@lowepower.com>
>>>>>>> *Sent:* 23 May 2017 22:27:34
>>>>>>>
>>>>>>> *To:* gem5 users mailing list
>>>>>>> *Subject:* Re: [gem5-users] Link error building gem5.fast
>>>>>>>
>>>>>>> I just tried again and still cannot reproduce the error. What
>>>>>>> compiler are you using?
>>>>>>>
>>>>>>> Jason
>>>>>>>
>>>>>>> On Tue, May 23, 2017 at 3:41 PM Moussa, Ayman <
>>>>>>> ***@imperial.ac.uk> wrote:
>>>>>>>
>>>>>>>> Hey
>>>>>>>>
>>>>>>>>
>>>>>>>> I've encountered this exact problem with x86 and it only seems to
>>>>>>>> be for gem5.fast (gem5.opt works fine). I still have problems with a clean
>>>>>>>> build as Jason suggested so I reverted back to some random commit on the
>>>>>>>> gem5 repository and it works but it's not what I was looking for though.
>>>>>>>> Hope this gets fixed soon.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------
>>>>>>>> *From:* gem5-users <gem5-users-***@gem5.org> on behalf of Alec
>>>>>>>> Roelke <***@virginia.edu>
>>>>>>>> *Sent:* 23 May 2017 21:14:10
>>>>>>>> *To:* gem5 users mailing list
>>>>>>>> *Subject:* [gem5-users] Link error building gem5.fast
>>>>>>>>
>>>>>>>> Hi Everyone,
>>>>>>>>
>>>>>>>> When I try to build gem5.fast using any ISA, I get a lot of
>>>>>>>> multiple definition errors during the final linking stage. For example,
>>>>>>>> with x86:
>>>>>>>>
>>>>>>>> [ LINK] -> X86/gem5.fast.unstripped
>>>>>>>> build/X86/arch/x86/bios/lib.fo.partial: In function
>>>>>>>> `Drainable::drainResume()':
>>>>>>>> (.text+0x5b00): multiple definition of `Drainable::drainResume()'
>>>>>>>> build/X86/dev/x86/lib.fo.partial:(.text+0x0): first defined here
>>>>>>>>
>>>>>>>> There are way too many of these to list them all, but they're all
>>>>>>>> multiple definitions of symbols. Has anyone else encountered this?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Alec Roelke
>>>>>>>> _______________________________________________
>>>>>>>> gem5-users mailing list
>>>>>>>> gem5-***@gem5.org
>>>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> gem5-users mailing list
>>>>>>> gem5-***@gem5.org
>>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>>>>
>>>>>>
>>>
>

[Jason Lowe-Power]

I'm fine with dropping LTO on gcc 4.9-6. (It also works on gcc 4.8 for me,
BTW.) I it's also failing for gcc 6 (see
https://travis-ci.org/powerjg/gem5-ci-test).

If you make a patch for this, could you add some detailed comments so we
can "undo" this change when we all move to gcc 7+?

Thanks for tracking this down!

Jason

On Mon, Jun 5, 2017 at 4:47 PM Gabe Black <***@google.com> wrote:

> I also used this thread/bug as a basis for my diagnosis.
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67548
>
> On Mon, Jun 5, 2017 at 2:40 PM, Gabe Black <***@google.com> wrote:
>
>> Ok, I did some digging around about this, and while a lot of the talk
>> between gcc devs sounds like gibberish to me, I did pick out bits and
>> pieces which makes me think this is just something that's broken in gcc of
>> particular versions. There's some documentation of the state of things in
>> gcc version 6 where it says things are fixed to the point where they can be
>> worked with, and that in version 7 they expect them to be totally fixed up:
>>
>> https://gcc.gnu.org/gcc-6/changes.html
>>
>> The problem seems to be that there were assumptions being made in the LTO
>> gcc plugin that the link was a final link all the time, and that weak
>> external symbols (the inline functions that might show up multiple times)
>> should be promoted to regular external symbols. That breaks things since,
>> in subsequent links, there are more copies of them and they all look like
>> they're supposed to be unique.
>>
>> What I think we should do is detect what situation we're in and react
>> accordingly. In gcc version 5.0-6.0 (maybe 4.9 or 4.8, although 4.8 seems
>> to work for me) we need to avoid doing either partial linking or LTO since
>> the combination doesn't work. It would be easier to make scons avoid LTO
>> since that would just be changing the compiler flags and not structurally
>> changing how the build flows or how the scons scripts are written.
>>
>> In versions 6.0 to 7.0, if those release notes are to be believed, we
>> would need to decide between doing the partial link with gcc or with ld. It
>> sounds like ld is better since it would still do whole program
>> optimization, although again it might be more difficult to twist scon's arm
>> and get it to do things that way since its linker command line uses gcc. We
>> could pass -r to ld directly by wrapping it in -Wl,-r, but that apparently
>> caused issues for people on macs.
>>
>> And then, in the glorious future where we're using gcc v7 which works
>> properly, or if you're using clang, we can stop worrying about it since -r
>> and -lto will play nicely together.
>>
>> Thoughts?
>>
>> Gabe
>>
>> On Sun, Jun 4, 2017 at 3:11 PM, Jason Lowe-Power <***@lowepower.com>
>> wrote:
>>
>>> Hi Gabe,
>>>
>>> I think the follow "just works" by downloading the image from dockerhub.
>>>
>>> > docker run -v `pwd`:`pwd` -it powerjg/gem5-gcc-6-build /bin/bash
>>>
>>> Or, to just download the image:
>>>
>>> > docker pull powerjg/gem5-gcc-6-build
>>>
>>> Let me know if that doesn't work for you.
>>>
>>> I searched around some to try to track down the issue. It seems that GCC
>>> doesn't love doing LTO and partial linking. There have been a number of
>>> bugs related to this in the past. But, all of the bugs that I found had
>>> been fixed before gcc 5.
>>>
>>> Cheers,
>>> Jason
>>>
>>> On Sun, Jun 4, 2017 at 4:37 PM Gabe Black <***@google.com> wrote:
>>>
>>>> I was hoping we could leave the lto in the .cc->.o but take it out of
>>>> the partial links, and that that would fix the problem. If you have a
>>>> docker image I can try this all out on, that would be helpful. If I can get
>>>> ahold of that somehow, I can try to figure out how to fix this on Monday.
>>>> I'd speculate what's happening is that little inline functions, etc., which
>>>> I think are called "common" symbols are showing up more than once. Normally
>>>> that's ok and the linker will figure that out and get rid of the extra
>>>> copies, but apparently here it isn't doing that. There's a scons variable
>>>> which you can use to disable lto in the fast build if you want a workaround
>>>> for right now, although using gem5.fast is a bit dangerous in the first
>>>> place since I think it disables asserts, etc.
>>>>
>>>> Gabe
>>>>
>>>> On Sun, Jun 4, 2017 at 2:11 PM, Jason Lowe-Power <***@lowepower.com>
>>>> wrote:
>>>>
>>>>> I tried passing -no-lto with ['-r', '-nostdlib'] on line
>>>>> SConstruct:688. However, that caused the error/warning:
>>>>> "/usr/bin/ld: build/X86/dev/io_device.fo: plugin needed to handle lto
>>>>> object" for every lib.fo.partial. I guess the -lto option during .cc->.o
>>>>> puts some data in the .o. Then, when partially linking with -r gcc gets
>>>>> confused?
>>>>>
>>>>> Should I filter out the -lto=8 from all of the .cc->.o? I could have
>>>>> mis-understood how to do this.
>>>>>
>>>>> Jason
>>>>>
>>>>> On Sun, Jun 4, 2017 at 4:08 PM Gabe Black <***@google.com>
>>>>> wrote:
>>>>>
>>>>>> Did you try filtering out the lto option from the partial link steps
>>>>>> like I suggested? Look at how I do that for -shared as an example.
>>>>>>
>>>>>> Gabe
>>>>>>
>>>>>> On May 24, 2017 2:00 PM, "Jason Lowe-Power" <***@lowepower.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi everyone,
>>>>>>>
>>>>>>> So I've been able to reproduce the problem. I would bet it's due to
>>>>>>> the new partial linking code (
>>>>>>> https://gem5.googlesource.com/public/gem5/+/6bdd897f04f4efdf90d0761c6d31d3f960f4eacf).
>>>>>>> I'm not sure what the solution is, yet, or if I'll have time to look at it
>>>>>>> in the next few day. Gabe might have an idea, though, if that is the
>>>>>>> problem.
>>>>>>>
>>>>>>> Here's a matrix of what compilers are working and which aren't
>>>>>>> (gcc-4.8 is working, too, though not tested on travis).
>>>>>>> https://travis-ci.org/powerjg/gem5-ci-test/builds/235779432
>>>>>>>
>>>>>>> Jason
>>>>>>>
>>>>>>> On Tue, May 23, 2017 at 4:33 PM Moussa, Ayman <
>>>>>>> ***@imperial.ac.uk> wrote:
>>>>>>>
>>>>>>>> How can I check which compiler scons uses? These are the compilers
>>>>>>>> on my system
>>>>>>>>
>>>>>>>>
>>>>>>>> gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
>>>>>>>> g++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
>>>>>>>> Linux 4.4.0-75-generic #96-Ubuntu SMP
>>>>>>>>
>>>>>>>> ------------------------------
>>>>>>>> *From:* gem5-users <gem5-users-***@gem5.org> on behalf of
>>>>>>>> Jason Lowe-Power <***@lowepower.com>
>>>>>>>> *Sent:* 23 May 2017 22:27:34
>>>>>>>>
>>>>>>>> *To:* gem5 users mailing list
>>>>>>>> *Subject:* Re: [gem5-users] Link error building gem5.fast
>>>>>>>>
>>>>>>>> I just tried again and still cannot reproduce the error. What
>>>>>>>> compiler are you using?
>>>>>>>>
>>>>>>>> Jason
>>>>>>>>
>>>>>>>> On Tue, May 23, 2017 at 3:41 PM Moussa, Ayman <
>>>>>>>> ***@imperial.ac.uk> wrote:
>>>>>>>>
>>>>>>>>> Hey
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I've encountered this exact problem with x86 and it only seems to
>>>>>>>>> be for gem5.fast (gem5.opt works fine). I still have problems with a clean
>>>>>>>>> build as Jason suggested so I reverted back to some random commit on the
>>>>>>>>> gem5 repository and it works but it's not what I was looking for though.
>>>>>>>>> Hope this gets fixed soon.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ------------------------------
>>>>>>>>> *From:* gem5-users <gem5-users-***@gem5.org> on behalf of
>>>>>>>>> Alec Roelke <***@virginia.edu>
>>>>>>>>> *Sent:* 23 May 2017 21:14:10
>>>>>>>>> *To:* gem5 users mailing list
>>>>>>>>> *Subject:* [gem5-users] Link error building gem5.fast
>>>>>>>>>
>>>>>>>>> Hi Everyone,
>>>>>>>>>
>>>>>>>>> When I try to build gem5.fast using any ISA, I get a lot of
>>>>>>>>> multiple definition errors during the final linking stage. For example,
>>>>>>>>> with x86:
>>>>>>>>>
>>>>>>>>> [ LINK] -> X86/gem5.fast.unstripped
>>>>>>>>> build/X86/arch/x86/bios/lib.fo.partial: In function
>>>>>>>>> `Drainable::drainResume()':
>>>>>>>>> (.text+0x5b00): multiple definition of `Drainable::drainResume()'
>>>>>>>>> build/X86/dev/x86/lib.fo.partial:(.text+0x0): first defined here
>>>>>>>>>
>>>>>>>>> There are way too many of these to list them all, but they're all
>>>>>>>>> multiple definitions of symbols. Has anyone else encountered this?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Alec Roelke
>>>>>>>>> _______________________________________________
>>>>>>>>> gem5-users mailing list
>>>>>>>>> gem5-***@gem5.org
>>>>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> gem5-users mailing list
>>>>>>>> gem5-***@gem5.org
>>>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>>>>>
>>>>>>>
>>>>
>>
>

[Andreas Hansson]

I think dropping LTO for the affected compilers is probably the right option, but it is potentially quite a blow to performance if we simply leave it at that. Back when I profiled LTO usage I remember seeing 10+ percent difference with and without LTO.

Andreas

From: gem5-users <gem5-users-***@gem5.org<mailto:gem5-users-***@gem5.org>> on behalf of Jason Lowe-Power <***@lowepower.com<mailto:***@lowepower.com>>
Reply-To: gem5 users mailing list <gem5-***@gem5.org<mailto:gem5-***@gem5.org>>
Date: Monday, 5 June 2017 at 23:16
To: Gabe Black <***@google.com<mailto:***@google.com>>
Cc: gem5 users mailing list <gem5-***@gem5.org<mailto:gem5-***@gem5.org>>
Subject: Re: [gem5-users] Link error building gem5.fast

I'm fine with dropping LTO on gcc 4.9-6. (It also works on gcc 4.8 for me, BTW.) I it's also failing for gcc 6 (see https://travis-ci.org/powerjg/gem5-ci-test).

If you make a patch for this, could you add some detailed comments so we can "undo" this change when we all move to gcc 7+?

Thanks for tracking this down!

Jason

On Mon, Jun 5, 2017 at 4:47 PM Gabe Black <***@google.com<mailto:***@google.com>> wrote:
I also used this thread/bug as a basis for my diagnosis.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67548

On Mon, Jun 5, 2017 at 2:40 PM, Gabe Black <***@google.com<mailto:***@google.com>> wrote:
Ok, I did some digging around about this, and while a lot of the talk between gcc devs sounds like gibberish to me, I did pick out bits and pieces which makes me think this is just something that's broken in gcc of particular versions. There's some documentation of the state of things in gcc version 6 where it says things are fixed to the point where they can be worked with, and that in version 7 they expect them to be totally fixed up:

https://gcc.gnu.org/gcc-6/changes.html

The problem seems to be that there were assumptions being made in the LTO gcc plugin that the link was a final link all the time, and that weak external symbols (the inline functions that might show up multiple times) should be promoted to regular external symbols. That breaks things since, in subsequent links, there are more copies of them and they all look like they're supposed to be unique.

What I think we should do is detect what situation we're in and react accordingly. In gcc version 5.0-6.0 (maybe 4.9 or 4.8, although 4.8 seems to work for me) we need to avoid doing either partial linking or LTO since the combination doesn't work. It would be easier to make scons avoid LTO since that would just be changing the compiler flags and not structurally changing how the build flows or how the scons scripts are written.

In versions 6.0 to 7.0, if those release notes are to be believed, we would need to decide between doing the partial link with gcc or with ld. It sounds like ld is better since it would still do whole program optimization, although again it might be more difficult to twist scon's arm and get it to do things that way since its linker command line uses gcc. We could pass -r to ld directly by wrapping it in -Wl,-r, but that apparently caused issues for people on macs.

And then, in the glorious future where we're using gcc v7 which works properly, or if you're using clang, we can stop worrying about it since -r and -lto will play nicely together.

Thoughts?

Gabe

On Sun, Jun 4, 2017 at 3:11 PM, Jason Lowe-Power <***@lowepower.com<mailto:***@lowepower.com>> wrote:
Hi Gabe,

I think the follow "just works" by downloading the image from dockerhub.

> docker run -v `pwd`:`pwd` -it powerjg/gem5-gcc-6-build /bin/bash

Or, to just download the image:

> docker pull powerjg/gem5-gcc-6-build

Let me know if that doesn't work for you.

I searched around some to try to track down the issue. It seems that GCC doesn't love doing LTO and partial linking. There have been a number of bugs related to this in the past. But, all of the bugs that I found had been fixed before gcc 5.

Cheers,
Jason

On Sun, Jun 4, 2017 at 4:37 PM Gabe Black <***@google.com<mailto:***@google.com>> wrote:
I was hoping we could leave the lto in the .cc->.o but take it out of the partial links, and that that would fix the problem. If you have a docker image I can try this all out on, that would be helpful. If I can get ahold of that somehow, I can try to figure out how to fix this on Monday. I'd speculate what's happening is that little inline functions, etc., which I think are called "common" symbols are showing up more than once. Normally that's ok and the linker will figure that out and get rid of the extra copies, but apparently here it isn't doing that. There's a scons variable which you can use to disable lto in the fast build if you want a workaround for right now, although using gem5.fast is a bit dangerous in the first place since I think it disables asserts, etc.

Gabe

On Sun, Jun 4, 2017 at 2:11 PM, Jason Lowe-Power <***@lowepower.com<mailto:***@lowepower.com>> wrote:
I tried passing -no-lto with ['-r', '-nostdlib'] on line SConstruct:688. However, that caused the error/warning:
"/usr/bin/ld: build/X86/dev/io_device.fo<http://io_device.fo>: plugin needed to handle lto object" for every lib.fo.partial. I guess the -lto option during .cc->.o puts some data in the .o. Then, when partially linking with -r gcc gets confused?

Should I filter out the -lto=8 from all of the .cc->.o? I could have mis-understood how to do this.

Jason

On Sun, Jun 4, 2017 at 4:08 PM Gabe Black <***@google.com<mailto:***@google.com>> wrote:
Did you try filtering out the lto option from the partial link steps like I suggested? Look at how I do that for -shared as an example.

Gabe

On May 24, 2017 2:00 PM, "Jason Lowe-Power" <***@lowepower.com<mailto:***@lowepower.com>> wrote:
Hi everyone,

So I've been able to reproduce the problem. I would bet it's due to the new partial linking code (https://gem5.googlesource.com/public/gem5/+/6bdd897f04f4efdf90d0761c6d31d3f960f4eacf). I'm not sure what the solution is, yet, or if I'll have time to look at it in the next few day. Gabe might have an idea, though, if that is the problem.

Here's a matrix of what compilers are working and which aren't (gcc-4.8 is working, too, though not tested on travis).
https://travis-ci.org/powerjg/gem5-ci-test/builds/235779432

Jason

On Tue, May 23, 2017 at 4:33 PM Moussa, Ayman <***@imperial.ac.uk<mailto:***@imperial.ac.uk>> wrote:

How can I check which compiler scons uses? These are the compilers on my system


gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
g++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
Linux 4.4.0-75-generic #96-Ubuntu SMP


________________________________
From: gem5-users <gem5-users-***@gem5.org<mailto:gem5-users-***@gem5.org>> on behalf of Jason Lowe-Power <***@lowepower.com<mailto:***@lowepower.com>>
Sent: 23 May 2017 22:27:34

To: gem5 users mailing list
Subject: Re: [gem5-users] Link error building gem5.fast

I just tried again and still cannot reproduce the error. What compiler are you using?

Jason

On Tue, May 23, 2017 at 3:41 PM Moussa, Ayman <***@imperial.ac.uk<mailto:***@imperial.ac.uk>> wrote:

Hey


I've encountered this exact problem with x86 and it only seems to be for gem5.fast (gem5.opt works fine). I still have problems with a clean build as Jason suggested so I reverted back to some random commit on the gem5 repository and it works but it's not what I was looking for though. Hope this gets fixed soon.



________________________________
From: gem5-users <gem5-users-***@gem5.org<mailto:gem5-users-***@gem5.org>> on behalf of Alec Roelke <***@virginia.edu<mailto:***@virginia.edu>>
Sent: 23 May 2017 21:14:10
To: gem5 users mailing list
Subject: [gem5-users] Link error building gem5.fast

Hi Everyone,

When I try to build gem5.fast using any ISA, I get a lot of multiple definition errors during the final linking stage. For example, with x86:

[ LINK] -> X86/gem5.fast.unstripped
build/X86/arch/x86/bios/lib.fo<http://lib.fo>.partial: In function `Drainable::drainResume()':
(.text+0x5b00): multiple definition of `Drainable::drainResume()'
build/X86/dev/x86/lib.fo<http://lib.fo>.partial:(.text+0x0): first defined here

There are way too many of these to list them all, but they're all multiple definitions of symbols. Has anyone else encountered this?

Thanks,
Alec Roelke
_______________________________________________
gem5-users mailing list
gem5-***@gem5.org<mailto:gem5-***@gem5.org>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
gem5-***@gem5.org<mailto:gem5-***@gem5.org>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users



IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

[Jason Lowe-Power]

Hey Gabe,

How hard would it be to have an option for partial linking? If we could
have a --force-lto option that did the opposite (enable lto and disable
partial linking), that would be great. But if this would be a giant scons
pain, I understand :).

Jason

On Mon, Jun 5, 2017 at 5:21 PM Andreas Hansson <***@arm.com>
wrote:

> I think dropping LTO for the affected compilers is probably the right
> option, but it is potentially quite a blow to performance if we simply
> leave it at that. Back when I profiled LTO usage I remember seeing 10+
> percent difference with and without LTO.
>
> Andreas
>
> From: gem5-users <gem5-users-***@gem5.org> on behalf of Jason
> Lowe-Power <***@lowepower.com>
> Reply-To: gem5 users mailing list <gem5-***@gem5.org>
> Date: Monday, 5 June 2017 at 23:16
> To: Gabe Black <***@google.com>
> Cc: gem5 users mailing list <gem5-***@gem5.org>
>
> Subject: Re: [gem5-users] Link error building gem5.fast
>
> I'm fine with dropping LTO on gcc 4.9-6. (It also works on gcc 4.8 for me,
> BTW.) I it's also failing for gcc 6 (see
> https://travis-ci.org/powerjg/gem5-ci-test).
>
> If you make a patch for this, could you add some detailed comments so we
> can "undo" this change when we all move to gcc 7+?
>
> Thanks for tracking this down!
>
> Jason
>
> On Mon, Jun 5, 2017 at 4:47 PM Gabe Black <***@google.com> wrote:
>
>> I also used this thread/bug as a basis for my diagnosis.
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67548
>>
>> On Mon, Jun 5, 2017 at 2:40 PM, Gabe Black <***@google.com> wrote:
>>
>>> Ok, I did some digging around about this, and while a lot of the talk
>>> between gcc devs sounds like gibberish to me, I did pick out bits and
>>> pieces which makes me think this is just something that's broken in gcc of
>>> particular versions. There's some documentation of the state of things in
>>> gcc version 6 where it says things are fixed to the point where they can be
>>> worked with, and that in version 7 they expect them to be totally fixed up:
>>>
>>> https://gcc.gnu.org/gcc-6/changes.html
>>>
>>> The problem seems to be that there were assumptions being made in the
>>> LTO gcc plugin that the link was a final link all the time, and that weak
>>> external symbols (the inline functions that might show up multiple times)
>>> should be promoted to regular external symbols. That breaks things since,
>>> in subsequent links, there are more copies of them and they all look like
>>> they're supposed to be unique.
>>>
>>> What I think we should do is detect what situation we're in and react
>>> accordingly. In gcc version 5.0-6.0 (maybe 4.9 or 4.8, although 4.8 seems
>>> to work for me) we need to avoid doing either partial linking or LTO since
>>> the combination doesn't work. It would be easier to make scons avoid LTO
>>> since that would just be changing the compiler flags and not structurally
>>> changing how the build flows or how the scons scripts are written.
>>>
>>> In versions 6.0 to 7.0, if those release notes are to be believed, we
>>> would need to decide between doing the partial link with gcc or with ld. It
>>> sounds like ld is better since it would still do whole program
>>> optimization, although again it might be more difficult to twist scon's arm
>>> and get it to do things that way since its linker command line uses gcc. We
>>> could pass -r to ld directly by wrapping it in -Wl,-r, but that apparently
>>> caused issues for people on macs.
>>>
>>> And then, in the glorious future where we're using gcc v7 which works
>>> properly, or if you're using clang, we can stop worrying about it since -r
>>> and -lto will play nicely together.
>>>
>>> Thoughts?
>>>
>>> Gabe
>>>
>>> On Sun, Jun 4, 2017 at 3:11 PM, Jason Lowe-Power <***@lowepower.com>
>>> wrote:
>>>
>>>> Hi Gabe,
>>>>
>>>> I think the follow "just works" by downloading the image from dockerhub.
>>>>
>>>> > docker run -v `pwd`:`pwd` -it powerjg/gem5-gcc-6-build /bin/bash
>>>>
>>>> Or, to just download the image:
>>>>
>>>> > docker pull powerjg/gem5-gcc-6-build
>>>>
>>>> Let me know if that doesn't work for you.
>>>>
>>>> I searched around some to try to track down the issue. It seems that
>>>> GCC doesn't love doing LTO and partial linking. There have been a number of
>>>> bugs related to this in the past. But, all of the bugs that I found had
>>>> been fixed before gcc 5.
>>>>
>>>> Cheers,
>>>> Jason
>>>>
>>>> On Sun, Jun 4, 2017 at 4:37 PM Gabe Black <***@google.com> wrote:
>>>>
>>>>> I was hoping we could leave the lto in the .cc->.o but take it out of
>>>>> the partial links, and that that would fix the problem. If you have a
>>>>> docker image I can try this all out on, that would be helpful. If I can get
>>>>> ahold of that somehow, I can try to figure out how to fix this on Monday.
>>>>> I'd speculate what's happening is that little inline functions, etc., which
>>>>> I think are called "common" symbols are showing up more than once. Normally
>>>>> that's ok and the linker will figure that out and get rid of the extra
>>>>> copies, but apparently here it isn't doing that. There's a scons variable
>>>>> which you can use to disable lto in the fast build if you want a workaround
>>>>> for right now, although using gem5.fast is a bit dangerous in the first
>>>>> place since I think it disables asserts, etc.
>>>>>
>>>>> Gabe
>>>>>
>>>>> On Sun, Jun 4, 2017 at 2:11 PM, Jason Lowe-Power <***@lowepower.com>
>>>>> wrote:
>>>>>
>>>>>> I tried passing -no-lto with ['-r', '-nostdlib'] on line
>>>>>> SConstruct:688. However, that caused the error/warning:
>>>>>> "/usr/bin/ld: build/X86/dev/io_device.fo: plugin needed to handle
>>>>>> lto object" for every lib.fo.partial. I guess the -lto option during
>>>>>> .cc->.o puts some data in the .o. Then, when partially linking with -r gcc
>>>>>> gets confused?
>>>>>>
>>>>>> Should I filter out the -lto=8 from all of the .cc->.o? I could have
>>>>>> mis-understood how to do this.
>>>>>>
>>>>>> Jason
>>>>>>
>>>>>> On Sun, Jun 4, 2017 at 4:08 PM Gabe Black <***@google.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Did you try filtering out the lto option from the partial link steps
>>>>>>> like I suggested? Look at how I do that for -shared as an example.
>>>>>>>
>>>>>>> Gabe
>>>>>>>
>>>>>>> On May 24, 2017 2:00 PM, "Jason Lowe-Power" <***@lowepower.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi everyone,
>>>>>>>>
>>>>>>>> So I've been able to reproduce the problem. I would bet it's due to
>>>>>>>> the new partial linking code (
>>>>>>>> https://gem5.googlesource.com/public/gem5/+/6bdd897f04f4efdf90d0761c6d31d3f960f4eacf).
>>>>>>>> I'm not sure what the solution is, yet, or if I'll have time to look at it
>>>>>>>> in the next few day. Gabe might have an idea, though, if that is the
>>>>>>>> problem.
>>>>>>>>
>>>>>>>> Here's a matrix of what compilers are working and which aren't
>>>>>>>> (gcc-4.8 is working, too, though not tested on travis).
>>>>>>>> https://travis-ci.org/powerjg/gem5-ci-test/builds/235779432
>>>>>>>>
>>>>>>>> Jason
>>>>>>>>
>>>>>>>> On Tue, May 23, 2017 at 4:33 PM Moussa, Ayman <
>>>>>>>> ***@imperial.ac.uk> wrote:
>>>>>>>>
>>>>>>>>> How can I check which compiler scons uses? These are the compilers
>>>>>>>>> on my system
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
>>>>>>>>> g++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
>>>>>>>>> Linux 4.4.0-75-generic #96-Ubuntu SMP
>>>>>>>>>
>>>>>>>>> ------------------------------
>>>>>>>>> *From:* gem5-users <gem5-users-***@gem5.org> on behalf of
>>>>>>>>> Jason Lowe-Power <***@lowepower.com>
>>>>>>>>> *Sent:* 23 May 2017 22:27:34
>>>>>>>>>
>>>>>>>>> *To:* gem5 users mailing list
>>>>>>>>> *Subject:* Re: [gem5-users] Link error building gem5.fast
>>>>>>>>>
>>>>>>>>> I just tried again and still cannot reproduce the error. What
>>>>>>>>> compiler are you using?
>>>>>>>>>
>>>>>>>>> Jason
>>>>>>>>>
>>>>>>>>> On Tue, May 23, 2017 at 3:41 PM Moussa, Ayman <
>>>>>>>>> ***@imperial.ac.uk> wrote:
>>>>>>>>>
>>>>>>>>>> Hey
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I've encountered this exact problem with x86 and it only seems to
>>>>>>>>>> be for gem5.fast (gem5.opt works fine). I still have problems with a clean
>>>>>>>>>> build as Jason suggested so I reverted back to some random commit on the
>>>>>>>>>> gem5 repository and it works but it's not what I was looking for though.
>>>>>>>>>> Hope this gets fixed soon.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ------------------------------
>>>>>>>>>> *From:* gem5-users <gem5-users-***@gem5.org> on behalf of
>>>>>>>>>> Alec Roelke <***@virginia.edu>
>>>>>>>>>> *Sent:* 23 May 2017 21:14:10
>>>>>>>>>> *To:* gem5 users mailing list
>>>>>>>>>> *Subject:* [gem5-users] Link error building gem5.fast
>>>>>>>>>>
>>>>>>>>>> Hi Everyone,
>>>>>>>>>>
>>>>>>>>>> When I try to build gem5.fast using any ISA, I get a lot of
>>>>>>>>>> multiple definition errors during the final linking stage. For example,
>>>>>>>>>> with x86:
>>>>>>>>>>
>>>>>>>>>> [ LINK] -> X86/gem5.fast.unstripped
>>>>>>>>>> build/X86/arch/x86/bios/lib.fo.partial: In function
>>>>>>>>>> `Drainable::drainResume()':
>>>>>>>>>> (.text+0x5b00): multiple definition of `Drainable::drainResume()'
>>>>>>>>>> build/X86/dev/x86/lib.fo.partial:(.text+0x0): first defined here
>>>>>>>>>>
>>>>>>>>>> There are way too many of these to list them all, but they're all
>>>>>>>>>> multiple definitions of symbols. Has anyone else encountered this?
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Alec Roelke
>>>>>>>>>> _______________________________________________
>>>>>>>>>> gem5-users mailing list
>>>>>>>>>> gem5-***@gem5.org
>>>>>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> gem5-users mailing list
>>>>>>>>> gem5-***@gem5.org
>>>>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>>>>>>
>>>>>>>>
>>>>>
>>>
>> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
> _______________________________________________
> gem5-users mailing list
> gem5-***@gem5.org
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

[Gabe Black]

I think those are all doable options. I'll give this a whirl, but while
I'll try to have a quick turnaround I can't make guarantees since I'll be
going on vacation next week and need to get a few things done. I don't
think it'll be too bad to implement though, so it shouldn't be a problem.

Gabe

On Mon, Jun 5, 2017 at 3:23 PM, Jason Lowe-Power <***@lowepower.com>
wrote:

> Hey Gabe,
>
> How hard would it be to have an option for partial linking? If we could
> have a --force-lto option that did the opposite (enable lto and disable
> partial linking), that would be great. But if this would be a giant scons
> pain, I understand :).
>
> Jason
>
> On Mon, Jun 5, 2017 at 5:21 PM Andreas Hansson <***@arm.com>
> wrote:
>
>> I think dropping LTO for the affected compilers is probably the right
>> option, but it is potentially quite a blow to performance if we simply
>> leave it at that. Back when I profiled LTO usage I remember seeing 10+
>> percent difference with and without LTO.
>>
>> Andreas
>>
>> From: gem5-users <gem5-users-***@gem5.org> on behalf of Jason
>> Lowe-Power <***@lowepower.com>
>> Reply-To: gem5 users mailing list <gem5-***@gem5.org>
>> Date: Monday, 5 June 2017 at 23:16
>> To: Gabe Black <***@google.com>
>> Cc: gem5 users mailing list <gem5-***@gem5.org>
>>
>> Subject: Re: [gem5-users] Link error building gem5.fast
>>
>> I'm fine with dropping LTO on gcc 4.9-6. (It also works on gcc 4.8 for
>> me, BTW.) I it's also failing for gcc 6 (see
>> https://travis-ci.org/powerjg/gem5-ci-test).
>>
>> If you make a patch for this, could you add some detailed comments so we
>> can "undo" this change when we all move to gcc 7+?
>>
>> Thanks for tracking this down!
>>
>> Jason
>>
>> On Mon, Jun 5, 2017 at 4:47 PM Gabe Black <***@google.com> wrote:
>>
>>> I also used this thread/bug as a basis for my diagnosis.
>>>
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67548
>>>
>>> On Mon, Jun 5, 2017 at 2:40 PM, Gabe Black <***@google.com> wrote:
>>>
>>>> Ok, I did some digging around about this, and while a lot of the talk
>>>> between gcc devs sounds like gibberish to me, I did pick out bits and
>>>> pieces which makes me think this is just something that's broken in gcc of
>>>> particular versions. There's some documentation of the state of things in
>>>> gcc version 6 where it says things are fixed to the point where they can be
>>>> worked with, and that in version 7 they expect them to be totally fixed up:
>>>>
>>>> https://gcc.gnu.org/gcc-6/changes.html
>>>>
>>>> The problem seems to be that there were assumptions being made in the
>>>> LTO gcc plugin that the link was a final link all the time, and that weak
>>>> external symbols (the inline functions that might show up multiple times)
>>>> should be promoted to regular external symbols. That breaks things since,
>>>> in subsequent links, there are more copies of them and they all look like
>>>> they're supposed to be unique.
>>>>
>>>> What I think we should do is detect what situation we're in and react
>>>> accordingly. In gcc version 5.0-6.0 (maybe 4.9 or 4.8, although 4.8 seems
>>>> to work for me) we need to avoid doing either partial linking or LTO since
>>>> the combination doesn't work. It would be easier to make scons avoid LTO
>>>> since that would just be changing the compiler flags and not structurally
>>>> changing how the build flows or how the scons scripts are written.
>>>>
>>>> In versions 6.0 to 7.0, if those release notes are to be believed, we
>>>> would need to decide between doing the partial link with gcc or with ld. It
>>>> sounds like ld is better since it would still do whole program
>>>> optimization, although again it might be more difficult to twist scon's arm
>>>> and get it to do things that way since its linker command line uses gcc. We
>>>> could pass -r to ld directly by wrapping it in -Wl,-r, but that apparently
>>>> caused issues for people on macs.
>>>>
>>>> And then, in the glorious future where we're using gcc v7 which works
>>>> properly, or if you're using clang, we can stop worrying about it since -r
>>>> and -lto will play nicely together.
>>>>
>>>> Thoughts?
>>>>
>>>> Gabe
>>>>
>>>> On Sun, Jun 4, 2017 at 3:11 PM, Jason Lowe-Power <***@lowepower.com>
>>>> wrote:
>>>>
>>>>> Hi Gabe,
>>>>>
>>>>> I think the follow "just works" by downloading the image from
>>>>> dockerhub.
>>>>>
>>>>> > docker run -v `pwd`:`pwd` -it powerjg/gem5-gcc-6-build /bin/bash
>>>>>
>>>>> Or, to just download the image:
>>>>>
>>>>> > docker pull powerjg/gem5-gcc-6-build
>>>>>
>>>>> Let me know if that doesn't work for you.
>>>>>
>>>>> I searched around some to try to track down the issue. It seems that
>>>>> GCC doesn't love doing LTO and partial linking. There have been a number of
>>>>> bugs related to this in the past. But, all of the bugs that I found had
>>>>> been fixed before gcc 5.
>>>>>
>>>>> Cheers,
>>>>> Jason
>>>>>
>>>>> On Sun, Jun 4, 2017 at 4:37 PM Gabe Black <***@google.com>
>>>>> wrote:
>>>>>
>>>>>> I was hoping we could leave the lto in the .cc->.o but take it out of
>>>>>> the partial links, and that that would fix the problem. If you have a
>>>>>> docker image I can try this all out on, that would be helpful. If I can get
>>>>>> ahold of that somehow, I can try to figure out how to fix this on Monday.
>>>>>> I'd speculate what's happening is that little inline functions, etc., which
>>>>>> I think are called "common" symbols are showing up more than once. Normally
>>>>>> that's ok and the linker will figure that out and get rid of the extra
>>>>>> copies, but apparently here it isn't doing that. There's a scons variable
>>>>>> which you can use to disable lto in the fast build if you want a workaround
>>>>>> for right now, although using gem5.fast is a bit dangerous in the first
>>>>>> place since I think it disables asserts, etc.
>>>>>>
>>>>>> Gabe
>>>>>>
>>>>>> On Sun, Jun 4, 2017 at 2:11 PM, Jason Lowe-Power <***@lowepower.com
>>>>>> > wrote:
>>>>>>
>>>>>>> I tried passing -no-lto with ['-r', '-nostdlib'] on line
>>>>>>> SConstruct:688. However, that caused the error/warning:
>>>>>>> "/usr/bin/ld: build/X86/dev/io_device.fo: plugin needed to handle
>>>>>>> lto object" for every lib.fo.partial. I guess the -lto option during
>>>>>>> .cc->.o puts some data in the .o. Then, when partially linking with -r gcc
>>>>>>> gets confused?
>>>>>>>
>>>>>>> Should I filter out the -lto=8 from all of the .cc->.o? I could have
>>>>>>> mis-understood how to do this.
>>>>>>>
>>>>>>> Jason
>>>>>>>
>>>>>>> On Sun, Jun 4, 2017 at 4:08 PM Gabe Black <***@google.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Did you try filtering out the lto option from the partial link
>>>>>>>> steps like I suggested? Look at how I do that for -shared as an example.
>>>>>>>>
>>>>>>>> Gabe
>>>>>>>>
>>>>>>>> On May 24, 2017 2:00 PM, "Jason Lowe-Power" <***@lowepower.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi everyone,
>>>>>>>>>
>>>>>>>>> So I've been able to reproduce the problem. I would bet it's due
>>>>>>>>> to the new partial linking code (https://gem5.googlesource.
>>>>>>>>> com/public/gem5/+/6bdd897f04f4efdf90d0761c6d31d3f960f4eacf). I'm
>>>>>>>>> not sure what the solution is, yet, or if I'll have time to look at it in
>>>>>>>>> the next few day. Gabe might have an idea, though, if that is the problem.
>>>>>>>>>
>>>>>>>>> Here's a matrix of what compilers are working and which aren't
>>>>>>>>> (gcc-4.8 is working, too, though not tested on travis).
>>>>>>>>> https://travis-ci.org/powerjg/gem5-ci-test/builds/235779432
>>>>>>>>>
>>>>>>>>> Jason
>>>>>>>>>
>>>>>>>>> On Tue, May 23, 2017 at 4:33 PM Moussa, Ayman <
>>>>>>>>> ***@imperial.ac.uk> wrote:
>>>>>>>>>
>>>>>>>>>> How can I check which compiler scons uses? These are the
>>>>>>>>>> compilers on my system
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
>>>>>>>>>> g++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
>>>>>>>>>> Linux 4.4.0-75-generic #96-Ubuntu SMP
>>>>>>>>>>
>>>>>>>>>> ------------------------------
>>>>>>>>>> *From:* gem5-users <gem5-users-***@gem5.org> on behalf of
>>>>>>>>>> Jason Lowe-Power <***@lowepower.com>
>>>>>>>>>> *Sent:* 23 May 2017 22:27:34
>>>>>>>>>>
>>>>>>>>>> *To:* gem5 users mailing list
>>>>>>>>>> *Subject:* Re: [gem5-users] Link error building gem5.fast
>>>>>>>>>>
>>>>>>>>>> I just tried again and still cannot reproduce the error. What
>>>>>>>>>> compiler are you using?
>>>>>>>>>>
>>>>>>>>>> Jason
>>>>>>>>>>
>>>>>>>>>> On Tue, May 23, 2017 at 3:41 PM Moussa, Ayman <
>>>>>>>>>> ***@imperial.ac.uk> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hey
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I've encountered this exact problem with x86 and it only seems
>>>>>>>>>>> to be for gem5.fast (gem5.opt works fine). I still have problems with a
>>>>>>>>>>> clean build as Jason suggested so I reverted back to some random commit on
>>>>>>>>>>> the gem5 repository and it works but it's not what I was looking for
>>>>>>>>>>> though. Hope this gets fixed soon.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ------------------------------
>>>>>>>>>>> *From:* gem5-users <gem5-users-***@gem5.org> on behalf of
>>>>>>>>>>> Alec Roelke <***@virginia.edu>
>>>>>>>>>>> *Sent:* 23 May 2017 21:14:10
>>>>>>>>>>> *To:* gem5 users mailing list
>>>>>>>>>>> *Subject:* [gem5-users] Link error building gem5.fast
>>>>>>>>>>>
>>>>>>>>>>> Hi Everyone,
>>>>>>>>>>>
>>>>>>>>>>> When I try to build gem5.fast using any ISA, I get a lot of
>>>>>>>>>>> multiple definition errors during the final linking stage. For example,
>>>>>>>>>>> with x86:
>>>>>>>>>>>
>>>>>>>>>>> [ LINK] -> X86/gem5.fast.unstripped
>>>>>>>>>>> build/X86/arch/x86/bios/lib.fo.partial: In function
>>>>>>>>>>> `Drainable::drainResume()':
>>>>>>>>>>> (.text+0x5b00): multiple definition of `Drainable::drainResume()'
>>>>>>>>>>> build/X86/dev/x86/lib.fo.partial:(.text+0x0): first defined here
>>>>>>>>>>>
>>>>>>>>>>> There are way too many of these to list them all, but they're
>>>>>>>>>>> all multiple definitions of symbols. Has anyone else encountered this?
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Alec Roelke
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> gem5-users mailing list
>>>>>>>>>>> gem5-***@gem5.org
>>>>>>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> gem5-users mailing list
>>>>>>>>>> gem5-***@gem5.org
>>>>>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>
>>> IMPORTANT NOTICE: The contents of this email and any attachments are
>> confidential and may also be privileged. If you are not the intended
>> recipient, please notify the sender immediately and do not disclose the
>> contents to any other person, use it for any purpose, or store or copy the
>> information in any medium. Thank you.
>> _______________________________________________
>> gem5-users mailing list
>> gem5-***@gem5.org
>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
>
> _______________________________________________
> gem5-users mailing list
> gem5-***@gem5.org
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>

[Gabe Black]

I think for version 6.0-ish (potentially going away in the future?) you're
supposed to add -flinker-output=rel as an option for the partial links.
Unfortunately when I do that, I get a different internal error described
here:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69866

Which was apparently fixed as recently as march of this year.

Gabe

On Mon, Jun 5, 2017 at 4:04 PM, Gabe Black <***@google.com> wrote:

> I think those are all doable options. I'll give this a whirl, but while
> I'll try to have a quick turnaround I can't make guarantees since I'll be
> going on vacation next week and need to get a few things done. I don't
> think it'll be too bad to implement though, so it shouldn't be a problem.
>
> Gabe
>
> On Mon, Jun 5, 2017 at 3:23 PM, Jason Lowe-Power <***@lowepower.com>
> wrote:
>
>> Hey Gabe,
>>
>> How hard would it be to have an option for partial linking? If we could
>> have a --force-lto option that did the opposite (enable lto and disable
>> partial linking), that would be great. But if this would be a giant scons
>> pain, I understand :).
>>
>> Jason
>>
>> On Mon, Jun 5, 2017 at 5:21 PM Andreas Hansson <***@arm.com>
>> wrote:
>>
>>> I think dropping LTO for the affected compilers is probably the right
>>> option, but it is potentially quite a blow to performance if we simply
>>> leave it at that. Back when I profiled LTO usage I remember seeing 10+
>>> percent difference with and without LTO.
>>>
>>> Andreas
>>>
>>> From: gem5-users <gem5-users-***@gem5.org> on behalf of Jason
>>> Lowe-Power <***@lowepower.com>
>>> Reply-To: gem5 users mailing list <gem5-***@gem5.org>
>>> Date: Monday, 5 June 2017 at 23:16
>>> To: Gabe Black <***@google.com>
>>> Cc: gem5 users mailing list <gem5-***@gem5.org>
>>>
>>> Subject: Re: [gem5-users] Link error building gem5.fast
>>>
>>> I'm fine with dropping LTO on gcc 4.9-6. (It also works on gcc 4.8 for
>>> me, BTW.) I it's also failing for gcc 6 (see
>>> https://travis-ci.org/powerjg/gem5-ci-test).
>>>
>>> If you make a patch for this, could you add some detailed comments so we
>>> can "undo" this change when we all move to gcc 7+?
>>>
>>> Thanks for tracking this down!
>>>
>>> Jason
>>>
>>> On Mon, Jun 5, 2017 at 4:47 PM Gabe Black <***@google.com> wrote:
>>>
>>>> I also used this thread/bug as a basis for my diagnosis.
>>>>
>>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67548
>>>>
>>>> On Mon, Jun 5, 2017 at 2:40 PM, Gabe Black <***@google.com>
>>>> wrote:
>>>>
>>>>> Ok, I did some digging around about this, and while a lot of the talk
>>>>> between gcc devs sounds like gibberish to me, I did pick out bits and
>>>>> pieces which makes me think this is just something that's broken in gcc of
>>>>> particular versions. There's some documentation of the state of things in
>>>>> gcc version 6 where it says things are fixed to the point where they can be
>>>>> worked with, and that in version 7 they expect them to be totally fixed up:
>>>>>
>>>>> https://gcc.gnu.org/gcc-6/changes.html
>>>>>
>>>>> The problem seems to be that there were assumptions being made in the
>>>>> LTO gcc plugin that the link was a final link all the time, and that weak
>>>>> external symbols (the inline functions that might show up multiple times)
>>>>> should be promoted to regular external symbols. That breaks things since,
>>>>> in subsequent links, there are more copies of them and they all look like
>>>>> they're supposed to be unique.
>>>>>
>>>>> What I think we should do is detect what situation we're in and react
>>>>> accordingly. In gcc version 5.0-6.0 (maybe 4.9 or 4.8, although 4.8 seems
>>>>> to work for me) we need to avoid doing either partial linking or LTO since
>>>>> the combination doesn't work. It would be easier to make scons avoid LTO
>>>>> since that would just be changing the compiler flags and not structurally
>>>>> changing how the build flows or how the scons scripts are written.
>>>>>
>>>>> In versions 6.0 to 7.0, if those release notes are to be believed, we
>>>>> would need to decide between doing the partial link with gcc or with ld. It
>>>>> sounds like ld is better since it would still do whole program
>>>>> optimization, although again it might be more difficult to twist scon's arm
>>>>> and get it to do things that way since its linker command line uses gcc. We
>>>>> could pass -r to ld directly by wrapping it in -Wl,-r, but that apparently
>>>>> caused issues for people on macs.
>>>>>
>>>>> And then, in the glorious future where we're using gcc v7 which works
>>>>> properly, or if you're using clang, we can stop worrying about it since -r
>>>>> and -lto will play nicely together.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> Gabe
>>>>>
>>>>> On Sun, Jun 4, 2017 at 3:11 PM, Jason Lowe-Power <***@lowepower.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Gabe,
>>>>>>
>>>>>> I think the follow "just works" by downloading the image from
>>>>>> dockerhub.
>>>>>>
>>>>>> > docker run -v `pwd`:`pwd` -it powerjg/gem5-gcc-6-build /bin/bash
>>>>>>
>>>>>> Or, to just download the image:
>>>>>>
>>>>>> > docker pull powerjg/gem5-gcc-6-build
>>>>>>
>>>>>> Let me know if that doesn't work for you.
>>>>>>
>>>>>> I searched around some to try to track down the issue. It seems that
>>>>>> GCC doesn't love doing LTO and partial linking. There have been a number of
>>>>>> bugs related to this in the past. But, all of the bugs that I found had
>>>>>> been fixed before gcc 5.
>>>>>>
>>>>>> Cheers,
>>>>>> Jason
>>>>>>
>>>>>> On Sun, Jun 4, 2017 at 4:37 PM Gabe Black <***@google.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I was hoping we could leave the lto in the .cc->.o but take it out
>>>>>>> of the partial links, and that that would fix the problem. If you have a
>>>>>>> docker image I can try this all out on, that would be helpful. If I can get
>>>>>>> ahold of that somehow, I can try to figure out how to fix this on Monday.
>>>>>>> I'd speculate what's happening is that little inline functions, etc., which
>>>>>>> I think are called "common" symbols are showing up more than once. Normally
>>>>>>> that's ok and the linker will figure that out and get rid of the extra
>>>>>>> copies, but apparently here it isn't doing that. There's a scons variable
>>>>>>> which you can use to disable lto in the fast build if you want a workaround
>>>>>>> for right now, although using gem5.fast is a bit dangerous in the first
>>>>>>> place since I think it disables asserts, etc.
>>>>>>>
>>>>>>> Gabe
>>>>>>>
>>>>>>> On Sun, Jun 4, 2017 at 2:11 PM, Jason Lowe-Power <
>>>>>>> ***@lowepower.com> wrote:
>>>>>>>
>>>>>>>> I tried passing -no-lto with ['-r', '-nostdlib'] on line
>>>>>>>> SConstruct:688. However, that caused the error/warning:
>>>>>>>> "/usr/bin/ld: build/X86/dev/io_device.fo: plugin needed to handle
>>>>>>>> lto object" for every lib.fo.partial. I guess the -lto option during
>>>>>>>> .cc->.o puts some data in the .o. Then, when partially linking with -r gcc
>>>>>>>> gets confused?
>>>>>>>>
>>>>>>>> Should I filter out the -lto=8 from all of the .cc->.o? I could
>>>>>>>> have mis-understood how to do this.
>>>>>>>>
>>>>>>>> Jason
>>>>>>>>
>>>>>>>> On Sun, Jun 4, 2017 at 4:08 PM Gabe Black <***@google.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Did you try filtering out the lto option from the partial link
>>>>>>>>> steps like I suggested? Look at how I do that for -shared as an example.
>>>>>>>>>
>>>>>>>>> Gabe
>>>>>>>>>
>>>>>>>>> On May 24, 2017 2:00 PM, "Jason Lowe-Power" <***@lowepower.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hi everyone,
>>>>>>>>>>
>>>>>>>>>> So I've been able to reproduce the problem. I would bet it's due
>>>>>>>>>> to the new partial linking code (https://gem5.googlesource.com
>>>>>>>>>> /public/gem5/+/6bdd897f04f4efdf90d0761c6d31d3f960f4eacf). I'm
>>>>>>>>>> not sure what the solution is, yet, or if I'll have time to look at it in
>>>>>>>>>> the next few day. Gabe might have an idea, though, if that is the problem.
>>>>>>>>>>
>>>>>>>>>> Here's a matrix of what compilers are working and which aren't
>>>>>>>>>> (gcc-4.8 is working, too, though not tested on travis).
>>>>>>>>>> https://travis-ci.org/powerjg/gem5-ci-test/builds/235779432
>>>>>>>>>>
>>>>>>>>>> Jason
>>>>>>>>>>
>>>>>>>>>> On Tue, May 23, 2017 at 4:33 PM Moussa, Ayman <
>>>>>>>>>> ***@imperial.ac.uk> wrote:
>>>>>>>>>>
>>>>>>>>>>> How can I check which compiler scons uses? These are the
>>>>>>>>>>> compilers on my system
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
>>>>>>>>>>> g++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
>>>>>>>>>>> Linux 4.4.0-75-generic #96-Ubuntu SMP
>>>>>>>>>>>
>>>>>>>>>>> ------------------------------
>>>>>>>>>>> *From:* gem5-users <gem5-users-***@gem5.org> on behalf of
>>>>>>>>>>> Jason Lowe-Power <***@lowepower.com>
>>>>>>>>>>> *Sent:* 23 May 2017 22:27:34
>>>>>>>>>>>
>>>>>>>>>>> *To:* gem5 users mailing list
>>>>>>>>>>> *Subject:* Re: [gem5-users] Link error building gem5.fast
>>>>>>>>>>>
>>>>>>>>>>> I just tried again and still cannot reproduce the error. What
>>>>>>>>>>> compiler are you using?
>>>>>>>>>>>
>>>>>>>>>>> Jason
>>>>>>>>>>>
>>>>>>>>>>> On Tue, May 23, 2017 at 3:41 PM Moussa, Ayman <
>>>>>>>>>>> ***@imperial.ac.uk> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hey
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I've encountered this exact problem with x86 and it only seems
>>>>>>>>>>>> to be for gem5.fast (gem5.opt works fine). I still have problems with a
>>>>>>>>>>>> clean build as Jason suggested so I reverted back to some random commit on
>>>>>>>>>>>> the gem5 repository and it works but it's not what I was looking for
>>>>>>>>>>>> though. Hope this gets fixed soon.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ------------------------------
>>>>>>>>>>>> *From:* gem5-users <gem5-users-***@gem5.org> on behalf of
>>>>>>>>>>>> Alec Roelke <***@virginia.edu>
>>>>>>>>>>>> *Sent:* 23 May 2017 21:14:10
>>>>>>>>>>>> *To:* gem5 users mailing list
>>>>>>>>>>>> *Subject:* [gem5-users] Link error building gem5.fast
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Everyone,
>>>>>>>>>>>>
>>>>>>>>>>>> When I try to build gem5.fast using any ISA, I get a lot of
>>>>>>>>>>>> multiple definition errors during the final linking stage. For example,
>>>>>>>>>>>> with x86:
>>>>>>>>>>>>
>>>>>>>>>>>> [ LINK] -> X86/gem5.fast.unstripped
>>>>>>>>>>>> build/X86/arch/x86/bios/lib.fo.partial: In function
>>>>>>>>>>>> `Drainable::drainResume()':
>>>>>>>>>>>> (.text+0x5b00): multiple definition of
>>>>>>>>>>>> `Drainable::drainResume()'
>>>>>>>>>>>> build/X86/dev/x86/lib.fo.partial:(.text+0x0): first defined
>>>>>>>>>>>> here
>>>>>>>>>>>>
>>>>>>>>>>>> There are way too many of these to list them all, but they're
>>>>>>>>>>>> all multiple definitions of symbols. Has anyone else encountered this?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Alec Roelke
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> gem5-users mailing list
>>>>>>>>>>>> gem5-***@gem5.org
>>>>>>>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> gem5-users mailing list
>>>>>>>>>>> gem5-***@gem5.org
>>>>>>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>
>>>>>
>>>> IMPORTANT NOTICE: The contents of this email and any attachments are
>>> confidential and may also be privileged. If you are not the intended
>>> recipient, please notify the sender immediately and do not disclose the
>>> contents to any other person, use it for any purpose, or store or copy the
>>> information in any medium. Thank you.
>>> _______________________________________________
>>> gem5-users mailing list
>>> gem5-***@gem5.org
>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>
>>
>> _______________________________________________
>> gem5-users mailing list
>> gem5-***@gem5.org
>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>
>
>

[Gabe Black]

Could you give this a try on your magical many configurations server thing,
Jason?

https://gem5-review.googlesource.com/#/c/3680/

I think it should cover the various failure modes we've discovered, but it
would be good to know for sure.

Gabe

On Mon, Jun 5, 2017 at 8:52 PM, Gabe Black <***@google.com> wrote:

> I think for version 6.0-ish (potentially going away in the future?) you're
> supposed to add -flinker-output=rel as an option for the partial links.
> Unfortunately when I do that, I get a different internal error described
> here:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69866
>
> Which was apparently fixed as recently as march of this year.
>
> Gabe
>
> On Mon, Jun 5, 2017 at 4:04 PM, Gabe Black <***@google.com> wrote:
>
>> I think those are all doable options. I'll give this a whirl, but while
>> I'll try to have a quick turnaround I can't make guarantees since I'll be
>> going on vacation next week and need to get a few things done. I don't
>> think it'll be too bad to implement though, so it shouldn't be a problem.
>>
>> Gabe
>>
>> On Mon, Jun 5, 2017 at 3:23 PM, Jason Lowe-Power <***@lowepower.com>
>> wrote:
>>
>>> Hey Gabe,
>>>
>>> How hard would it be to have an option for partial linking? If we could
>>> have a --force-lto option that did the opposite (enable lto and disable
>>> partial linking), that would be great. But if this would be a giant scons
>>> pain, I understand :).
>>>
>>> Jason
>>>
>>> On Mon, Jun 5, 2017 at 5:21 PM Andreas Hansson <***@arm.com>
>>> wrote:
>>>
>>>> I think dropping LTO for the affected compilers is probably the right
>>>> option, but it is potentially quite a blow to performance if we simply
>>>> leave it at that. Back when I profiled LTO usage I remember seeing 10+
>>>> percent difference with and without LTO.
>>>>
>>>> Andreas
>>>>
>>>> From: gem5-users <gem5-users-***@gem5.org> on behalf of Jason
>>>> Lowe-Power <***@lowepower.com>
>>>> Reply-To: gem5 users mailing list <gem5-***@gem5.org>
>>>> Date: Monday, 5 June 2017 at 23:16
>>>> To: Gabe Black <***@google.com>
>>>> Cc: gem5 users mailing list <gem5-***@gem5.org>
>>>>
>>>> Subject: Re: [gem5-users] Link error building gem5.fast
>>>>
>>>> I'm fine with dropping LTO on gcc 4.9-6. (It also works on gcc 4.8 for
>>>> me, BTW.) I it's also failing for gcc 6 (see
>>>> https://travis-ci.org/powerjg/gem5-ci-test).
>>>>
>>>> If you make a patch for this, could you add some detailed comments so
>>>> we can "undo" this change when we all move to gcc 7+?
>>>>
>>>> Thanks for tracking this down!
>>>>
>>>> Jason
>>>>
>>>> On Mon, Jun 5, 2017 at 4:47 PM Gabe Black <***@google.com> wrote:
>>>>
>>>>> I also used this thread/bug as a basis for my diagnosis.
>>>>>
>>>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67548
>>>>>
>>>>> On Mon, Jun 5, 2017 at 2:40 PM, Gabe Black <***@google.com>
>>>>> wrote:
>>>>>
>>>>>> Ok, I did some digging around about this, and while a lot of the talk
>>>>>> between gcc devs sounds like gibberish to me, I did pick out bits and
>>>>>> pieces which makes me think this is just something that's broken in gcc of
>>>>>> particular versions. There's some documentation of the state of things in
>>>>>> gcc version 6 where it says things are fixed to the point where they can be
>>>>>> worked with, and that in version 7 they expect them to be totally fixed up:
>>>>>>
>>>>>> https://gcc.gnu.org/gcc-6/changes.html
>>>>>>
>>>>>> The problem seems to be that there were assumptions being made in the
>>>>>> LTO gcc plugin that the link was a final link all the time, and that weak
>>>>>> external symbols (the inline functions that might show up multiple times)
>>>>>> should be promoted to regular external symbols. That breaks things since,
>>>>>> in subsequent links, there are more copies of them and they all look like
>>>>>> they're supposed to be unique.
>>>>>>
>>>>>> What I think we should do is detect what situation we're in and react
>>>>>> accordingly. In gcc version 5.0-6.0 (maybe 4.9 or 4.8, although 4.8 seems
>>>>>> to work for me) we need to avoid doing either partial linking or LTO since
>>>>>> the combination doesn't work. It would be easier to make scons avoid LTO
>>>>>> since that would just be changing the compiler flags and not structurally
>>>>>> changing how the build flows or how the scons scripts are written.
>>>>>>
>>>>>> In versions 6.0 to 7.0, if those release notes are to be believed, we
>>>>>> would need to decide between doing the partial link with gcc or with ld. It
>>>>>> sounds like ld is better since it would still do whole program
>>>>>> optimization, although again it might be more difficult to twist scon's arm
>>>>>> and get it to do things that way since its linker command line uses gcc. We
>>>>>> could pass -r to ld directly by wrapping it in -Wl,-r, but that apparently
>>>>>> caused issues for people on macs.
>>>>>>
>>>>>> And then, in the glorious future where we're using gcc v7 which works
>>>>>> properly, or if you're using clang, we can stop worrying about it since -r
>>>>>> and -lto will play nicely together.
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>> Gabe
>>>>>>
>>>>>> On Sun, Jun 4, 2017 at 3:11 PM, Jason Lowe-Power <***@lowepower.com
>>>>>> > wrote:
>>>>>>
>>>>>>> Hi Gabe,
>>>>>>>
>>>>>>> I think the follow "just works" by downloading the image from
>>>>>>> dockerhub.
>>>>>>>
>>>>>>> > docker run -v `pwd`:`pwd` -it powerjg/gem5-gcc-6-build /bin/bash
>>>>>>>
>>>>>>> Or, to just download the image:
>>>>>>>
>>>>>>> > docker pull powerjg/gem5-gcc-6-build
>>>>>>>
>>>>>>> Let me know if that doesn't work for you.
>>>>>>>
>>>>>>> I searched around some to try to track down the issue. It seems that
>>>>>>> GCC doesn't love doing LTO and partial linking. There have been a number of
>>>>>>> bugs related to this in the past. But, all of the bugs that I found had
>>>>>>> been fixed before gcc 5.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Jason
>>>>>>>
>>>>>>> On Sun, Jun 4, 2017 at 4:37 PM Gabe Black <***@google.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I was hoping we could leave the lto in the .cc->.o but take it out
>>>>>>>> of the partial links, and that that would fix the problem. If you have a
>>>>>>>> docker image I can try this all out on, that would be helpful. If I can get
>>>>>>>> ahold of that somehow, I can try to figure out how to fix this on Monday.
>>>>>>>> I'd speculate what's happening is that little inline functions, etc., which
>>>>>>>> I think are called "common" symbols are showing up more than once. Normally
>>>>>>>> that's ok and the linker will figure that out and get rid of the extra
>>>>>>>> copies, but apparently here it isn't doing that. There's a scons variable
>>>>>>>> which you can use to disable lto in the fast build if you want a workaround
>>>>>>>> for right now, although using gem5.fast is a bit dangerous in the first
>>>>>>>> place since I think it disables asserts, etc.
>>>>>>>>
>>>>>>>> Gabe
>>>>>>>>
>>>>>>>> On Sun, Jun 4, 2017 at 2:11 PM, Jason Lowe-Power <
>>>>>>>> ***@lowepower.com> wrote:
>>>>>>>>
>>>>>>>>> I tried passing -no-lto with ['-r', '-nostdlib'] on line
>>>>>>>>> SConstruct:688. However, that caused the error/warning:
>>>>>>>>> "/usr/bin/ld: build/X86/dev/io_device.fo: plugin needed to handle
>>>>>>>>> lto object" for every lib.fo.partial. I guess the -lto option during
>>>>>>>>> .cc->.o puts some data in the .o. Then, when partially linking with -r gcc
>>>>>>>>> gets confused?
>>>>>>>>>
>>>>>>>>> Should I filter out the -lto=8 from all of the .cc->.o? I could
>>>>>>>>> have mis-understood how to do this.
>>>>>>>>>
>>>>>>>>> Jason
>>>>>>>>>
>>>>>>>>> On Sun, Jun 4, 2017 at 4:08 PM Gabe Black <***@google.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Did you try filtering out the lto option from the partial link
>>>>>>>>>> steps like I suggested? Look at how I do that for -shared as an example.
>>>>>>>>>>
>>>>>>>>>> Gabe
>>>>>>>>>>
>>>>>>>>>> On May 24, 2017 2:00 PM, "Jason Lowe-Power" <***@lowepower.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi everyone,
>>>>>>>>>>>
>>>>>>>>>>> So I've been able to reproduce the problem. I would bet it's due
>>>>>>>>>>> to the new partial linking code (https://gem5.googlesource.com
>>>>>>>>>>> /public/gem5/+/6bdd897f04f4efdf90d0761c6d31d3f960f4eacf). I'm
>>>>>>>>>>> not sure what the solution is, yet, or if I'll have time to look at it in
>>>>>>>>>>> the next few day. Gabe might have an idea, though, if that is the problem.
>>>>>>>>>>>
>>>>>>>>>>> Here's a matrix of what compilers are working and which aren't
>>>>>>>>>>> (gcc-4.8 is working, too, though not tested on travis).
>>>>>>>>>>> https://travis-ci.org/powerjg/gem5-ci-test/builds/235779432
>>>>>>>>>>>
>>>>>>>>>>> Jason
>>>>>>>>>>>
>>>>>>>>>>> On Tue, May 23, 2017 at 4:33 PM Moussa, Ayman <
>>>>>>>>>>> ***@imperial.ac.uk> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> How can I check which compiler scons uses? These are the
>>>>>>>>>>>> compilers on my system
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
>>>>>>>>>>>> g++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
>>>>>>>>>>>> Linux 4.4.0-75-generic #96-Ubuntu SMP
>>>>>>>>>>>>
>>>>>>>>>>>> ------------------------------
>>>>>>>>>>>> *From:* gem5-users <gem5-users-***@gem5.org> on behalf of
>>>>>>>>>>>> Jason Lowe-Power <***@lowepower.com>
>>>>>>>>>>>> *Sent:* 23 May 2017 22:27:34
>>>>>>>>>>>>
>>>>>>>>>>>> *To:* gem5 users mailing list
>>>>>>>>>>>> *Subject:* Re: [gem5-users] Link error building gem5.fast
>>>>>>>>>>>>
>>>>>>>>>>>> I just tried again and still cannot reproduce the error. What
>>>>>>>>>>>> compiler are you using?
>>>>>>>>>>>>
>>>>>>>>>>>> Jason
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, May 23, 2017 at 3:41 PM Moussa, Ayman <
>>>>>>>>>>>> ***@imperial.ac.uk> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hey
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I've encountered this exact problem with x86 and it only seems
>>>>>>>>>>>>> to be for gem5.fast (gem5.opt works fine). I still have problems with a
>>>>>>>>>>>>> clean build as Jason suggested so I reverted back to some random commit on
>>>>>>>>>>>>> the gem5 repository and it works but it's not what I was looking for
>>>>>>>>>>>>> though. Hope this gets fixed soon.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ------------------------------
>>>>>>>>>>>>> *From:* gem5-users <gem5-users-***@gem5.org> on behalf of
>>>>>>>>>>>>> Alec Roelke <***@virginia.edu>
>>>>>>>>>>>>> *Sent:* 23 May 2017 21:14:10
>>>>>>>>>>>>> *To:* gem5 users mailing list
>>>>>>>>>>>>> *Subject:* [gem5-users] Link error building gem5.fast
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Everyone,
>>>>>>>>>>>>>
>>>>>>>>>>>>> When I try to build gem5.fast using any ISA, I get a lot of
>>>>>>>>>>>>> multiple definition errors during the final linking stage. For example,
>>>>>>>>>>>>> with x86:
>>>>>>>>>>>>>
>>>>>>>>>>>>> [ LINK] -> X86/gem5.fast.unstripped
>>>>>>>>>>>>> build/X86/arch/x86/bios/lib.fo.partial: In function
>>>>>>>>>>>>> `Drainable::drainResume()':
>>>>>>>>>>>>> (.text+0x5b00): multiple definition of
>>>>>>>>>>>>> `Drainable::drainResume()'
>>>>>>>>>>>>> build/X86/dev/x86/lib.fo.partial:(.text+0x0): first defined
>>>>>>>>>>>>> here
>>>>>>>>>>>>>
>>>>>>>>>>>>> There are way too many of these to list them all, but they're
>>>>>>>>>>>>> all multiple definitions of symbols. Has anyone else encountered this?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Alec Roelke
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> gem5-users mailing list
>>>>>>>>>>>>> gem5-***@gem5.org
>>>>>>>>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> gem5-users mailing list
>>>>>>>>>>>> gem5-***@gem5.org
>>>>>>>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>> IMPORTANT NOTICE: The contents of this email and any attachments are
>>>> confidential and may also be privileged. If you are not the intended
>>>> recipient, please notify the sender immediately and do not disclose the
>>>> contents to any other person, use it for any purpose, or store or copy the
>>>> information in any medium. Thank you.
>>>> _______________________________________________
>>>> gem5-users mailing list
>>>> gem5-***@gem5.org
>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>
>>>
>>> _______________________________________________
>>> gem5-users mailing list
>>> gem5-***@gem5.org
>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>
>>
>>
>

[Jason Lowe-Power]

That seems to work (
https://travis-ci.org/powerjg/gem5-ci-test/builds/239987760). And I tested
--force-lto and that works on gcc-6 as well.

Though, that test found build issues with a different commit on clang ;).

I'll take care of those new issues.

Cheers,
Jason

On Tue, Jun 6, 2017 at 12:31 AM Gabe Black <***@google.com> wrote:

> Could you give this a try on your magical many configurations server
> thing, Jason?
>
> https://gem5-review.googlesource.com/#/c/3680/
>
> I think it should cover the various failure modes we've discovered, but it
> would be good to know for sure.
>
> Gabe
>
> On Mon, Jun 5, 2017 at 8:52 PM, Gabe Black <***@google.com> wrote:
>
>> I think for version 6.0-ish (potentially going away in the future?)
>> you're supposed to add -flinker-output=rel as an option for the partial
>> links. Unfortunately when I do that, I get a different internal error
>> described here:
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69866
>>
>> Which was apparently fixed as recently as march of this year.
>>
>> Gabe
>>
>> On Mon, Jun 5, 2017 at 4:04 PM, Gabe Black <***@google.com> wrote:
>>
>>> I think those are all doable options. I'll give this a whirl, but while
>>> I'll try to have a quick turnaround I can't make guarantees since I'll be
>>> going on vacation next week and need to get a few things done. I don't
>>> think it'll be too bad to implement though, so it shouldn't be a problem.
>>>
>>> Gabe
>>>
>>> On Mon, Jun 5, 2017 at 3:23 PM, Jason Lowe-Power <***@lowepower.com>
>>> wrote:
>>>
>>>> Hey Gabe,
>>>>
>>>> How hard would it be to have an option for partial linking? If we could
>>>> have a --force-lto option that did the opposite (enable lto and disable
>>>> partial linking), that would be great. But if this would be a giant scons
>>>> pain, I understand :).
>>>>
>>>> Jason
>>>>
>>>> On Mon, Jun 5, 2017 at 5:21 PM Andreas Hansson <***@arm.com>
>>>> wrote:
>>>>
>>>>> I think dropping LTO for the affected compilers is probably the right
>>>>> option, but it is potentially quite a blow to performance if we simply
>>>>> leave it at that. Back when I profiled LTO usage I remember seeing 10+
>>>>> percent difference with and without LTO.
>>>>>
>>>>> Andreas
>>>>>
>>>>> From: gem5-users <gem5-users-***@gem5.org> on behalf of Jason
>>>>> Lowe-Power <***@lowepower.com>
>>>>> Reply-To: gem5 users mailing list <gem5-***@gem5.org>
>>>>> Date: Monday, 5 June 2017 at 23:16
>>>>> To: Gabe Black <***@google.com>
>>>>> Cc: gem5 users mailing list <gem5-***@gem5.org>
>>>>>
>>>>> Subject: Re: [gem5-users] Link error building gem5.fast
>>>>>
>>>>> I'm fine with dropping LTO on gcc 4.9-6. (It also works on gcc 4.8 for
>>>>> me, BTW.) I it's also failing for gcc 6 (see
>>>>> https://travis-ci.org/powerjg/gem5-ci-test).
>>>>>
>>>>> If you make a patch for this, could you add some detailed comments so
>>>>> we can "undo" this change when we all move to gcc 7+?
>>>>>
>>>>> Thanks for tracking this down!
>>>>>
>>>>> Jason
>>>>>
>>>>> On Mon, Jun 5, 2017 at 4:47 PM Gabe Black <***@google.com>
>>>>> wrote:
>>>>>
>>>>>> I also used this thread/bug as a basis for my diagnosis.
>>>>>>
>>>>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67548
>>>>>>
>>>>>> On Mon, Jun 5, 2017 at 2:40 PM, Gabe Black <***@google.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Ok, I did some digging around about this, and while a lot of the
>>>>>>> talk between gcc devs sounds like gibberish to me, I did pick out bits and
>>>>>>> pieces which makes me think this is just something that's broken in gcc of
>>>>>>> particular versions. There's some documentation of the state of things in
>>>>>>> gcc version 6 where it says things are fixed to the point where they can be
>>>>>>> worked with, and that in version 7 they expect them to be totally fixed up:
>>>>>>>
>>>>>>> https://gcc.gnu.org/gcc-6/changes.html
>>>>>>>
>>>>>>> The problem seems to be that there were assumptions being made in
>>>>>>> the LTO gcc plugin that the link was a final link all the time, and that
>>>>>>> weak external symbols (the inline functions that might show up multiple
>>>>>>> times) should be promoted to regular external symbols. That breaks things
>>>>>>> since, in subsequent links, there are more copies of them and they all look
>>>>>>> like they're supposed to be unique.
>>>>>>>
>>>>>>> What I think we should do is detect what situation we're in and
>>>>>>> react accordingly. In gcc version 5.0-6.0 (maybe 4.9 or 4.8, although 4.8
>>>>>>> seems to work for me) we need to avoid doing either partial linking or LTO
>>>>>>> since the combination doesn't work. It would be easier to make scons avoid
>>>>>>> LTO since that would just be changing the compiler flags and not
>>>>>>> structurally changing how the build flows or how the scons scripts are
>>>>>>> written.
>>>>>>>
>>>>>>> In versions 6.0 to 7.0, if those release notes are to be believed,
>>>>>>> we would need to decide between doing the partial link with gcc or with ld.
>>>>>>> It sounds like ld is better since it would still do whole program
>>>>>>> optimization, although again it might be more difficult to twist scon's arm
>>>>>>> and get it to do things that way since its linker command line uses gcc. We
>>>>>>> could pass -r to ld directly by wrapping it in -Wl,-r, but that apparently
>>>>>>> caused issues for people on macs.
>>>>>>>
>>>>>>> And then, in the glorious future where we're using gcc v7 which
>>>>>>> works properly, or if you're using clang, we can stop worrying about it
>>>>>>> since -r and -lto will play nicely together.
>>>>>>>
>>>>>>> Thoughts?
>>>>>>>
>>>>>>> Gabe
>>>>>>>
>>>>>>> On Sun, Jun 4, 2017 at 3:11 PM, Jason Lowe-Power <
>>>>>>> ***@lowepower.com> wrote:
>>>>>>>
>>>>>>>> Hi Gabe,
>>>>>>>>
>>>>>>>> I think the follow "just works" by downloading the image from
>>>>>>>> dockerhub.
>>>>>>>>
>>>>>>>> > docker run -v `pwd`:`pwd` -it powerjg/gem5-gcc-6-build /bin/bash
>>>>>>>>
>>>>>>>>
>>>>>>>> Or, to just download the image:
>>>>>>>>
>>>>>>>> > docker pull powerjg/gem5-gcc-6-build
>>>>>>>>
>>>>>>>> Let me know if that doesn't work for you.
>>>>>>>>
>>>>>>>> I searched around some to try to track down the issue. It seems
>>>>>>>> that GCC doesn't love doing LTO and partial linking. There have been a
>>>>>>>> number of bugs related to this in the past. But, all of the bugs that I
>>>>>>>> found had been fixed before gcc 5.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Jason
>>>>>>>>
>>>>>>>> On Sun, Jun 4, 2017 at 4:37 PM Gabe Black <***@google.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> I was hoping we could leave the lto in the .cc->.o but take it out
>>>>>>>>> of the partial links, and that that would fix the problem. If you have a
>>>>>>>>> docker image I can try this all out on, that would be helpful. If I can get
>>>>>>>>> ahold of that somehow, I can try to figure out how to fix this on Monday.
>>>>>>>>> I'd speculate what's happening is that little inline functions, etc., which
>>>>>>>>> I think are called "common" symbols are showing up more than once. Normally
>>>>>>>>> that's ok and the linker will figure that out and get rid of the extra
>>>>>>>>> copies, but apparently here it isn't doing that. There's a scons variable
>>>>>>>>> which you can use to disable lto in the fast build if you want a workaround
>>>>>>>>> for right now, although using gem5.fast is a bit dangerous in the first
>>>>>>>>> place since I think it disables asserts, etc.
>>>>>>>>>
>>>>>>>>> Gabe
>>>>>>>>>
>>>>>>>>> On Sun, Jun 4, 2017 at 2:11 PM, Jason Lowe-Power <
>>>>>>>>> ***@lowepower.com> wrote:
>>>>>>>>>
>>>>>>>>>> I tried passing -no-lto with ['-r', '-nostdlib'] on line
>>>>>>>>>> SConstruct:688. However, that caused the error/warning:
>>>>>>>>>> "/usr/bin/ld: build/X86/dev/io_device.fo: plugin needed to
>>>>>>>>>> handle lto object" for every lib.fo.partial. I guess the -lto option during
>>>>>>>>>> .cc->.o puts some data in the .o. Then, when partially linking with -r gcc
>>>>>>>>>> gets confused?
>>>>>>>>>>
>>>>>>>>>> Should I filter out the -lto=8 from all of the .cc->.o? I could
>>>>>>>>>> have mis-understood how to do this.
>>>>>>>>>>
>>>>>>>>>> Jason
>>>>>>>>>>
>>>>>>>>>> On Sun, Jun 4, 2017 at 4:08 PM Gabe Black <***@google.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Did you try filtering out the lto option from the partial link
>>>>>>>>>>> steps like I suggested? Look at how I do that for -shared as an example.
>>>>>>>>>>>
>>>>>>>>>>> Gabe
>>>>>>>>>>>
>>>>>>>>>>> On May 24, 2017 2:00 PM, "Jason Lowe-Power" <***@lowepower.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi everyone,
>>>>>>>>>>>>
>>>>>>>>>>>> So I've been able to reproduce the problem. I would bet it's
>>>>>>>>>>>> due to the new partial linking code (
>>>>>>>>>>>> https://gem5.googlesource.com/public/gem5/+/6bdd897f04f4efdf90d0761c6d31d3f960f4eacf).
>>>>>>>>>>>> I'm not sure what the solution is, yet, or if I'll have time to look at it
>>>>>>>>>>>> in the next few day. Gabe might have an idea, though, if that is the
>>>>>>>>>>>> problem.
>>>>>>>>>>>>
>>>>>>>>>>>> Here's a matrix of what compilers are working and which aren't
>>>>>>>>>>>> (gcc-4.8 is working, too, though not tested on travis).
>>>>>>>>>>>> https://travis-ci.org/powerjg/gem5-ci-test/builds/235779432
>>>>>>>>>>>>
>>>>>>>>>>>> Jason
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, May 23, 2017 at 4:33 PM Moussa, Ayman <
>>>>>>>>>>>> ***@imperial.ac.uk> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> How can I check which compiler scons uses? These are the
>>>>>>>>>>>>> compilers on my system
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
>>>>>>>>>>>>> g++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
>>>>>>>>>>>>> Linux 4.4.0-75-generic #96-Ubuntu SMP
>>>>>>>>>>>>>
>>>>>>>>>>>>> ------------------------------
>>>>>>>>>>>>> *From:* gem5-users <gem5-users-***@gem5.org> on behalf of
>>>>>>>>>>>>> Jason Lowe-Power <***@lowepower.com>
>>>>>>>>>>>>> *Sent:* 23 May 2017 22:27:34
>>>>>>>>>>>>>
>>>>>>>>>>>>> *To:* gem5 users mailing list
>>>>>>>>>>>>> *Subject:* Re: [gem5-users] Link error building gem5.fast
>>>>>>>>>>>>>
>>>>>>>>>>>>> I just tried again and still cannot reproduce the error. What
>>>>>>>>>>>>> compiler are you using?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Jason
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, May 23, 2017 at 3:41 PM Moussa, Ayman <
>>>>>>>>>>>>> ***@imperial.ac.uk> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hey
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I've encountered this exact problem with x86 and it only
>>>>>>>>>>>>>> seems to be for gem5.fast (gem5.opt works fine). I still have problems with
>>>>>>>>>>>>>> a clean build as Jason suggested so I reverted back to some random commit
>>>>>>>>>>>>>> on the gem5 repository and it works but it's not what I was looking for
>>>>>>>>>>>>>> though. Hope this gets fixed soon.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ------------------------------
>>>>>>>>>>>>>> *From:* gem5-users <gem5-users-***@gem5.org> on behalf
>>>>>>>>>>>>>> of Alec Roelke <***@virginia.edu>
>>>>>>>>>>>>>> *Sent:* 23 May 2017 21:14:10
>>>>>>>>>>>>>> *To:* gem5 users mailing list
>>>>>>>>>>>>>> *Subject:* [gem5-users] Link error building gem5.fast
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Everyone,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> When I try to build gem5.fast using any ISA, I get a lot of
>>>>>>>>>>>>>> multiple definition errors during the final linking stage. For example,
>>>>>>>>>>>>>> with x86:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> [ LINK] -> X86/gem5.fast.unstripped
>>>>>>>>>>>>>> build/X86/arch/x86/bios/lib.fo.partial: In function
>>>>>>>>>>>>>> `Drainable::drainResume()':
>>>>>>>>>>>>>> (.text+0x5b00): multiple definition of
>>>>>>>>>>>>>> `Drainable::drainResume()'
>>>>>>>>>>>>>> build/X86/dev/x86/lib.fo.partial:(.text+0x0): first defined
>>>>>>>>>>>>>> here
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> There are way too many of these to list them all, but they're
>>>>>>>>>>>>>> all multiple definitions of symbols. Has anyone else encountered this?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> Alec Roelke
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> gem5-users mailing list
>>>>>>>>>>>>>> gem5-***@gem5.org
>>>>>>>>>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> gem5-users mailing list
>>>>>>>>>>>>> gem5-***@gem5.org
>>>>>>>>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>> IMPORTANT NOTICE: The contents of this email and any attachments are
>>>>> confidential and may also be privileged. If you are not the intended
>>>>> recipient, please notify the sender immediately and do not disclose the
>>>>> contents to any other person, use it for any purpose, or store or copy the
>>>>> information in any medium. Thank you.
>>>>> _______________________________________________
>>>>> gem5-users mailing list
>>>>> gem5-***@gem5.org
>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>>
>>>>
>>>> _______________________________________________
>>>> gem5-users mailing list
>>>> gem5-***@gem5.org
>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>>
>>>
>>>
>>
> _______________________________________________
> gem5-users mailing list
> gem5-***@gem5.org
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users