Re: [PATCH] [RTEMS] Update RTEMS thread model

2015-09-23 Thread Sebastian Huber 



On 22/09/15 16:01, Aurelio Remonda wrote:

Thank you Sebastian! We were able to reproduce the tests.
The test we were interested in was 
25_algorithms/random_shuffle/moveable, this one fails, as we saw in 
your results (and ours as well). We debugged it and find out that all 
three VERIFY pass (cout of the same line gave us 1, is an equal) but 
we didn't get the exit code 0 at the end of the simulation. 
Apparently, this is making DejaGNU think something's wrong.
We find out that if we reduce the size of A (the array that contains 
the values being shuffled) the test runs correctly.


Ok, its a classic stack overflow (80 bytes on the stack, stack size 
is 256KiB).


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] [RTEMS] Update RTEMS thread model

2015-09-22 Thread Aurelio Remonda 
>
> This change to the test needs to be discussed on the appropriate GCC
> mailing list with Sebastian and I cc'ed.
>
> How large was it? When it works? Is it on the stack?
>
> The size of A is 20. We tested it with 2000 and still works but not
with 5 (don't know what happen in the middle).
Is not on the stack.

Gcc tests already accommodate small targets on some tests so there may be
> an existing define to test or the size really doesn't matter and can be
> reduced for all targets. These are normally acceptable options to the GCC
> community.
>

There is no define that we know for this one, as far as we know it doesn't
really matter, the test basically shuffle's values and check if the values
are not in order (the array is filled with values in order).


> Or we might be able to change the stack of main() in our harness.
>
> So simple but multiple ways to solve. Just need to figure out the best way.
>
>
-- 

Aurelio Remonda

Software Engineer
San Lorenzo 47, 3rd Floor, Office 5
Córdoba, Argentina
*Phone:* +54-351-4217888 / 4218211
 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] [RTEMS] Update RTEMS thread model

2015-09-22 Thread Aurelio Remonda 
Thank you Sebastian! We were able to reproduce the tests.
The test we were interested in was 25_algorithms/random_shuffle/moveable,
this one fails, as we saw in your results (and ours as well). We debugged
it and find out that all three VERIFY pass (cout of the same line gave us
1, is an equal) but we didn't get the exit code 0 at the end of the
simulation. Apparently, this is making DejaGNU think something's wrong.
We find out that if we reduce the size of A (the array that contains the
values being shuffled) the test runs correctly.


On Fri, Sep 18, 2015 at 5:24 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

>
>
> On 17/09/15 16:36, Aurelio Remonda wrote:
>
>> It is printing the "real time" but the time is set to a date early
>>> >in the RTEMS development history. Look at the year. That's about the
>>> >time the test was initially written.
>>> >
>>> >It is likely running faster than "real time" because it is a simulator.
>>> >The numbers not ending in "5" is a bit unusual. The test consists of
>>> >four tasks:
>>> >
>>> >+ one runs every 5 seconds
>>> >+ one every 10
>>> >+ one every 15
>>> >+ IDLE
>>> >
>>> >It exits when one notices it has gone over 30 seconds.
>>>
>> Thank you Joel! I have another question if you don't mind: where i can
>> find the realview_pbx_a9_qemu.exp file?
>> I can't find it in dejagnu/boards.
>>
>
> Sorry, I check this file in.
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>


-- 

Aurelio Remonda

Software Engineer
San Lorenzo 47, 3rd Floor, Office 5
Córdoba, Argentina
*Phone:* +54-351-4217888 / 4218211
 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] [RTEMS] Update RTEMS thread model

2015-09-22 Thread Joel Sherrill 


On September 22, 2015 10:01:49 AM EDT, Aurelio Remonda 
 wrote:
>Thank you Sebastian! We were able to reproduce the tests. 
>The test we were interested in was
>25_algorithms/random_shuffle/moveable, this one fails, as we saw in
>your results (and ours as well). We debugged it and find out that all
>three VERIFY pass (cout of the same line gave us 1, is an equal) but we
>didn't get the exit code 0 at the end of the simulation. Apparently,
>this is making DejaGNU think something's wrong.
>
>We find out that if we reduce the size of A (the array that contains
>the values being shuffled) the test runs correctly.
>

This change to the test needs to be discussed on the appropriate GCC mailing 
list with Sebastian and I cc'ed.

How large was it? When it works? Is it on the stack?

Gcc tests already accommodate small targets on some tests so there may be an 
existing define to test or the size really doesn't matter and can be reduced 
for all targets. These are normally acceptable options to the GCC community.

Or we might be able to change the stack of main() in our harness.

So simple but multiple ways to solve. Just need to figure out the best way.  


>
>On Fri, Sep 18, 2015 at 5:24 AM, Sebastian Huber
> wrote:
>
>
>
>On 17/09/15 16:36, Aurelio Remonda wrote:
>
>It is printing the "real time" but the time is set to a date early
>>in the RTEMS development history. Look at the year. That's about the
>>time the test was initially written.
>>
>>It is likely running faster than "real time" because it is a
>simulator.
>>The numbers not ending in "5" is a bit unusual. The test consists of
>>four tasks:
>>
>>+ one runs every 5 seconds
>>+ one every 10
>>+ one every 15
>>+ IDLE
>>
>>It exits when one notices it has gone over 30 seconds.
>
>Thank you Joel! I have another question if you don't mind: where i can
>find the realview_pbx_a9_qemu.exp file?
>I can't find it in dejagnu/boards.
>
>
>Sorry, I check this file in.
>
>-- 
>Sebastian Huber, embedded brains GmbH
>
>Address : Dornierstr. 4, D-82178 Puchheim, Germany
>Phone   : +49 89 189 47 41-16
>Fax : +49 89 189 47 41-09
>E-Mail  : sebastian.hu...@embedded-brains.de
>PGP : Public key available on request.
>
>Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
>
>
>-- 
>
>Aurelio Remonda
>
>Software Engineer
>
>San Lorenzo 47, 3rd Floor, Office 5
>Córdoba, Argentina 
>Phone: +54-351-4217888 / 4218211
> 

--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] [RTEMS] Update RTEMS thread model

2015-09-18 Thread Sebastian Huber 



On 17/09/15 16:36, Aurelio Remonda wrote:

It is printing the "real time" but the time is set to a date early
>in the RTEMS development history. Look at the year. That's about the
>time the test was initially written.
>
>It is likely running faster than "real time" because it is a simulator.
>The numbers not ending in "5" is a bit unusual. The test consists of
>four tasks:
>
>+ one runs every 5 seconds
>+ one every 10
>+ one every 15
>+ IDLE
>
>It exits when one notices it has gone over 30 seconds.

Thank you Joel! I have another question if you don't mind: where i can find the 
realview_pbx_a9_qemu.exp file?
I can't find it in dejagnu/boards.


Sorry, I check this file in.

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re:[PATCH] [RTEMS] Update RTEMS thread model

2015-09-17 Thread Aurelio Remonda 
> It is printing the "real time" but the time is set to a date early
> in the RTEMS development history. Look at the year. That's about the
> time the test was initially written.
>
> It is likely running faster than "real time" because it is a simulator.
> The numbers not ending in "5" is a bit unusual. The test consists of
> four tasks:
>
> + one runs every 5 seconds
> + one every 10
> + one every 15
> + IDLE
>
> It exits when one notices it has gone over 30 seconds.

Thank you Joel! I have another question if you don't mind: where i can find the 
realview_pbx_a9_qemu.exp file?
I can't find it in dejagnu/boards.

I did try making one (basically a copy of rtems-i386-qemu.exp with 
modifications), though. However, when I try:
make check 'RUNTESTFLAGS= SIM=realview_pbx_a9_qemu 
RTEMS_MAKEFILE_PATH=/home/aurelio-remonda/test-gcc/install-svn/arm-rtems4.11/realview_pbx_a9_qemu/
 RTEMS_CONFIG_OBJ=/home/aurelio-remonda/test-gcc/rtems-testing/gcc/ 
