Multiple Simulators Link Failure on Head

Multiple Simulators Link Failure on Head

[Joel Sherrill]

Hi

Multiple targets fail to link with sim_addr_range_hit_p. The
targets are:

   bfin h8300 lm32 m32r mips moxie v850

gcc -DHAVE_CONFIG_H   -DWITH_DEFAULT_MODEL='"bf537"' -DTRACE=1 
-DWITH_TRACE=-1 -DPROFILE=1 -DWITH_PROFILE=-1   
-DWITH_DEFAULT_ALIGNMENT=STRICT_ALIGNMENT  
-DWITH_TARGET_BYTE_ORDER=LITTLE_ENDIAN 
-DWITH_ENVIRONMENT=ALL_ENVIRONMENT  -DWITH_HW=1 
-DWITH_HOST_BYTE_ORDER=LITTLE_ENDIAN        -Wall 
-Wdeclaration-after-statement -Wpointer-arith -Wpointer-sign -Wno-unused 
-Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts 
-Wmissing-prototypes -Wdeclaration-after-statement -Wempty-body 
-Wmissing-parameter-type -Wold-style-declaration -Wold-style-definition 
-Wformat-nonliteral       -I. -I../../../binutils-gdb/sim/bfin 
-I../common -I../../../binutils-gdb/sim/bfin/../common -I../../include 
-I../../../binutils-gdb/sim/bfin/../../include -I../../bfd 
-I../../../binutils-gdb/sim/bfin/../../bfd -I../../opcodes 
-I../../../binutils-gdb/sim/bfin/../../opcodes  -g -O2 -static-libstdc++ 
-static-libgcc  -o run \
   nrun.o libsim.a ../../bfd/libbfd.a ../../opcodes/libopcodes.a  