--target_board=rtems-arm-realview_pbx_a9_qemu{-march=armv7-a/-mthumb/-mfpu=neon/-mfloat-abi=hard}'

I get a lot of 'compilation failed to produce executable' messages. The log 
tells me 'No libgloss support for this target'. At the end I get this:


=== libstdc++ Summary ===

# of expected passes2676
# of unexpected failures3162
# of expected failures  6
# of unresolved testcases   3129
# of unsupported tests  808
runtest completed at Tue Sep 15 11:59:24 2015


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] [RTEMS] Update RTEMS thread model

2015-09-17 Thread Joel Sherrill 



On 9/17/2015 9:36 AM, Aurelio Remonda wrote:

It is printing the "real time" but the time is set to a date early
in the RTEMS development history. Look at the year. That's about the
time the test was initially written.

It is likely running faster than "real time" because it is a simulator.
The numbers not ending in "5" is a bit unusual. The test consists of
four tasks:

+ one runs every 5 seconds
+ one every 10
+ one every 15
+ IDLE

It exits when one notices it has gone over 30 seconds.


Thank you Joel! I have another question if you don't mind: where i can find the 
realview_pbx_a9_qemu.exp file?
I can't find it in dejagnu/boards.

I did try making one (basically a copy of rtems-i386-qemu.exp with 
modifications), though. However, when I try:
make check 'RUNTESTFLAGS= SIM=realview_pbx_a9_qemu 
RTEMS_MAKEFILE_PATH=/home/aurelio-remonda/test-gcc/install-svn/arm-rtems4.11/realview_pbx_a9_qemu/
 RTEMS_CONFIG_OBJ=/home/aurelio-remonda/test-gcc/rtems-testing/gcc/ 
--target_board=rtems-arm-realview_pbx_a9_qemu{-march=armv7-a/-mthumb/-mfpu=neon/-mfloat-abi=hard}'


Apparently Sebastian either hasn't run the tests on this or hasn't pushed
the board file for this BSP.

I think there may be one also missing for the xilinx on qemu.

Sebastian?

The files are largely copies with the sim script name changed. Copy
one, fix, use it, and submit it if Sebastian doesn't have one to push. :)


I get a lot of 'compilation failed to produce executable' messages. The log 
tells me 'No libgloss support for this target'. At the end I get this:


This is because you are testing against a DejaGNU configuration file
that assumes arm-eabi not arm-rtems.



=== libstdc++ Summary ===

# of expected passes2676
# of unexpected failures3162
# of expected failures  6
# of unresolved testcases   3129
# of unsupported tests  808
runtest completed at Tue Sep 15 11:59:24 2015


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel



--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] [RTEMS] Update RTEMS thread model

2015-09-14 Thread Gedare Bloom 
On Mon, Sep 14, 2015 at 7:33 AM, Sebastian Huber
 wrote:
>
>
> On 11/09/15 16:21, Aurelio Remonda wrote:
>>>
>>> The test runners are in "sim-scripts" make sure a "realview_pbx_a9_qemu
>>> >-i ticker.exe" produces the expected output.
>>
>> Hi, silly question here, running ticker gave me the elapsed times
>> but not in 'real time'. It prints 09:00:00, 09:00:04,..., 09:00:34
>> immediately. Is this a normal behaviour for this test in this BSP?
>
>
> Yes, in case the fast idle is enabled (default). This helps to speed up test
> suite runs.
>
Any clue why the test is rounding off a second? It should give
09:00:00, 09:00:05, ..., 09:00:35

> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] [RTEMS] Update RTEMS thread model

2015-09-14 Thread Aurelio Remonda 
On Fri, Sep 11, 2015 at 11:34 AM, Joel Sherrill 
wrote:

>
>
> On 9/11/2015 9:21 AM, Aurelio Remonda wrote:
>
>> The test runners are in "sim-scripts" make sure a "realview_pbx_a9_qemu
>>> -i ticker.exe" produces the expected output.
>>>
>>
>> Hi, silly question here, running ticker gave me the elapsed times
>> but not in 'real time'. It prints 09:00:00, 09:00:04,..., 09:00:34
>> immediately. Is this a norma behaviour for this test in this BSP?
>>
>
> It is printing the "real time" but the time is set to a date early
> in the RTEMS development history. Look at the year. That's about the
> time the test was initially written.
>
> It is likely running faster than "real time" because it is a simulator.
> The numbers not ending in "5" is a bit unusual. The test consists of
> four tasks:
>
> + one runs every 5 seconds
> + one every 10
> + one every 15
> + IDLE
>
> It exits when one notices it has gone over 30 seconds.
>
>
Thank you Joel! I have another question if you don't mind where i can find
the realview_pbx_a9_qemu.exp file?
I can't find it in dejagnu/boards directory

-- 

Aurelio Remonda

Software Engineer
San Lorenzo 47, 3rd Floor, Office 5
Córdoba, Argentina
*Phone:* +54-351-4217888 / 4218211
 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re:[PATCH] [RTEMS] Update RTEMS thread model

2015-09-11 Thread Aurelio Remonda 
> The test runners are in "sim-scripts" make sure a "realview_pbx_a9_qemu
> -i ticker.exe" produces the expected output.

Hi, silly question here, running ticker gave me the elapsed times
but not in 'real time'. It prints 09:00:00, 09:00:04,..., 09:00:34 immediately. 
Is this a normal behaviour for this test in this BSP?
Thanks in advance
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] [RTEMS] Update RTEMS thread model

2015-09-04 Thread Joel Sherrill 



On 9/4/2015 1:53 AM, Sebastian Huber wrote:

On 03/09/15 15:47, Martin Galvan wrote:

Hi Sebastian! Thanks for your answer. There are a couple of things I
still don't get :)

On Thu, Sep 3, 2015 at 2:48 AM, Sebastian Huber
 wrote:

I updated the rtems-testing repository.

1. You have to adjust the VERSIONS file.

Is this file meant to help the scripts download the tool sources
automatically (like RSB does), or does it just point to local
directories where I'm supposed to place them? If it downloads them
automatically, should I replace 'cvs' by 'git' for e.g. gdb?


GDB is managed by git and for GCC I would use the git mirror.


The intention of these scripts is to test some arbitrary version
of the tools that you have locally manually fetched, patched,
symlinked newlib under gcc, etc.

There are a lot of things which have to be correct to be able
to run the tests and this just tries to make it easier.


2. You need the latest Git versions of Newlib, GCC and RTEMS.

So I should manually build a cross-gcc from the gcc trunk? I think
that's past 5.2, will RTEMS build ok with that?

Also, should I apply the patch you posted here:

https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00019.html

?


No patches, just the latest versions, so GCC 6.0.


I would say this is the normal usage. Verify master is OK.

Sebastian .. are you mailing your results to the gcc testresults list?


3. Use

./do_one -1 -r -g -v -M arm realview_pbx_a9_qemu

to run the GCC tests. Make sure the test runner "realview_pbx_a9_qemu"
works.

How can I test that? Should I build the realview_pbx_a9 BSP and run a
sample (e.g. ticker) on the latest Qemu?


The test runners are in "sim-scripts" make sure a "realview_pbx_a9_qemu
-i ticker.exe" produces the expected output.


+1

If it doesn't, you will waste a lot of time for something very
fundamentally broken.


4. Use something similar

cd gcc/b-arm-gcc/arm-rtems4.11/libstdc++-v3/testsuite
make check 'RUNTESTFLAGS=  SIM=realview_pbx_a9_qemu
RTEMS_MAKEFILE_PATH=/scratch/git-rtems-testing/gcc/install-git/arm-rtems4.11/realview_pbx_a9_qemu
RTEMS_CONFIG_OBJ=/scratch/git-rtems-testing/gcc/b-arm-gcc/rtems_gcc_main.o
--target_board=rtems-arm-realview_pbx_a9_qemu{-march=armv7-a/-mthumb/-mfpu=neon/-mfloat-abi=hard}'

to run the libstdc++ tests.

Where does the /git-rtems-testing/gcc/install-git directory? I didn't
see an 'install-git' dir inside rtems-testing/gcc. Is it created after
doing make install on rtems-testing?


I don't remember. I set this up several months ago and now it just works.


In the VERSIONS file, the install prefix is determined by the gcc version
being tested. If you were testing the 4.9 branch, you likely would want
an install directory with 4.9 in the name.

I think I have some local hacks on my VERSIONS file since switching
branches in a single git clone is much simpler than having multiple
SVN checkouts for branches with the branch in the name of the checked
out directory. It used to assume that the GCC branch name was part
of the gcc SVN checkout directory and install directory. With git,
you can't do that.

And making sure your various tools are on the branches you want to
test is up to you. That is really beyond the scope of the tool.

This was not intended to be idiot proof as much as automate the
tedious and fragile build/testing process of the tools.

It can email the results if you like.
 


--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] [RTEMS] Update RTEMS thread model

2015-09-04 Thread Martin Galvan 
Thanks a lot for the detailed answer! We'll give it a try.

Btw:

On Fri, Sep 4, 2015 at 11:40 AM, Joel Sherrill
 wrote:

> It can email the results if you like.

Was that an 'it' or an 'I'? If you have the output of the failed
25_algorithms/random_shuffle/moveable.cc test handy it would
definitely make our lives easier :)
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] [RTEMS] Update RTEMS thread model

2015-09-04 Thread Sebastian Huber 

On 03/09/15 15:47, Martin Galvan wrote:

Hi Sebastian! Thanks for your answer. There are a couple of things I
still don't get :)

On Thu, Sep 3, 2015 at 2:48 AM, Sebastian Huber
 wrote:

I updated the rtems-testing repository.

1. You have to adjust the VERSIONS file.

Is this file meant to help the scripts download the tool sources
automatically (like RSB does), or does it just point to local
directories where I'm supposed to place them? If it downloads them
automatically, should I replace 'cvs' by 'git' for e.g. gdb?


GDB is managed by git and for GCC I would use the git mirror.




2. You need the latest Git versions of Newlib, GCC and RTEMS.

So I should manually build a cross-gcc from the gcc trunk? I think
that's past 5.2, will RTEMS build ok with that?

Also, should I apply the patch you posted here:

https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00019.html

?


No patches, just the latest versions, so GCC 6.0.




3. Use

./do_one -1 -r -g -v -M arm realview_pbx_a9_qemu

to run the GCC tests. Make sure the test runner "realview_pbx_a9_qemu"
works.

How can I test that? Should I build the realview_pbx_a9 BSP and run a
sample (e.g. ticker) on the latest Qemu?


The test runners are in "sim-scripts" make sure a "realview_pbx_a9_qemu 
-i ticker.exe" produces the expected output.





4. Use something similar

cd gcc/b-arm-gcc/arm-rtems4.11/libstdc++-v3/testsuite
make check 'RUNTESTFLAGS=  SIM=realview_pbx_a9_qemu
RTEMS_MAKEFILE_PATH=/scratch/git-rtems-testing/gcc/install-git/arm-rtems4.11/realview_pbx_a9_qemu
RTEMS_CONFIG_OBJ=/scratch/git-rtems-testing/gcc/b-arm-gcc/rtems_gcc_main.o
--target_board=rtems-arm-realview_pbx_a9_qemu{-march=armv7-a/-mthumb/-mfpu=neon/-mfloat-abi=hard}'

to run the libstdc++ tests.

Where does the /git-rtems-testing/gcc/install-git directory? I didn't
see an 'install-git' dir inside rtems-testing/gcc. Is it created after
doing make install on rtems-testing?


I don't remember. I set this up several months ago and now it just works.

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] [RTEMS] Update RTEMS thread model

2015-09-03 Thread Martin Galvan 
Hi Sebastian! Thanks for your answer. There are a couple of things I
still don't get :)

On Thu, Sep 3, 2015 at 2:48 AM, Sebastian Huber
 wrote:
> I updated the rtems-testing repository.
>
> 1. You have to adjust the VERSIONS file.

Is this file meant to help the scripts download the tool sources
automatically (like RSB does), or does it just point to local
directories where I'm supposed to place them? If it downloads them
automatically, should I replace 'cvs' by 'git' for e.g. gdb?

> 2. You need the latest Git versions of Newlib, GCC and RTEMS.

So I should manually build a cross-gcc from the gcc trunk? I think
that's past 5.2, will RTEMS build ok with that?

Also, should I apply the patch you posted here:

https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00019.html

?

> 3. Use
>
> ./do_one -1 -r -g -v -M arm realview_pbx_a9_qemu
>
> to run the GCC tests. Make sure the test runner "realview_pbx_a9_qemu"
> works.

How can I test that? Should I build the realview_pbx_a9 BSP and run a
sample (e.g. ticker) on the latest Qemu?

> 4. Use something similar
>
> cd gcc/b-arm-gcc/arm-rtems4.11/libstdc++-v3/testsuite
> make check 'RUNTESTFLAGS=  SIM=realview_pbx_a9_qemu
> RTEMS_MAKEFILE_PATH=/scratch/git-rtems-testing/gcc/install-git/arm-rtems4.11/realview_pbx_a9_qemu
> RTEMS_CONFIG_OBJ=/scratch/git-rtems-testing/gcc/b-arm-gcc/rtems_gcc_main.o
> --target_board=rtems-arm-realview_pbx_a9_qemu{-march=armv7-a/-mthumb/-mfpu=neon/-mfloat-abi=hard}'
>
> to run the libstdc++ tests.

Where does the /git-rtems-testing/gcc/install-git directory? I didn't
see an 'install-git' dir inside rtems-testing/gcc. Is it created after
doing make install on rtems-testing?

Thanks a lot.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] [RTEMS] Update RTEMS thread model

2015-09-02 Thread Sebastian Huber 



On 01/09/15 13:05, Sebastian Huber wrote:

On 01/09/15 12:10, Sebastian Huber wrote:
Shared mutexes are not implemented in general. 


This works now also:

https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00027.html



With this additional fix:

https://gcc.gnu.org/ml/gcc/2015-09/msg00021.html

We have these results:

Target is arm-unknown-rtems4.11
Host   is arm-unknown-rtems4.11
Build  is x86_64-pc-linux-gnu

=== libstdc++ tests ===

Schedule of variations:
rtems-arm-realview_pbx_a9_qemu/-march=armv7-a/-mthumb/-mfpu=neon/-mfloat-abi=hard

Running target 
rtems-arm-realview_pbx_a9_qemu/-march=armv7-a/-mthumb/-mfpu=neon/-mfloat-abi=hard
Using 
/scratch/git-rtems-testing/dejagnu/boards/rtems-arm-realview_pbx_a9_qemu.exp 
as board description file for target.
Using /usr/share/dejagnu/config/sim.exp as generic interface file for 
target.
Using /usr/share/dejagnu/baseboards/basic-sim.exp as board description 
file for target.
Using 
/home/EB/sebastian_h/archive/gcc-git/libstdc++-v3/testsuite/config/default.exp 
as tool-and-target-specific interface file.
Running 
/home/EB/sebastian_h/archive/gcc-git/libstdc++-v3/testsuite/libstdc++-abi/abi.exp 
...
Running 
/home/EB/sebastian_h/archive/gcc-git/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp 
...