../../libiberty/libiberty.a -lm -ldl -lz -lnsl  -lm
libsim.a(sim-info.o): In function `sim_addr_range_hit_p':
/users/joel/test-gcc/b-bfin-rtems4.11-bin/sim/bfin/../../../binutils-gdb/sim/bfin/../common/sim-arange.c:290: 
multiple definition of `sim_addr_range_hit_p'
nrun.o:/users/joel/test-gcc/b-bfin-rtems4.11-bin/sim/bfin/../../../binutils-gdb/sim/bfin/../common/sim-arange.c:290: 
first defined here
libsim.a(sim-module.o): In function `sim_addr_range_hit_p':
/users/joel/test-gcc/b-bfin-rtems4.11-bin/sim/bfin/../../../binutils-gdb/sim/bfin/../common/sim-arange.c:290: 
multiple definition of `sim_addr_range_hit_p'
nrun.o:/users/joel/test-gcc/b-bfin-rtems4.11-bin/sim/bfin/../../../binutils-gdb/sim/bfin/../common/sim-arange.c:290: 
first defined here
libsim.a(sim-options.o): In function `sim_addr_range_hit_p':
/users/joel/test-gcc/b-bfin-rtems4.11-bin/sim/bfin/../../../binutils-gdb/sim/bfin/../common/sim-arange.c:290: 
multiple definition of `sim_addr_range_hit_p'
nrun.o:/users/joel/test-gcc/b-bfin-rtems4.11-bin/sim/bfin/../../../binutils-gdb/sim/bfin/../common/sim-arange.c:290: 
first defined here
libsim.a(sim-profile.o): In function `sim_addr_range_hit_p':
/users/joel/test-gcc/b-bfin-rtems4.11-bin/sim/bfin/../../../binutils-gdb/sim/bfin/../common/sim-arange.c:290: 
multiple definition of `sim_addr_range_hit_p'
nrun.o:/users/joel/test-gcc/b-bfin-rtems4.11-bin/sim/bfin/../../../binutils-gdb/sim/bfin/../common/sim-arange.c:290: 
first defined here
libsim.a(sim-signal.o): In function `sim_addr_range_hit_p':


--joel

Re: Multiple Simulators Link Failure on Head

[Joel Sherrill]

On 3/20/2015 10:38 AM, Mike Frysinger wrote:
> On 20 Mar 2015 08:16, Joel Sherrill wrote:
>> Multiple targets fail to link with sim_addr_range_hit_p. The
>> targets are:
> are you doing incremental builds ?  or did you build entirely from scratch ?  
> some changes landed recently that would break incremental, so you should build 
> the sim dir from scratch.
The build directory is removed and remade every time
> how exactly did you run configure ? 
../binutils-gdb/configure --target=h8300-rtems4.11 \
  --prefix=/users/joel/test-gcc/install-head --disable-werror \
  --enable-sim --enable-sim-hardware --enable-timebase --enable-sim-trace

>  how about `make` ?
make -j8
> i build every sim target myself and run their testsuites before i push new sim 
> commits ...
Hmmm... h8300-rtems4.11 just built this morning.

Same build script. Not sure what happened. Let me do a build of all targets
again and see what happens this time.

sigh.. ghosts. :(
> -mike

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

Re: Multiple Simulators Link Failure on Head

[Joel Sherrill]

This looks to be an issue with the "make -j8".
I did it again with "-j8" and it failed. I did a simple "make clean all"
in that directory and it failed again.

I then changed my script to drop the -j8 and it built ok again.

My suspicion is something in the dependencies isn't 100% right
and there is a race condition. sim/common/cconfig.h is the same
in a tree built with -j1 vs -j8.

--joel

On 3/20/2015 10:38 AM, Mike Frysinger wrote:
> On 20 Mar 2015 08:16, Joel Sherrill wrote:
>> Multiple targets fail to link with sim_addr_range_hit_p. The
>> targets are:
> are you doing incremental builds ?  or did you build entirely from scratch ?  
> some changes landed recently that would break incremental, so you should build 
> the sim dir from scratch.
>
> how exactly did you run configure ?  how about `make` ?
>
> i build every sim target myself and run their testsuites before i push new sim 
> commits ...
> -mike

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

Re: Multiple Simulators Link Failure on Head

[Mike Frysinger]

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

On 20 Mar 2015 13:13, Joel Sherrill wrote:
> This looks to be an issue with the "make -j8".
> I did it again with "-j8" and it failed. I did a simple "make clean all"
> in that directory and it failed again.

ok, i'll take a look.  i use -j4 everywhere myself, so most egregious errors 
shake out.

side note: could you avoid top posting ?
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Multiple Simulators Link Failure on Head

[Mike Frysinger]

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

On 20 Mar 2015 13:13, Joel Sherrill wrote:
> This looks to be an issue with the "make -j8".
> I did it again with "-j8" and it failed. I did a simple "make clean all"
> in that directory and it failed again.
> 
> I then changed my script to drop the -j8 and it built ok again.
> 
> My suspicion is something in the dependencies isn't 100% right
> and there is a race condition. sim/common/cconfig.h is the same
> in a tree built with -j1 vs -j8.

a high level note: it's not possible to race between common/ and other subdirs.  
the configure script explicitly runs configure for all subdirs first, and that 
is how config.h/cconfig.h get generated.  the common/ subdir otherwise does not 
produce any objects.
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Multiple Simulators Link Failure on Head

[Mike Frysinger]

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

On 20 Mar 2015 13:13, Joel Sherrill wrote:
> This looks to be an issue with the "make -j8".
> I did it again with "-j8" and it failed. I did a simple "make clean all"
> in that directory and it failed again.
> 
> I then changed my script to drop the -j8 and it built ok again.
> 
> My suspicion is something in the dependencies isn't 100% right
> and there is a race condition. sim/common/cconfig.h is the same
> in a tree built with -j1 vs -j8.

when it fails, can you attach the full build log ?

what gcc version are you using ?  there might be some misbehavior with the usage 
of extern inline.  i think the code base expects gnu_inline semantics but just 
uses "extern inline" directly.  maybe try including -fgnu89-inline in your 
CFLAGS and see if that helps ?
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Multiple Simulators Link Failure on Head

[Joel Sherrill]

On 3/22/2015 9:29 PM, Mike Frysinger wrote:
> On 20 Mar 2015 13:13, Joel Sherrill wrote:
>> This looks to be an issue with the "make -j8".
>> I did it again with "-j8" and it failed. I did a simple "make clean all"
>> in that directory and it failed again.
>>
>> I then changed my script to drop the -j8 and it built ok again.
>>
>> My suspicion is something in the dependencies isn't 100% right
>> and there is a race condition. sim/common/cconfig.h is the same
>> in a tree built with -j1 vs -j8.
> when it fails, can you attach the full build log ?
>
> what gcc version are you using ?  there might be some misbehavior with the usage 
> of extern inline.  i think the code base expects gnu_inline semantics but just 
> uses "extern inline" directly.  maybe try including -fgnu89-inline in your 
> CFLAGS and see if that helps ?
I am not in good position to send build logs or try the alternative CFLAGS
until another long build finishes.

But the idea of the gcc version sounds promising. I am building with a gcc
from near the head. The default version of C has changed to C11 and I
know that has caused a few odd issues with RTEMS. Maybe this has
impacted the the compilation of this method.

$ gcc --version
gcc (GCC) 5.0.0 20150211 (experimental)


I will try the suggestions as soon as I can.


> -mike
--joel

Re: Multiple Simulators Link Failure on Head

[Joel Sherrill]

On 03/22/2015 05:46 PM, Joel Sherrill wrote:
>
> On 3/22/2015 9:29 PM, Mike Frysinger wrote:
>> On 20 Mar 2015 13:13, Joel Sherrill wrote:
>>> This looks to be an issue with the "make -j8".
>>> I did it again with "-j8" and it failed. I did a simple "make clean all"
>>> in that directory and it failed again.
>>>
>>> I then changed my script to drop the -j8 and it built ok again.
>>>
>>> My suspicion is something in the dependencies isn't 100% right
>>> and there is a race condition. sim/common/cconfig.h is the same
>>> in a tree built with -j1 vs -j8.
>> when it fails, can you attach the full build log ?
>>
>> what gcc version are you using ?  there might be some misbehavior with the usage
>> of extern inline.  i think the code base expects gnu_inline semantics but just
>> uses "extern inline" directly.  maybe try including -fgnu89-inline in your
>> CFLAGS and see if that helps ?
> I am not in good position to send build logs or try the alternative CFLAGS
> until another long build finishes.
>
> But the idea of the gcc version sounds promising. I am building with a gcc
> from near the head. The default version of C has changed to C11 and I
> know that has caused a few odd issues with RTEMS. Maybe this has
> impacted the the compilation of this method.
>
> $ gcc --version
> gcc (GCC) 5.0.0 20150211 (experimental)
>
>
> I will try the suggestions as soon as I can.
>
>
I can confirm that lm32 and other targets built with the native
Fedora compiler.

$ gcc --version
gcc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-7)

But failed with I switched to using the more recent native I
listed above.

I can provide a log if you want but that should be enough to
reproduce this.
>> -mike
> --joel

Re: Multiple Simulators Link Failure on Head

[Mike Frysinger]

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

On 23 Mar 2015 09:32, Joel Sherrill wrote:
> On 03/22/2015 05:46 PM, Joel Sherrill wrote:
> > On 3/22/2015 9:29 PM, Mike Frysinger wrote:
> >> On 20 Mar 2015 13:13, Joel Sherrill wrote:
> >>> This looks to be an issue with the "make -j8".
> >>> I did it again with "-j8" and it failed. I did a simple "make clean all"
> >>> in that directory and it failed again.
> >>>
> >>> I then changed my script to drop the -j8 and it built ok again.
> >>>
> >>> My suspicion is something in the dependencies isn't 100% right
> >>> and there is a race condition. sim/common/cconfig.h is the same
> >>> in a tree built with -j1 vs -j8.
> >> when it fails, can you attach the full build log ?
> >>
> >> what gcc version are you using ?  there might be some misbehavior with the usage
> >> of extern inline.  i think the code base expects gnu_inline semantics but just
> >> uses "extern inline" directly.  maybe try including -fgnu89-inline in your
> >> CFLAGS and see if that helps ?
> > I am not in good position to send build logs or try the alternative CFLAGS
> > until another long build finishes.
> >
> > But the idea of the gcc version sounds promising. I am building with a gcc
> > from near the head. The default version of C has changed to C11 and I
> > know that has caused a few odd issues with RTEMS. Maybe this has
> > impacted the the compilation of this method.
> >
> > $ gcc --version
> > gcc (GCC) 5.0.0 20150211 (experimental)
> >
> >
> > I will try the suggestions as soon as I can.
>
> I can confirm that lm32 and other targets built with the native
> Fedora compiler.
> 
> $ gcc --version
> gcc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-7)
> 
> But failed with I switched to using the more recent native I
> listed above.
> 
> I can provide a log if you want but that should be enough to
> reproduce this.

ok, i guess i have to stop being lazy and get Gentoo's gcc-5 snapshots working 
again
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]