FAIL: 25_algorithms/copy/streambuf_iterators/wchar_t/4.cc execution test
FAIL: 25_algorithms/find/istreambuf_iterators/wchar_t/2.cc execution test
FAIL: 25_algorithms/random_shuffle/moveable.cc execution test
FAIL: 27_io/basic_istream/extractors_other/wchar_t/2.cc execution test
FAIL: 27_io/basic_istream/get/wchar_t/2.cc execution test
FAIL: 27_io/basic_istream/ignore/wchar_t/3.cc execution test
FAIL: 27_io/basic_istream/seekg/wchar_t/sstream.cc execution test
FAIL: 27_io/basic_istream/tellg/wchar_t/sstream.cc execution test
FAIL: 27_io/basic_ostream/inserters_other/wchar_t/1.cc execution test
FAIL: 27_io/basic_stringbuf/setbuf/char/4.cc execution test
FAIL: 27_io/objects/wchar_t/12048-1.cc execution test
FAIL: 27_io/objects/wchar_t/12048-2.cc execution test
FAIL: 27_io/objects/wchar_t/12048-3.cc execution test
FAIL: 27_io/objects/wchar_t/12048-4.cc execution test
WARNING: program timed out.
FAIL: 30_threads/async/42819.cc execution test
WARNING: program timed out.
FAIL: 30_threads/async/49668.cc execution test
WARNING: program timed out.
FAIL: 30_threads/async/any.cc execution test
WARNING: program timed out.
FAIL: 30_threads/async/async.cc execution test
WARNING: program timed out.
FAIL: 30_threads/condition_variable/members/3.cc execution test
FAIL: 30_threads/shared_timed_mutex/try_lock/3.cc execution test
WARNING: program timed out.
FAIL: 30_threads/thread/native_handle/cancel.cc execution test
FAIL: 30_threads/timed_mutex/try_lock_until/57641.cc execution test
FAIL: tr1/8_c_compatibility/complex/50880.cc (test for excess errors)
WARNING: tr1/8_c_compatibility/complex/50880.cc compilation failed to 
produce executable

FAIL: tr1/8_c_compatibility/complex/functions.cc (test for excess errors)
Running 
/home/EB/sebastian_h/archive/gcc-git/libstdc++-v3/testsuite/libstdc++-prettyprinters/prettyprinters.exp 
...
Running 
/home/EB/sebastian_h/archive/gcc-git/libstdc++-v3/testsuite/libstdc++-xmethods/xmethods.exp 
...


=== libstdc++ Summary ===

# of expected passes9029
# of unexpected failures24
# of expected failures  65
# of unsupported tests  726

Biggest issue: the thread cancel/exit problems. Since this is not an 
issue with the thread model, I will commit the patch tomorrow if nobody 
objects.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] [RTEMS] Update RTEMS thread model

2015-09-02 Thread Sebastian Huber 



On 02/09/15 02:50, Chris Johns wrote:

On 1/09/2015 8:52 pm, Daniel Gutson wrote:

>
>El 31/7/2015 3:28, "Chris Johns" > escribió:

>>
>>On 31/07/2015 4:11 pm, Sebastian Huber wrote:

>> >For synchronization objects use the self-contained objects available via
>> >Newlib .
>> >
>> >

>https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=commit;h=ecaef05f6601f1e8acb78fb65b411a258f39988a

>> >
>> >Enable the C++11 threads using .  So, the threads are only
>> >supported in case the POSIX API is enabled in RTEMS.  In the long run
>> >support for thread join and detach should be added to the API
>> >independent RTEMS services.
>> >

>>
>>Is this for 4.12 ?
>>
>>What happens if I build RTEMS with --disable-posix ? If I use locale in
>>C++ it pulls in the 'once' support which pulls in this file which would
>>give unresolved externals. There is a PR against me for libstdc++ not
>>checking the return code. Is it time for the --enable-posix option to go
>>and to always nave it enabled ?

>
>Please don't. The POSIX layer takes valuable resurces and it is not
>always needed.
>

Maybe we should look into this and fix the reasons. Any code not
required should not be included. This is an on going effort in RTEMS and
it requires we expose the cases.


We have all the infrastructure to fix this. One part is

CFLAGS += -ffunction-sections -fdata-sections
LDFLAGS += -Wl,--gc-sections

The other part a linker set based initialization (fully implemented in 
libbsd). One issue is that we have to add support for this in all linker 
command files. So we need just someone who has time to do this.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] [RTEMS] Update RTEMS thread model

2015-09-02 Thread Sebastian Huber 

Committed:

https://gcc.gnu.org/viewcvs/gcc?view=revision=227428

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] [RTEMS] Update RTEMS thread model

2015-09-02 Thread Daniel Gutson 
El 2/9/2015 5:28, "Sebastian Huber" 
escribió:
>
>
>
> On 02/09/15 02:50, Chris Johns wrote:
>>
>> On 1/09/2015 8:52 pm, Daniel Gutson wrote:
>>>
>>> >
>>> >El 31/7/2015 3:28, "Chris Johns" >> >> escribió:

 >>
 >>On 31/07/2015 4:11 pm, Sebastian Huber wrote:
>
> >> >For synchronization objects use the self-contained objects
available via
> >> >Newlib .
> >> >
> >> >
>>>
>>> >
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=commit;h=ecaef05f6601f1e8acb78fb65b411a258f39988a
>
> >> >
> >> >Enable the C++11 threads using .  So, the threads are
only
> >> >supported in case the POSIX API is enabled in RTEMS.  In the long
run
> >> >support for thread join and detach should be added to the API
> >> >independent RTEMS services.
> >> >

 >>
 >>Is this for 4.12 ?
 >>
 >>What happens if I build RTEMS with --disable-posix ? If I use locale
in
 >>C++ it pulls in the 'once' support which pulls in this file which
would
 >>give unresolved externals. There is a PR against me for libstdc++ not
 >>checking the return code. Is it time for the --enable-posix option
to go
 >>and to always nave it enabled ?
>>>
>>> >
>>> >Please don't. The POSIX layer takes valuable resurces and it is not
>>> >always needed.
>>> >
>>
>> Maybe we should look into this and fix the reasons. Any code not
>> required should not be included. This is an on going effort in RTEMS and
>> it requires we expose the cases.
>
>
> We have all the infrastructure to fix this. One part is
>
> CFLAGS += -ffunction-sections -fdata-sections
> LDFLAGS += -Wl,--gc-sections
>
> The other part a linker set based initialization (fully implemented in
libbsd). One issue is that we have to add support for this in all linker
command files. So we need just someone who has time to do this.

Could you please create a ticket for this dumping all the useful
informatiom you have in your head there :) since we are interested so we'll
likely do it, and any further question can be discussed in the ticket.

>
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] [RTEMS] Update RTEMS thread model

2015-09-02 Thread Daniel Gutson 
El 2/9/2015 5:17, "Sebastian Huber" 
escribió:
>
>
>
> On 01/09/15 13:05, Sebastian Huber wrote:
>>
>> On 01/09/15 12:10, Sebastian Huber wrote:
>>>
>>> Shared mutexes are not implemented in general.
>>
>>
>> This works now also:
>>
>> https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00027.html
>>
>
> With this additional fix:
>
> https://gcc.gnu.org/ml/gcc/2015-09/msg00021.html
>
> We have these results:
>
>
> Target is arm-unknown-rtems4.11
> Host   is arm-unknown-rtems4.11
> Build  is x86_64-pc-linux-gnu
>
> === libstdc++ tests ===
>
> Schedule of variations:
>
rtems-arm-realview_pbx_a9_qemu/-march=armv7-a/-mthumb/-mfpu=neon/-mfloat-abi=hard
>
> Running target
rtems-arm-realview_pbx_a9_qemu/-march=armv7-a/-mthumb/-mfpu=neon/-mfloat-abi=hard
>
> Using
/scratch/git-rtems-testing/dejagnu/boards/rtems-arm-realview_pbx_a9_qemu.exp
as board description file for target.
> Using /usr/share/dejagnu/config/sim.exp as generic interface file for
target.
> Using /usr/share/dejagnu/baseboards/basic-sim.exp as board description
file for target.
> Using
/home/EB/sebastian_h/archive/gcc-git/libstdc++-v3/testsuite/config/default.exp
as tool-and-target-specific interface file.
> Running
/home/EB/sebastian_h/archive/gcc-git/libstdc++-v3/testsuite/libstdc++-abi/abi.exp
...
> Running
/home/EB/sebastian_h/archive/gcc-git/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp
...
> FAIL: 25_algorithms/copy/streambuf_iterators/wchar_t/4.cc execution test
> FAIL: 25_algorithms/find/istreambuf_iterators/wchar_t/2.cc execution test
> FAIL: 25_algorithms/random_shuffle/moveable.cc execution test

I'm very interested in this last one. Is this an XFail? Could you please
post both the dejagnu test and the output?
We use move semantics everywhere and I'd want to be sure it's working OK.
Specially since this doesn't seem to be related to concurrency but just
algorithms.

Thanks,

Daniel.

> FAIL: 27_io/basic_istream/extractors_other/wchar_t/2.cc execution test
> FAIL: 27_io/basic_istream/get/wchar_t/2.cc execution test
> FAIL: 27_io/basic_istream/ignore/wchar_t/3.cc execution test
> FAIL: 27_io/basic_istream/seekg/wchar_t/sstream.cc execution test
> FAIL: 27_io/basic_istream/tellg/wchar_t/sstream.cc execution test
> FAIL: 27_io/basic_ostream/inserters_other/wchar_t/1.cc execution test
> FAIL: 27_io/basic_stringbuf/setbuf/char/4.cc execution test
> FAIL: 27_io/objects/wchar_t/12048-1.cc execution test
> FAIL: 27_io/objects/wchar_t/12048-2.cc execution test
> FAIL: 27_io/objects/wchar_t/12048-3.cc execution test
> FAIL: 27_io/objects/wchar_t/12048-4.cc execution test
> WARNING: program timed out.
> FAIL: 30_threads/async/42819.cc execution test
> WARNING: program timed out.
> FAIL: 30_threads/async/49668.cc execution test
> WARNING: program timed out.
> FAIL: 30_threads/async/any.cc execution test
> WARNING: program timed out.
> FAIL: 30_threads/async/async.cc execution test
>
> WARNING: program timed out.
> FAIL: 30_threads/condition_variable/members/3.cc execution test
> FAIL: 30_threads/shared_timed_mutex/try_lock/3.cc execution test
> WARNING: program timed out.
> FAIL: 30_threads/thread/native_handle/cancel.cc execution test
> FAIL: 30_threads/timed_mutex/try_lock_until/57641.cc execution test
> FAIL: tr1/8_c_compatibility/complex/50880.cc (test for excess errors)
> WARNING: tr1/8_c_compatibility/complex/50880.cc compilation failed to
produce executable
> FAIL: tr1/8_c_compatibility/complex/functions.cc (test for excess errors)
> Running
/home/EB/sebastian_h/archive/gcc-git/libstdc++-v3/testsuite/libstdc++-prettyprinters/prettyprinters.exp
...
> Running
/home/EB/sebastian_h/archive/gcc-git/libstdc++-v3/testsuite/libstdc++-xmethods/xmethods.exp
...
>
> === libstdc++ Summary ===
>
> # of expected passes9029
> # of unexpected failures24
>
> # of expected failures  65
> # of unsupported tests  726
>
> Biggest issue: the thread cancel/exit problems. Since this is not an
issue with the thread model, I will commit the patch tomorrow if nobody
objects.
>
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] [RTEMS] Update RTEMS thread model

2015-09-02 Thread Sebastian Huber 



On 02/09/15 13:27, Daniel Gutson wrote:



El 2/9/2015 5:17, "Sebastian Huber" 
> escribió:

>
>
>
> On 01/09/15 13:05, Sebastian Huber wrote:
>>
>> On 01/09/15 12:10, Sebastian Huber wrote:
>>>
>>> Shared mutexes are not implemented in general.
>>
>>
>> This works now also:
>>
>> https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00027.html
>>
>
> With this additional fix:
>
> https://gcc.gnu.org/ml/gcc/2015-09/msg00021.html
>
> We have these results:
>
>
> Target is arm-unknown-rtems4.11
> Host   is arm-unknown-rtems4.11
> Build  is x86_64-pc-linux-gnu
>
> === libstdc++ tests ===
>
> Schedule of variations:
> 
rtems-arm-realview_pbx_a9_qemu/-march=armv7-a/-mthumb/-mfpu=neon/-mfloat-abi=hard

>
> Running target 
rtems-arm-realview_pbx_a9_qemu/-march=armv7-a/-mthumb/-mfpu=neon/-mfloat-abi=hard

>
> Using 
/scratch/git-rtems-testing/dejagnu/boards/rtems-arm-realview_pbx_a9_qemu.exp 
as board description file for target.
> Using /usr/share/dejagnu/config/sim.exp as generic interface file 
for target.
> Using /usr/share/dejagnu/baseboards/basic-sim.exp as board 
description file for target.
> Using 
/home/EB/sebastian_h/archive/gcc-git/libstdc++-v3/testsuite/config/default.exp 
as tool-and-target-specific interface file.
> Running 
/home/EB/sebastian_h/archive/gcc-git/libstdc++-v3/testsuite/libstdc++-abi/abi.exp 
...
> Running 
/home/EB/sebastian_h/archive/gcc-git/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp 
...

> FAIL: 25_algorithms/copy/streambuf_iterators/wchar_t/4.cc execution test
> FAIL: 25_algorithms/find/istreambuf_iterators/wchar_t/2.cc execution 
test

> FAIL: 25_algorithms/random_shuffle/moveable.cc execution test

I'm very interested in this last one. Is this an XFail? Could you 
please post both the dejagnu test and the output?
We use move semantics everywhere and I'd want to be sure it's working 
OK. Specially since this doesn't seem to be related to concurrency but 
just algorithms.




I deleted the test tree. It will take a couple of days before I create a 
new one. I think it makes more sense if you run the tests yourself, so 
that you can debug them. I use the realview_pbx_a9_qemu BSP for this, 
since it is very easy to debug.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] [RTEMS] Update RTEMS thread model

2015-09-02 Thread Sebastian Huber 



On 02/09/15 13:32, Daniel Gutson wrote:



El 2/9/2015 5:28, "Sebastian Huber" 
> escribió:

>
>
>
> On 02/09/15 02:50, Chris Johns wrote:
>>
>> On 1/09/2015 8:52 pm, Daniel Gutson wrote:
>>>
>>> >
>>> >El 31/7/2015 3:28, "Chris Johns" 

>>> >>> escribió:

 >>
 >>On 31/07/2015 4:11 pm, Sebastian Huber wrote:
>
> >> >For synchronization objects use the self-contained objects 
available via

> >> >Newlib .
> >> >
> >> >
>>>
>>> 
>https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=commit;h=ecaef05f6601f1e8acb78fb65b411a258f39988a

>
> >> >
> >> >Enable the C++11 threads using .  So, the threads 
are only
> >> >supported in case the POSIX API is enabled in RTEMS.  In the 
long run

> >> >support for thread join and detach should be added to the API
> >> >independent RTEMS services.
> >> >

 >>
 >>Is this for 4.12 ?
 >>
 >>What happens if I build RTEMS with --disable-posix ? If I use 
locale in
 >>C++ it pulls in the 'once' support which pulls in this file 
which would
 >>give unresolved externals. There is a PR against me for 
libstdc++ not
 >>checking the return code. Is it time for the --enable-posix 
option to go

 >>and to always nave it enabled ?
>>>
>>> >
>>> >Please don't. The POSIX layer takes valuable resurces and it is not
>>> >always needed.
>>> >
>>
>> Maybe we should look into this and fix the reasons. Any code not
>> required should not be included. This is an on going effort in 
RTEMS and

>> it requires we expose the cases.
>
>
> We have all the infrastructure to fix this. One part is
>
> CFLAGS += -ffunction-sections -fdata-sections
> LDFLAGS += -Wl,--gc-sections
>
> The other part a linker set based initialization (fully implemented 
in libbsd). One issue is that we have to add support for this in all 
linker command files. So we need just someone who has time to do this.


Could you please create a ticket for this dumping all the useful 
informatiom you have in your head there :) since we are interested so 
we'll likely do it, and any further question can be discussed in the 
ticket.




https://devel.rtems.org/ticket/2407
https://devel.rtems.org/ticket/2408

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] [RTEMS] Update RTEMS thread model

2015-09-02 Thread Martin Galvan 
On Wed, Sep 2, 2015 at 12:01 PM, Daniel Gutson
 wrote:
>
> El 2/9/2015 11:58, "Martin Galvan" 
> escribió:
>>
>> On 02/09/2015 15:00, Sebastian Huber wrote:
>> > I deleted the test tree. It will take a couple of days before I create a
>> > new one. I think it makes more sense if you run the tests yourself, so
>> > that you can debug them. I use the realview_pbx_a9_qemu BSP for this,
>> > since it is very easy to debug.
>>
>> Could you please tell us how to run the tests on realview_pbx_a9_qemu?
>> I looked at the READMEs in rtems-testing, but they seem to be quite out of
>> date.
>
> I assume this is not 'make test', right?

It's probably make test, but I'm not sure how to let DejaGNU know I'm
pointing at realview_pbx_a9_qemu :)
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] [RTEMS] Update RTEMS thread model

2015-09-01 Thread Chris Johns 
On 1/09/2015 8:52 pm, Daniel Gutson wrote:
> 
> El 31/7/2015 3:28, "Chris Johns"  > escribió:
>>
>> On 31/07/2015 4:11 pm, Sebastian Huber wrote:
>> > For synchronization objects use the self-contained objects available via
>> > Newlib .
>> >
>> >
> https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=commit;h=ecaef05f6601f1e8acb78fb65b411a258f39988a
>> >
>> > Enable the C++11 threads using .  So, the threads are only
>> > supported in case the POSIX API is enabled in RTEMS.  In the long run
>> > support for thread join and detach should be added to the API
>> > independent RTEMS services.
>> >
>>
>> Is this for 4.12 ?
>>
>> What happens if I build RTEMS with --disable-posix ? If I use locale in
>> C++ it pulls in the 'once' support which pulls in this file which would
>> give unresolved externals. There is a PR against me for libstdc++ not
>> checking the return code. Is it time for the --enable-posix option to go
>> and to always nave it enabled ?
> 
> Please don't. The POSIX layer takes valuable resurces and it is not
> always needed.
> 

Maybe we should look into this and fix the reasons. Any code not
required should not be included. This is an on going effort in RTEMS and
it requires we expose the cases.

Every configure flag in RTEMS at this level increases the build and
testing load. There are real advantages to have a single build and test
cycle for "RTEMS". For resource constrained targets tests that cannot be
run are not supported.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] [RTEMS] Update RTEMS thread model

2015-09-01 Thread Sebastian Huber 



On 31/07/15 09:23, Sebastian Huber wrote:



On 31/07/15 09:10, Chris Johns wrote:

On 31/07/2015 4:44 pm, Sebastian Huber wrote:

>

>>Is this for 4.12 ?

>
>This is just a proof-of-concept patch, but it would be nice to include
>this in the next release along with the C11 threads support.
>

If you have tests and they are ok then why not put it in.



It is thoroughly tested in the libstdc++ test suite, unfortunately we 
have do adjust all test cases since they contain stuff like this:


// { dg-do run { target *-*-freebsd* *-*-dragonfly* *-*-netbsd* 
*-*-linux* *-*-gnu* *-*-solaris* *-*-cygwin *-*-darwin* 
powerpc-ibm-aix* } }
// { dg-options " -std=gnu++11 -pthread" { target *-*-freebsd* 
*-*-dragonfly* *-*-netbsd* *-*-linux* *-*-gnu* powerpc-ibm-aix* } }

// { dg-options " -std=gnu++11 -pthreads" { target *-*-solaris* } }
// { dg-options " -std=gnu++11 " { target *-*-cygwin *-*-darwin* } }
// { dg-require-cstdint "" }
// { dg-require-gthreads "" }

So, there is a target white list.



See also:

https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00019.html

https://devel.rtems.org/ticket/2402
https://devel.rtems.org/ticket/2403

The test results are not that bad. Some tests use files, which are not 
available to the RTEMS test driver. The main issues are due to thread 
cancel/exit misbehaviour of RTEMS. Shared mutexes are not implemented in 
general.


Target is arm-unknown-rtems4.11
Host   is arm-unknown-rtems4.11
Build  is x86_64-pc-linux-gnu

=== libstdc++ tests ===

Schedule of variations:
rtems-arm-realview_pbx_a9_qemu

Running target rtems-arm-realview_pbx_a9_qemu
Using 
/scratch/git-rtems-testing/dejagnu/boards/rtems-arm-realview_pbx_a9_qemu.exp 
as board description file for target.
Using /usr/share/dejagnu/config/sim.exp as generic interface file for 
target.
Using /usr/share/dejagnu/baseboards/basic-sim.exp as board description 
file for target.
Using 
/home/EB/sebastian_h/archive/gcc-git/libstdc++-v3/testsuite/config/default.exp 
as tool-and-target-specific interface file.
Running 
/home/EB/sebastian_h/archive/gcc-git/libstdc++-v3/testsuite/libstdc++-abi/abi.exp 
...
Running 
/home/EB/sebastian_h/archive/gcc-git/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp 
...

FAIL: 25_algorithms/copy/streambuf_iterators/wchar_t/4.cc execution test
FAIL: 25_algorithms/find/istreambuf_iterators/wchar_t/2.cc execution test
FAIL: 25_algorithms/random_shuffle/moveable.cc execution test
FAIL: 27_io/basic_istream/extractors_other/wchar_t/2.cc execution test
FAIL: 27_io/basic_istream/get/wchar_t/2.cc execution test
FAIL: 27_io/basic_istream/ignore/wchar_t/3.cc execution test
FAIL: 27_io/basic_istream/seekg/wchar_t/sstream.cc execution test
FAIL: 27_io/basic_istream/tellg/wchar_t/sstream.cc execution test
FAIL: 27_io/basic_ostream/inserters_other/wchar_t/1.cc execution test
FAIL: 27_io/basic_stringbuf/setbuf/char/4.cc execution test
FAIL: 27_io/objects/wchar_t/12048-1.cc execution test
FAIL: 27_io/objects/wchar_t/12048-2.cc execution test
FAIL: 27_io/objects/wchar_t/12048-3.cc execution test
FAIL: 27_io/objects/wchar_t/12048-4.cc execution test
WARNING: program timed out.
FAIL: 30_threads/condition_variable/members/3.cc execution test
FAIL: 30_threads/shared_mutex/cons/1.cc (test for excess errors)
WARNING: 30_threads/shared_mutex/cons/1.cc compilation failed to produce 
executable

FAIL: 30_threads/shared_mutex/try_lock/1.cc (test for excess errors)
WARNING: 30_threads/shared_mutex/try_lock/1.cc compilation failed to 
produce executable

FAIL: 30_threads/shared_mutex/try_lock/2.cc (test for excess errors)
WARNING: 30_threads/shared_mutex/try_lock/2.cc compilation failed to 
produce executable

FAIL: 30_threads/shared_timed_mutex/try_lock/3.cc execution test
WARNING: program timed out.
FAIL: 30_threads/thread/native_handle/cancel.cc execution test
FAIL: 30_threads/timed_mutex/try_lock_until/57641.cc execution test
FAIL: tr1/8_c_compatibility/complex/50880.cc (test for excess errors)
WARNING: tr1/8_c_compatibility/complex/50880.cc compilation failed to 
produce executable

FAIL: tr1/8_c_compatibility/complex/functions.cc (test for excess errors)
Running 
/home/EB/sebastian_h/archive/gcc-git/libstdc++-v3/testsuite/libstdc++-prettyprinters/prettyprinters.exp 
...
Running 
/home/EB/sebastian_h/archive/gcc-git/libstdc++-v3/testsuite/libstdc++-xmethods/xmethods.exp 
...


=== libstdc++ Summary ===

# of expected passes8807
# of unexpected failures23
# of expected failures  65
# of unsupported tests  843

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] [RTEMS] Update RTEMS thread model

2015-09-01 Thread Daniel Gutson 
El 31/7/2015 3:28, "Chris Johns"  escribió:
>
> On 31/07/2015 4:11 pm, Sebastian Huber wrote:
> > For synchronization objects use the self-contained objects available via
> > Newlib .
> >
> >
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=commit;h=ecaef05f6601f1e8acb78fb65b411a258f39988a
> >
> > Enable the C++11 threads using .  So, the threads are only
> > supported in case the POSIX API is enabled in RTEMS.  In the long run
> > support for thread join and detach should be added to the API
> > independent RTEMS services.
> >
>
> Is this for 4.12 ?
>
> What happens if I build RTEMS with --disable-posix ? If I use locale in
> C++ it pulls in the 'once' support which pulls in this file which would
> give unresolved externals. There is a PR against me for libstdc++ not
> checking the return code. Is it time for the --enable-posix option to go
> and to always nave it enabled ?

Please don't. The POSIX layer takes valuable resurces and it is not always
needed.

>
> I feel 'tiny' support should be by not linking rather than configure
magic.
>
> Chris
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] [RTEMS] Update RTEMS thread model

2015-09-01 Thread Sebastian Huber 
For synchronization objects use the self-contained objects available via
Newlib .

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=commit;h=ecaef05f6601f1e8acb78fb65b411a258f39988a

Enable the C++11 threads using .  So, the threads are only
supported in case the POSIX API is enabled in RTEMS.  In the long run
support for thread join and detach should be added to the API
independent RTEMS services.

libgcc/ChangeLog
2015-09-01  Sebastian Huber  

* config/gthr-rtems.h (__GTHREADS_CXX0X): New.
(__GTHREAD_HAS_COND): Likewise.
(__gthread_t): Likewise.
(__gthread_cond_t): Likewise.
(__gthread_time_t): Likewise.
(__GTHREAD_MUTEX_INIT): Likewise.
(__GTHREAD_RECURSIVE_MUTEX_INIT): Likewise.
(__GTHREAD_COND_INIT): Likewise.
(__GTHREAD_COND_INIT_FUNCTION): Likewise.
(__GTHREAD_TIME_INIT): Likewise.
(__gthread_create): Likewise.
(__gthread_join): Likewise.
(__gthread_detach): Likewise.
(__gthread_equal): Likewise.
(__gthread_self): Likewise.
(__gthread_yield): Likewise.
(__gthread_cond_broadcast): Likewise.
(__gthread_cond_signal): Likewise.
(__gthread_cond_wait): Likewise.
(__gthread_cond_timedwait): Likewise.
(__gthread_cond_wait_recursive): Likewise.
(__gthread_cond_destroy): Likewise.
(rtems_gxx_once): Delete.
(rtems_gxx_key_create): Likewise.
(rtems_gxx_key_delete): Likewise.
(rtems_gxx_getspecific): Likewise.
(rtems_gxx_setspecific): Likewise.
(rtems_gxx_mutex_init): Likewise.
(rtems_gxx_mutex_destroy): Likewise.
(rtems_gxx_mutex_lock): Likewise.
(rtems_gxx_mutex_trylock): Likewise.
(rtems_gxx_mutex_unlock): Likewise.
(rtems_gxx_recursive_mutex_init): Likewise.
(rtems_gxx_recursive_mutex_lock): Likewise.
(rtems_gxx_recursive_mutex_trylock): Likewise.
(rtems_gxx_recursive_mutex_unlock): Likewise.
(__GTHREAD_ONCE_INIT): Use  initializer.
(__GTHREAD_MUTEX_INIT_FUNCTION): Use  function.
(__GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION): Likewise.
(__gthread_once): Likewise.
(__gthread_key_create): Likewise.
(__gthread_key_delete): Likewise.
(__gthread_getspecific): Likewise.
(__gthread_setspecific): Likewise.
(__gthread_key_t): Use  type.
(__gthread_once_t): Likewise
(__gthread_mutex_t): Use  type.
(__gthread_recursive_mutex_t): Likewise
(__gthread_mutex_lock): Use  function.
(__gthread_mutex_trylock): Likewise.
(__gthread_mutex_timedlock): Likewise.
(__gthread_mutex_unlock): Likewise.
(__gthread_mutex_destroy): Likewise.
(__gthread_recursive_mutex_lock): Likewise.
(__gthread_recursive_mutex_trylock): Likewise.
(__gthread_recursive_mutex_timedlock): Likewise.
(__gthread_recursive_mutex_unlock): Likewise.
(__gthread_recursive_mutex_destroy): Likewise.
---
 libgcc/config/gthr-rtems.h | 195 -
 1 file changed, 139 insertions(+), 56 deletions(-)

diff --git a/libgcc/config/gthr-rtems.h b/libgcc/config/gthr-rtems.h
index 23038c6..1aff329 100644
--- a/libgcc/config/gthr-rtems.h
+++ b/libgcc/config/gthr-rtems.h
@@ -27,134 +27,217 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  
If not, see
 #ifndef GCC_GTHR_RTEMS_H
 #define GCC_GTHR_RTEMS_H
 
+#include 
+#include 
+#include 
+
 #ifdef __cplusplus
 extern "C" {
 #endif
 
 #define __GTHREADS 1
+#define __GTHREADS_CXX0X 1
+#define __GTHREAD_HAS_COND 1
+
+typedef pthread_t __gthread_t;
+typedef pthread_key_t __gthread_key_t;
+typedef pthread_once_t __gthread_once_t;
+typedef struct _Mutex_Control __gthread_mutex_t;
+typedef struct _Mutex_recursive_Control __gthread_recursive_mutex_t;
+typedef struct _Condition_Control __gthread_cond_t;
+typedef struct timespec __gthread_time_t;
+
+#define __GTHREAD_ONCE_INIT PTHREAD_ONCE_INIT
+#define __GTHREAD_MUTEX_INIT _MUTEX_INITIALIZER
+#define __GTHREAD_MUTEX_INIT_FUNCTION _Mutex_Initialize
+#define __GTHREAD_RECURSIVE_MUTEX_INIT _MUTEX_RECURSIVE_INITIALIZER
+#define __GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION _Mutex_recursive_Initialize
+#define __GTHREAD_COND_INIT _CONDITION_INITIALIZER
+#define __GTHREAD_COND_INIT_FUNCTION _Condition_Initialize
+#define __GTHREAD_TIME_INIT {0, 0}
 
-#define __GTHREAD_ONCE_INIT  0
-#define __GTHREAD_MUTEX_INIT_FUNCTION  rtems_gxx_mutex_init
-#define __GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION  rtems_gxx_recursive_mutex_init
-
-/* Avoid dependency on rtems specific headers.  */
-typedef void *__gthread_key_t;
-typedef int   __gthread_once_t;
-typedef void *__gthread_mutex_t;
-typedef void *__gthread_recursive_mutex_t;
-
-/*
- * External functions provided by RTEMS. They are very similar to their POSIX
- * counterparts. A "Wrapper API" is being use to avoid

Re: [PATCH] [RTEMS] Update RTEMS thread model

2015-09-01 Thread Sebastian Huber 

On 01/09/15 12:10, Sebastian Huber wrote:
Shared mutexes are not implemented in general. 


This works now also:

https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00027.html

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] [RTEMS] Update RTEMS thread model

2015-07-31 Thread Sebastian Huber 
For synchronization objects use the self-contained objects available via
Newlib sys/lock.h.

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=commit;h=ecaef05f6601f1e8acb78fb65b411a258f39988a

Enable the C++11 threads using pthread.h.  So, the threads are only
supported in case the POSIX API is enabled in RTEMS.  In the long run
support for thread join and detach should be added to the API
independent RTEMS services.

libgcc/ChangeLog
2015-07-31  Sebastian Huber  sebastian.hu...@embedded-brains.de

* config/gthr-rtems.h (__GTHREADS_CXX0X): New.
(__GTHREAD_HAS_COND): Likewise.
(__gthread_t): Likewise.
(__gthread_cond_t): Likewise.
(__gthread_time_t): Likewise.
(__GTHREAD_MUTEX_INIT): Likewise.
(__GTHREAD_RECURSIVE_MUTEX_INIT): Likewise.
(__GTHREAD_COND_INIT): Likewise.
(__GTHREAD_COND_INIT_FUNCTION): Likewise.
(__GTHREAD_TIME_INIT): Likewise.
(__gthread_create): Likewise.
(__gthread_join): Likewise.
(__gthread_detach): Likewise.
(__gthread_equal): Likewise.
(__gthread_self): Likewise.
(__gthread_yield): Likewise.
(__gthread_cond_broadcast): Likewise.
(__gthread_cond_signal): Likewise.
(__gthread_cond_wait): Likewise.
(__gthread_cond_timedwait): Likewise.
(__gthread_cond_wait_recursive): Likewise.
(__gthread_cond_destroy): Likewise.
(rtems_gxx_once): Delete.
(rtems_gxx_key_create): Likewise.
(rtems_gxx_key_delete): Likewise.
(rtems_gxx_getspecific): Likewise.
(rtems_gxx_setspecific): Likewise.
(rtems_gxx_mutex_init): Likewise.
(rtems_gxx_mutex_destroy): Likewise.
(rtems_gxx_mutex_lock): Likewise.
(rtems_gxx_mutex_trylock): Likewise.
(rtems_gxx_mutex_unlock): Likewise.
(rtems_gxx_recursive_mutex_init): Likewise.
(rtems_gxx_recursive_mutex_lock): Likewise.
(rtems_gxx_recursive_mutex_trylock): Likewise.
(rtems_gxx_recursive_mutex_unlock): Likewise.
(__GTHREAD_ONCE_INIT): Use pthread.h initializer.
(__GTHREAD_MUTEX_INIT_FUNCTION): Use pthread.h function.
(__GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION): Likewise.
(__gthread_once): Likewise.
(__gthread_key_create): Likewise.
(__gthread_key_delete): Likewise.
(__gthread_getspecific): Likewise.
(__gthread_setspecific): Likewise.
(__gthread_key_t): Use pthread.h type.
(__gthread_once_t): Likewise
(__gthread_mutex_t): Use sys/lock.h type.
(__gthread_recursive_mutex_t): Likewise
(__gthread_mutex_lock): Use sys/lock.h function.
(__gthread_mutex_trylock): Likewise.
(__gthread_mutex_timedlock): Likewise.
(__gthread_mutex_unlock): Likewise.
(__gthread_mutex_destroy): Likewise.
(__gthread_recursive_mutex_lock): Likewise.
(__gthread_recursive_mutex_trylock): Likewise.
(__gthread_recursive_mutex_timedlock): Likewise.
(__gthread_recursive_mutex_unlock): Likewise.
(__gthread_recursive_mutex_destroy): Likewise.
---
 libgcc/config/gthr-rtems.h | 195 -
 1 file changed, 139 insertions(+), 56 deletions(-)

diff --git a/libgcc/config/gthr-rtems.h b/libgcc/config/gthr-rtems.h
index 23038c6..1aff329 100644
--- a/libgcc/config/gthr-rtems.h
+++ b/libgcc/config/gthr-rtems.h
@@ -27,134 +27,217 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  
If not, see
 #ifndef GCC_GTHR_RTEMS_H
 #define GCC_GTHR_RTEMS_H
 
+#include sys/lock.h
+#include pthread.h
+#include sched.h
+
 #ifdef __cplusplus
 extern C {
 #endif
 
 #define __GTHREADS 1
+#define __GTHREADS_CXX0X 1
+#define __GTHREAD_HAS_COND 1
+
+typedef pthread_t __gthread_t;
+typedef pthread_key_t __gthread_key_t;
+typedef pthread_once_t __gthread_once_t;
+typedef struct _Mutex_Control __gthread_mutex_t;
+typedef struct _Mutex_recursive_Control __gthread_recursive_mutex_t;
+typedef struct _Condition_Control __gthread_cond_t;
+typedef struct timespec __gthread_time_t;
+
+#define __GTHREAD_ONCE_INIT PTHREAD_ONCE_INIT
+#define __GTHREAD_MUTEX_INIT _MUTEX_INITIALIZER
+#define __GTHREAD_MUTEX_INIT_FUNCTION _Mutex_Initialize
+#define __GTHREAD_RECURSIVE_MUTEX_INIT _MUTEX_RECURSIVE_INITIALIZER
+#define __GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION _Mutex_recursive_Initialize
+#define __GTHREAD_COND_INIT _CONDITION_INITIALIZER
+#define __GTHREAD_COND_INIT_FUNCTION _Condition_Initialize
+#define __GTHREAD_TIME_INIT {0, 0}
 
-#define __GTHREAD_ONCE_INIT  0
-#define __GTHREAD_MUTEX_INIT_FUNCTION  rtems_gxx_mutex_init
-#define __GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION  rtems_gxx_recursive_mutex_init
-
-/* Avoid dependency on rtems specific headers.  */
-typedef void *__gthread_key_t;
-typedef int   __gthread_once_t;
-typedef void *__gthread_mutex_t;
-typedef void *__gthread_recursive_mutex_t;
-
-/*
- * External functions provided by RTEMS. They are

Re: [PATCH] [RTEMS] Update RTEMS thread model

2015-07-31 Thread Sebastian Huber 



On 31/07/15 09:10, Chris Johns wrote:

On 31/07/2015 4:44 pm, Sebastian Huber wrote:



Is this for 4.12 ?


This is just a proof-of-concept patch, but it would be nice to include
this in the next release along with the C11 threads support.


If you have tests and they are ok then why not put it in.



It is thoroughly tested in the libstdc++ test suite, unfortunately we 
have do adjust all test cases since they contain stuff like this:


// { dg-do run { target *-*-freebsd* *-*-dragonfly* *-*-netbsd* 
*-*-linux* *-*-gnu* *-*-solaris* *-*-cygwin *-*-darwin* powerpc-ibm-aix* } }
// { dg-options  -std=gnu++11 -pthread { target *-*-freebsd* 
*-*-dragonfly* *-*-netbsd* *-*-linux* *-*-gnu* powerpc-ibm-aix* } }

// { dg-options  -std=gnu++11 -pthreads { target *-*-solaris* } }
// { dg-options  -std=gnu++11  { target *-*-cygwin *-*-darwin* } }
// { dg-require-cstdint  }
// { dg-require-gthreads  }

So, there is a target white list.

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel