Re: coverage : error when running --coverage with rtems-test for whole testsuites
Hi There is a bug in the DWARF DIE class whIch crashes covoar and returns a -9. I have a fix but I have no computer access to finishes the changes and push the fix. I hope to be back sometime next week. I am sorry about this. Chris > On 21 Jul 2018, at 10:19 am, Vijay Kumar Banerjee > wrote: > >> On Fri, Jul 20, 2018, 10:08 PM Joel Sherrill wrote: >> >> >>> On Fri, Jul 20, 2018 at 9:14 AM, Gedare Bloom wrote: >>> On Thu, Jul 19, 2018 at 6:29 PM, Vijay Kumar Banerjee >>> wrote: >>> > Hello, >>> > >>> > I used the following command >>> > >>> > >>> > $HOME/development/rtems/test/rtems-tools/tester/rtems-test \ >>> > --rtems-tools=$HOME/development/rtems/5 --log=coverage_analysis.log \ >>> > --no-clean --coverage=score --rtems-bsp=leon3-qemu-cov \ >>> > /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites >>> > --debug-trace=cov >>> > >>> > >>> > and I'm getting the following error >>> > >>> > === >>> > error: coverage: covoar failure:: -9 >>> > === >>> > >>> >>> What does error code -9 mean from covoar? >>> >>> Does it make any progress at all? >> >> Can you capture the command line used to invoke covoar and >> run it in gdb? That's an odd error message. covoar is usually >> good at printing something useful. It was written to be paranoid. > > yes I'm trying to run it in gdb, the laptop > freezes for a long time and I have to > restart it, I'll give it more time tommorow > and let it take as much time as it wants > > It runs fine for samples/ so we're searching > for a small test case where it trips, so > I'll run it separately for each set of tests, > like benchmarks/ , fstests/ ... > >> >>> >>> > This, however, runs fine for samples/ >>> > >>> >>> does this command work for you without using the cov options? >>> >>> > I think this will probably be on hold as Chris seems to be >>> > on a break, meanwhile, I want to do a wrapup work on >>> > the non-gcov coverage reports, I seek suggestions/advice >>> > for the same. >>> > >>> > The current state is that the coverage reports can be generated >>> > for one symbol-set only, There's a ticket for the support of >>> > generating separate reports of multiple sets from covoar. >>> > >>> > https://devel.rtems.org/ticket/3441 >> >> I thought originally that the Python would invoke covoar multiple >> times. It was slower but that was how it was originally designed. >> Is there no support in the Python for doing this? > > I was building it in a way that the script invokes > covoar multiple times, but Chris' modifications > to covoar added support for reading multiple symbol-sets > after which I changed the coverage script. > > If we're planning to have this support in > the python script untill covoar is updated, > then I can add it. > >> >>> >>> > >>> > Please let me know of any suggestions including suggestions >>> > regarding documentation as Coverage needs more >>> > documentation. >>> > >>> >>> What is the existing documentation for coverage? >> >> That's an important part of reproducability. >> >>> >>> > Thanks >>> > -- vijay >>> > >>> > ___ >>> > 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: coverage : error when running --coverage with rtems-test for whole testsuites
On Fri, Jul 20, 2018, 10:08 PM Joel Sherrill wrote: > > > On Fri, Jul 20, 2018 at 9:14 AM, Gedare Bloom wrote: > >> On Thu, Jul 19, 2018 at 6:29 PM, Vijay Kumar Banerjee >> wrote: >> > Hello, >> > >> > I used the following command >> > >> > >> > $HOME/development/rtems/test/rtems-tools/tester/rtems-test \ >> > --rtems-tools=$HOME/development/rtems/5 --log=coverage_analysis.log \ >> > --no-clean --coverage=score --rtems-bsp=leon3-qemu-cov \ >> > >> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites >> > --debug-trace=cov >> > >> > >> > and I'm getting the following error >> > >> > === >> > error: coverage: covoar failure:: -9 >> > === >> > >> >> What does error code -9 mean from covoar? >> >> Does it make any progress at all? >> > > Can you capture the command line used to invoke covoar and > run it in gdb? That's an odd error message. covoar is usually > good at printing something useful. It was written to be paranoid. > yes I'm trying to run it in gdb, the laptop freezes for a long time and I have to restart it, I'll give it more time tommorow and let it take as much time as it wants It runs fine for samples/ so we're searching for a small test case where it trips, so I'll run it separately for each set of tests, like benchmarks/ , fstests/ ... > >> >> > This, however, runs fine for samples/ >> > >> >> does this command work for you without using the cov options? >> >> > I think this will probably be on hold as Chris seems to be >> > on a break, meanwhile, I want to do a wrapup work on >> > the non-gcov coverage reports, I seek suggestions/advice >> > for the same. >> > >> > The current state is that the coverage reports can be generated >> > for one symbol-set only, There's a ticket for the support of >> > generating separate reports of multiple sets from covoar. >> > >> > https://devel.rtems.org/ticket/3441 > > > I thought originally that the Python would invoke covoar multiple > times. It was slower but that was how it was originally designed. > Is there no support in the Python for doing this? > I was building it in a way that the script invokes covoar multiple times, but Chris' modifications to covoar added support for reading multiple symbol-sets after which I changed the coverage script. If we're planning to have this support in the python script untill covoar is updated, then I can add it. > >> >> > >> > Please let me know of any suggestions including suggestions >> > regarding documentation as Coverage needs more >> > documentation. >> > >> >> What is the existing documentation for coverage? >> > > That's an important part of reproducability. > > >> >> > Thanks >> > -- vijay >> > >> > ___ >> > 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: coverage : error when running --coverage with rtems-test for whole testsuites
On Fri, Jul 20, 2018 at 9:14 AM, Gedare Bloom wrote: > On Thu, Jul 19, 2018 at 6:29 PM, Vijay Kumar Banerjee > wrote: > > Hello, > > > > I used the following command > > > > > > $HOME/development/rtems/test/rtems-tools/tester/rtems-test \ > > --rtems-tools=$HOME/development/rtems/5 --log=coverage_analysis.log \ > > --no-clean --coverage=score --rtems-bsp=leon3-qemu-cov \ > > /home/lunatic/development/rtems/kernel/leon3/sparc- > rtems5/c/leon3/testsuites > > --debug-trace=cov > > > > > > and I'm getting the following error > > > > === > > error: coverage: covoar failure:: -9 > > === > > > > What does error code -9 mean from covoar? > > Does it make any progress at all? > Can you capture the command line used to invoke covoar and run it in gdb? That's an odd error message. covoar is usually good at printing something useful. It was written to be paranoid. > > > This, however, runs fine for samples/ > > > > does this command work for you without using the cov options? > > > I think this will probably be on hold as Chris seems to be > > on a break, meanwhile, I want to do a wrapup work on > > the non-gcov coverage reports, I seek suggestions/advice > > for the same. > > > > The current state is that the coverage reports can be generated > > for one symbol-set only, There's a ticket for the support of > > generating separate reports of multiple sets from covoar. > > > > https://devel.rtems.org/ticket/3441 I thought originally that the Python would invoke covoar multiple times. It was slower but that was how it was originally designed. Is there no support in the Python for doing this? > > > > > Please let me know of any suggestions including suggestions > > regarding documentation as Coverage needs more > > documentation. > > > > What is the existing documentation for coverage? > That's an important part of reproducability. > > > Thanks > > -- vijay > > > > ___ > > 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: coverage : error when running --coverage with rtems-test for whole testsuites
On Fri, Jul 20, 2018, 9:19 PM Gedare Bloom wrote: > On Fri, Jul 20, 2018 at 11:43 AM, Vijay Kumar Banerjee > wrote: > > On 20 July 2018 at 19:44, Gedare Bloom wrote: > >> > >> On Thu, Jul 19, 2018 at 6:29 PM, Vijay Kumar Banerjee > >> wrote: > >> > Hello, > >> > > >> > I used the following command > >> > > >> > > >> > $HOME/development/rtems/test/rtems-tools/tester/rtems-test \ > >> > --rtems-tools=$HOME/development/rtems/5 --log=coverage_analysis.log \ > >> > --no-clean --coverage=score --rtems-bsp=leon3-qemu-cov \ > >> > > >> > > /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites > >> > --debug-trace=cov > >> > > >> > > >> > and I'm getting the following error > >> > > >> > === > >> > error: coverage: covoar failure:: -9 > >> > === > >> > > >> > >> What does error code -9 mean from covoar? > >> > > I don't know what does code -9 mean. > > The error is coming from here > > > https://github.com/RTEMS/rtems-tools/blob/master/tester/rt/coverage.py#L329 > > > > I should have said, "Can you figure out what error code -9 means?" > You'll have to trace back to find where it originates. > I am looking into it. > > I will run coverage for testsuites/ again and upload the log file here. > >> > >> Does it make any progress at all? > >> > > The tests are running but coverage doesn't progress at all. > >> > >> > This, however, runs fine for samples/ > >> > > >> > >> does this command work for you without using the cov options? > >> > > yes > >> > >> > I think this will probably be on hold as Chris seems to be > >> > on a break, meanwhile, I want to do a wrapup work on > >> > the non-gcov coverage reports, I seek suggestions/advice > >> > for the same. > >> > > >> > The current state is that the coverage reports can be generated > >> > for one symbol-set only, There's a ticket for the support of > >> > generating separate reports of multiple sets from covoar. > >> > > >> > https://devel.rtems.org/ticket/3441 > >> > > >> > Please let me know of any suggestions including suggestions > >> > regarding documentation as Coverage needs more > >> > documentation. > >> > > >> > >> What is the existing documentation for coverage? > >> > > I found these links > > > > https://devel.rtems.org/wiki/TBR/UserManual/RTEMS_Coverage_Analysis > > https://devel.rtems.org/wiki/Developer/Coverage/Theory > > https://devel.rtems.org/wiki/Developer/Coverage/Analysis > > > > We need to capture this stuff in a proper manual. At least it could > start as a chapter in the user manual, maybe? @Joel ideas? > > >> > Thanks > >> > -- vijay > >> > > >> > ___ > >> > 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 3/3] score: Add _CPU_Instruction_illegal()
On Fri, Jul 20, 2018 at 11:46 AM, Sebastian Huber wrote: > - Am 20. Jul 2018 um 16:28 schrieb Gedare Bloom ged...@rtems.org: > >> I want to reiterate my comment that some ISAs have valid instructions >> with an encoding of all zeroes. Off the top of my head, MIPS32 of all >> 0s is the encoding for sll $0, $0, 0, which is a nop. > > Yes, I added some special instructions on some architectures, but I don't > know all of them. I will try to use the "illegal" instruction on m68k. > > Do you now an opcode for MIPS? > I think all 1s is an undefined/illegal opcode for mips, so .word -1 might work >> >> I am not too sure about the purpose of the test anymore, as if an >> illegal instruction exception occurs, the alignment/data access >> exception does not get executed. > > Yes, I will remove this stuff in v2. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 3/3] 5: Update Newlib
I will replace this Newlib version with the snapshot from today. It should fix the 16-bit issues. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: coverage : error when running --coverage with rtems-test for whole testsuites
On Fri, Jul 20, 2018 at 11:43 AM, Vijay Kumar Banerjee wrote: > On 20 July 2018 at 19:44, Gedare Bloom wrote: >> >> On Thu, Jul 19, 2018 at 6:29 PM, Vijay Kumar Banerjee >> wrote: >> > Hello, >> > >> > I used the following command >> > >> > >> > $HOME/development/rtems/test/rtems-tools/tester/rtems-test \ >> > --rtems-tools=$HOME/development/rtems/5 --log=coverage_analysis.log \ >> > --no-clean --coverage=score --rtems-bsp=leon3-qemu-cov \ >> > >> > /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites >> > --debug-trace=cov >> > >> > >> > and I'm getting the following error >> > >> > === >> > error: coverage: covoar failure:: -9 >> > === >> > >> >> What does error code -9 mean from covoar? >> > I don't know what does code -9 mean. > The error is coming from here > https://github.com/RTEMS/rtems-tools/blob/master/tester/rt/coverage.py#L329 > I should have said, "Can you figure out what error code -9 means?" You'll have to trace back to find where it originates. > I will run coverage for testsuites/ again and upload the log file here. >> >> Does it make any progress at all? >> > The tests are running but coverage doesn't progress at all. >> >> > This, however, runs fine for samples/ >> > >> >> does this command work for you without using the cov options? >> > yes >> >> > I think this will probably be on hold as Chris seems to be >> > on a break, meanwhile, I want to do a wrapup work on >> > the non-gcov coverage reports, I seek suggestions/advice >> > for the same. >> > >> > The current state is that the coverage reports can be generated >> > for one symbol-set only, There's a ticket for the support of >> > generating separate reports of multiple sets from covoar. >> > >> > https://devel.rtems.org/ticket/3441 >> > >> > Please let me know of any suggestions including suggestions >> > regarding documentation as Coverage needs more >> > documentation. >> > >> >> What is the existing documentation for coverage? >> > I found these links > > https://devel.rtems.org/wiki/TBR/UserManual/RTEMS_Coverage_Analysis > https://devel.rtems.org/wiki/Developer/Coverage/Theory > https://devel.rtems.org/wiki/Developer/Coverage/Analysis > We need to capture this stuff in a proper manual. At least it could start as a chapter in the user manual, maybe? @Joel ideas? >> > Thanks >> > -- vijay >> > >> > ___ >> > 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 3/3] score: Add _CPU_Instruction_illegal()
- Am 20. Jul 2018 um 16:28 schrieb Gedare Bloom ged...@rtems.org: > I want to reiterate my comment that some ISAs have valid instructions > with an encoding of all zeroes. Off the top of my head, MIPS32 of all > 0s is the encoding for sll $0, $0, 0, which is a nop. Yes, I added some special instructions on some architectures, but I don't know all of them. I will try to use the "illegal" instruction on m68k. Do you now an opcode for MIPS? > > I am not too sure about the purpose of the test anymore, as if an > illegal instruction exception occurs, the alignment/data access > exception does not get executed. Yes, I will remove this stuff in v2. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: coverage : error when running --coverage with rtems-test for whole testsuites
On 20 July 2018 at 19:44, Gedare Bloom wrote: > On Thu, Jul 19, 2018 at 6:29 PM, Vijay Kumar Banerjee > wrote: > > Hello, > > > > I used the following command > > > > > > $HOME/development/rtems/test/rtems-tools/tester/rtems-test \ > > --rtems-tools=$HOME/development/rtems/5 --log=coverage_analysis.log \ > > --no-clean --coverage=score --rtems-bsp=leon3-qemu-cov \ > > /home/lunatic/development/rtems/kernel/leon3/sparc- > rtems5/c/leon3/testsuites > > --debug-trace=cov > > > > > > and I'm getting the following error > > > > === > > error: coverage: covoar failure:: -9 > > === > > > > What does error code -9 mean from covoar? > > I don't know what does code -9 mean. The error is coming from here https://github.com/RTEMS/rtems-tools/blob/master/tester/rt/coverage.py#L329 I will run coverage for testsuites/ again and upload the log file here. > Does it make any progress at all? > > The tests are running but coverage doesn't progress at all. > > This, however, runs fine for samples/ > > > > does this command work for you without using the cov options? > > yes > > I think this will probably be on hold as Chris seems to be > > on a break, meanwhile, I want to do a wrapup work on > > the non-gcov coverage reports, I seek suggestions/advice > > for the same. > > > > The current state is that the coverage reports can be generated > > for one symbol-set only, There's a ticket for the support of > > generating separate reports of multiple sets from covoar. > > > > https://devel.rtems.org/ticket/3441 > > > > Please let me know of any suggestions including suggestions > > regarding documentation as Coverage needs more > > documentation. > > > > What is the existing documentation for coverage? > > I found these links https://devel.rtems.org/wiki/TBR/UserManual/RTEMS_Coverage_Analysis https://devel.rtems.org/wiki/Developer/Coverage/Theory https://devel.rtems.org/wiki/Developer/Coverage/Analysis > Thanks > > -- vijay > > > > ___ > > 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] sptests/spfatal26: Use an illegal instruction
- Am 20. Jul 2018 um 17:35 schrieb joel j...@rtems.org: > On Fri, Jul 20, 2018 at 10:22 AM, Amaan Cheval > wrote: > >> On Fri, Jul 20, 2018 at 12:18 AM, Joel Sherrill wrote: [...] >> - How our GCC toolchains implicitly have "-lrtemsbsp -lrtemscpu" for >> when -qrtems is used[1] >> >> [1] https://github.com/gcc-mirror/gcc/blob/master/gcc/config/rtems.h#L41 > > > I think this is not so bad but non-obvious. > > The inconsistent and hacky use of bsp_specs needs to disappear. The issue with the autoconf link-time feature detection during the GCC build is still not solved. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] sptests/spfatal26: Use an illegal instruction
On Fri, Jul 20, 2018 at 10:22 AM, Amaan Cheval wrote: > On Fri, Jul 20, 2018 at 12:18 AM, Joel Sherrill wrote: > > > > > > On Thu, Jul 19, 2018 at 1:37 PM, Sebastian Huber > > wrote: > >> > >> > >> > >> - Am 19. Jul 2018 um 17:03 schrieb joel j...@rtems.org: > >> > >> > On Thu, Jul 19, 2018 at 8:49 AM, Gedare Bloom > wrote: > >> > > >> >> For now we don't need to generalize this approach or make any kind of > >> >> facility like this available outside of testing. > >> >> > >> >> (FYI: 0 is a "nop" on some architectures) > >> >> > >> >> Gedare > >> >> > >> >> On Thu, Jul 19, 2018 at 9:37 AM, Sebastian Huber > >> >> wrote: > >> >> > I thought about adding a _CPU_Illegal_instruction() function to > >> >> > . But, do you want such a toxic function in a > >> >> > header > >> >> file > >> >> > or librtemscpu.a? Now it is isolated in the test and can do no > harm. > >> >> > >> > > >> > I have wondered if there enough architectural oddities like this in > >> > the tests where a central place to address them would be helpful > >> > when porting. > >> > >> I am not really happy about the use of architecture defines in the > tests. > >> I will add a _CPU_Instruction_illegal() and > _CPU_Instruction_no_operation() > >> (used by testsuites/sptests/spcache01/init.c) to > > >> tomorrow. > >> > >> > > >> > Where all do you have to check now when porting? > >> > >> You always have to check the test results. > > > > > > I meant how many places in the source do you have to touch that > > you don't expect? For example, RPC has some architecture conditionals > > in it that are easy to forget. > > Yep, the xdr_float.c update was definitely not something I expected to > have to do: > https://git.rtems.org/rtems/commit/?id=76c03152e110dcb770253b54277811 > 228e8f78df > > Thankfully, IIRC, it was a compile-time error, so it called attention > to itself pretty easily. > Yep. This should be added to the porting guide. > > Others that were unexpected / hard to understand at first for me: > > - Not sure why I need > cpukit/score/cpu/x86_64/include/machine/elf_machdep.h and not > important enough > This is a new area and I assume it is for dynamic loading. We should find out from Chris and add that to the porting guide. > - The bsps/*/*/config/bsp.cfg file and what magic variables affect > compilation of which parts of the system (CPU_CFLAGS vs. > CFLAGS_OPTIMIZE_V) > - The hacky use of bsp_specs to override some GCC defaults (the > inclusion of the default crt0 earlier, with __getreent being redefined > erroneously) > Hopefully these two area will improve. Hang around after GSoC and maybe you will see them disappear. :) > - How our GCC toolchains implicitly have "-lrtemsbsp -lrtemscpu" for > when -qrtems is used[1] > > [1] https://github.com/gcc-mirror/gcc/blob/master/gcc/config/rtems.h#L41 I think this is not so bad but non-obvious. The inconsistent and hacky use of bsp_specs needs to disappear. > > > > > > --joel > > > > > > ___ > > 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] sptests/spfatal26: Use an illegal instruction
On Fri, Jul 20, 2018 at 12:18 AM, Joel Sherrill wrote: > > > On Thu, Jul 19, 2018 at 1:37 PM, Sebastian Huber > wrote: >> >> >> >> - Am 19. Jul 2018 um 17:03 schrieb joel j...@rtems.org: >> >> > On Thu, Jul 19, 2018 at 8:49 AM, Gedare Bloom wrote: >> > >> >> For now we don't need to generalize this approach or make any kind of >> >> facility like this available outside of testing. >> >> >> >> (FYI: 0 is a "nop" on some architectures) >> >> >> >> Gedare >> >> >> >> On Thu, Jul 19, 2018 at 9:37 AM, Sebastian Huber >> >> wrote: >> >> > I thought about adding a _CPU_Illegal_instruction() function to >> >> > . But, do you want such a toxic function in a >> >> > header >> >> file >> >> > or librtemscpu.a? Now it is isolated in the test and can do no harm. >> >> >> > >> > I have wondered if there enough architectural oddities like this in >> > the tests where a central place to address them would be helpful >> > when porting. >> >> I am not really happy about the use of architecture defines in the tests. >> I will add a _CPU_Instruction_illegal() and _CPU_Instruction_no_operation() >> (used by testsuites/sptests/spcache01/init.c) to >> tomorrow. >> >> > >> > Where all do you have to check now when porting? >> >> You always have to check the test results. > > > I meant how many places in the source do you have to touch that > you don't expect? For example, RPC has some architecture conditionals > in it that are easy to forget. Yep, the xdr_float.c update was definitely not something I expected to have to do: https://git.rtems.org/rtems/commit/?id=76c03152e110dcb770253b54277811228e8f78df Thankfully, IIRC, it was a compile-time error, so it called attention to itself pretty easily. Others that were unexpected / hard to understand at first for me: - Not sure why I need cpukit/score/cpu/x86_64/include/machine/elf_machdep.h and not important enough - The bsps/*/*/config/bsp.cfg file and what magic variables affect compilation of which parts of the system (CPU_CFLAGS vs. CFLAGS_OPTIMIZE_V) - The hacky use of bsp_specs to override some GCC defaults (the inclusion of the default crt0 earlier, with __getreent being redefined erroneously) - How our GCC toolchains implicitly have "-lrtemsbsp -lrtemscpu" for when -qrtems is used[1] [1] https://github.com/gcc-mirror/gcc/blob/master/gcc/config/rtems.h#L41 > > --joel > > > ___ > 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 3/3] score: Add _CPU_Instruction_illegal()
I want to reiterate my comment that some ISAs have valid instructions
with an encoding of all zeroes. Off the top of my head, MIPS32 of all
0s is the encoding for sll $0, $0, 0, which is a nop.
I am not too sure about the purpose of the test anymore, as if an
illegal instruction exception occurs, the alignment/data access
exception does not get executed.
Gedare
On Fri, Jul 20, 2018 at 2:53 AM, Sebastian Huber
wrote:
> On some architectures/simulators it is difficult to provoke an
> exception with misaligned or illegal data loads. Use an illegal
> instruction instead.
>
> Update #3433.
> ---
> cpukit/score/cpu/arm/include/rtems/score/cpuimpl.h | 5 +
> cpukit/score/cpu/bfin/include/rtems/score/cpuimpl.h | 5 +
> cpukit/score/cpu/epiphany/include/rtems/score/cpuimpl.h | 5 +
> cpukit/score/cpu/i386/include/rtems/score/cpuimpl.h | 5 +
> cpukit/score/cpu/lm32/include/rtems/score/cpuimpl.h | 5 +
> cpukit/score/cpu/m32c/include/rtems/score/cpuimpl.h | 5 +
> cpukit/score/cpu/m68k/include/rtems/score/cpuimpl.h | 5 +
> cpukit/score/cpu/mips/include/rtems/score/cpuimpl.h | 5 +
> cpukit/score/cpu/moxie/include/rtems/score/cpuimpl.h| 5 +
> cpukit/score/cpu/nios2/include/rtems/score/cpuimpl.h| 5 +
> cpukit/score/cpu/no_cpu/include/rtems/score/cpuimpl.h | 10 ++
> cpukit/score/cpu/or1k/include/rtems/score/cpuimpl.h | 5 +
> cpukit/score/cpu/powerpc/include/rtems/score/cpuimpl.h | 5 +
> cpukit/score/cpu/riscv/include/rtems/score/cpuimpl.h| 5 +
> cpukit/score/cpu/sh/include/rtems/score/cpuimpl.h | 5 +
> cpukit/score/cpu/sparc/include/rtems/score/cpuimpl.h| 5 +
> cpukit/score/cpu/sparc64/include/rtems/score/cpuimpl.h | 5 +
> cpukit/score/cpu/v850/include/rtems/score/cpuimpl.h | 5 +
> cpukit/score/cpu/x86_64/include/rtems/score/cpuimpl.h | 5 +
> testsuites/sptests/spfatal26/init.c | 13 ++---
> 20 files changed, 110 insertions(+), 3 deletions(-)
>
> diff --git a/cpukit/score/cpu/arm/include/rtems/score/cpuimpl.h
> b/cpukit/score/cpu/arm/include/rtems/score/cpuimpl.h
> index d007a7982b..b856349db3 100644
> --- a/cpukit/score/cpu/arm/include/rtems/score/cpuimpl.h
> +++ b/cpukit/score/cpu/arm/include/rtems/score/cpuimpl.h
> @@ -106,6 +106,11 @@ void _CPU_Context_volatile_clobber( uintptr_t pattern );
>
> void _CPU_Context_validate( uintptr_t pattern );
>
> +RTEMS_INLINE_ROUTINE void _CPU_Instruction_illegal( void )
> +{
> + __asm__ volatile ( "udf" );
> +}
> +
> RTEMS_INLINE_ROUTINE void _CPU_Instruction_no_operation( void )
> {
>__asm__ volatile ( "nop" );
> diff --git a/cpukit/score/cpu/bfin/include/rtems/score/cpuimpl.h
> b/cpukit/score/cpu/bfin/include/rtems/score/cpuimpl.h
> index 5d8bd77161..78b87ef981 100644
> --- a/cpukit/score/cpu/bfin/include/rtems/score/cpuimpl.h
> +++ b/cpukit/score/cpu/bfin/include/rtems/score/cpuimpl.h
> @@ -37,6 +37,11 @@ RTEMS_INLINE_ROUTINE void _CPU_Context_validate( uintptr_t
> pattern )
>}
> }
>
> +RTEMS_INLINE_ROUTINE void _CPU_Instruction_illegal( void )
> +{
> + __asm__ volatile ( ".word 0" );
> +}
> +
> RTEMS_INLINE_ROUTINE void _CPU_Instruction_no_operation( void )
> {
>__asm__ volatile ( "nop" );
> diff --git a/cpukit/score/cpu/epiphany/include/rtems/score/cpuimpl.h
> b/cpukit/score/cpu/epiphany/include/rtems/score/cpuimpl.h
> index 5d8bd77161..78b87ef981 100644
> --- a/cpukit/score/cpu/epiphany/include/rtems/score/cpuimpl.h
> +++ b/cpukit/score/cpu/epiphany/include/rtems/score/cpuimpl.h
> @@ -37,6 +37,11 @@ RTEMS_INLINE_ROUTINE void _CPU_Context_validate( uintptr_t
> pattern )
>}
> }
>
> +RTEMS_INLINE_ROUTINE void _CPU_Instruction_illegal( void )
> +{
> + __asm__ volatile ( ".word 0" );
> +}
> +
> RTEMS_INLINE_ROUTINE void _CPU_Instruction_no_operation( void )
> {
>__asm__ volatile ( "nop" );
> diff --git a/cpukit/score/cpu/i386/include/rtems/score/cpuimpl.h
> b/cpukit/score/cpu/i386/include/rtems/score/cpuimpl.h
> index 5d8bd77161..78b87ef981 100644
> --- a/cpukit/score/cpu/i386/include/rtems/score/cpuimpl.h
> +++ b/cpukit/score/cpu/i386/include/rtems/score/cpuimpl.h
> @@ -37,6 +37,11 @@ RTEMS_INLINE_ROUTINE void _CPU_Context_validate( uintptr_t
> pattern )
>}
> }
>
> +RTEMS_INLINE_ROUTINE void _CPU_Instruction_illegal( void )
> +{
> + __asm__ volatile ( ".word 0" );
> +}
> +
> RTEMS_INLINE_ROUTINE void _CPU_Instruction_no_operation( void )
> {
>__asm__ volatile ( "nop" );
> diff --git a/cpukit/score/cpu/lm32/include/rtems/score/cpuimpl.h
> b/cpukit/score/cpu/lm32/include/rtems/score/cpuimpl.h
> index 5d8bd77161..78b87ef981 100644
> --- a/cpukit/score/cpu/lm32/include/rtems/score/cpuimpl.h
> +++ b/cpukit/score/cpu/lm32/include/rtems/score/cpuimpl.h
> @@ -37,6 +37,11 @@ RTEMS_INLINE_ROUTINE void _CPU_Context_validate( uintptr_t
> pattern )
>}
> }
>
> +RTEMS_INLINE_ROUTINE void _CPU_Instruction_illegal( void )
> +{
> +
Re: [PATCH 2/3] score: Add _CPU_Instruction_no_operation()
This seems fine to me.
On Fri, Jul 20, 2018 at 2:53 AM, Sebastian Huber
wrote:
> This helps to reduce the use of architecture-specific defines throughout
> the code base.
> ---
> cpukit/score/cpu/arm/include/rtems/score/cpuimpl.h | 5 +
> cpukit/score/cpu/bfin/include/rtems/score/cpuimpl.h | 5 +
> cpukit/score/cpu/epiphany/include/rtems/score/cpuimpl.h | 5 +
> cpukit/score/cpu/i386/include/rtems/score/cpuimpl.h | 5 +
> cpukit/score/cpu/lm32/include/rtems/score/cpuimpl.h | 5 +
> cpukit/score/cpu/m32c/include/rtems/score/cpuimpl.h | 5 +
> cpukit/score/cpu/m68k/include/rtems/score/cpuimpl.h | 5 +
> cpukit/score/cpu/mips/include/rtems/score/cpuimpl.h | 5 +
> cpukit/score/cpu/moxie/include/rtems/score/cpuimpl.h| 5 +
> cpukit/score/cpu/nios2/include/rtems/score/cpuimpl.h| 5 +
> cpukit/score/cpu/no_cpu/include/rtems/score/cpuimpl.h | 10 ++
> cpukit/score/cpu/or1k/include/rtems/score/cpuimpl.h | 5 +
> cpukit/score/cpu/powerpc/include/rtems/score/cpuimpl.h | 5 +
> cpukit/score/cpu/riscv/include/rtems/score/cpuimpl.h| 5 +
> cpukit/score/cpu/sh/include/rtems/score/cpuimpl.h | 5 +
> cpukit/score/cpu/sparc/include/rtems/score/cpuimpl.h| 5 +
> cpukit/score/cpu/sparc64/include/rtems/score/cpuimpl.h | 5 +
> cpukit/score/cpu/v850/include/rtems/score/cpuimpl.h | 5 +
> cpukit/score/cpu/x86_64/include/rtems/score/cpuimpl.h | 5 +
> testsuites/sptests/spcache01/init.c | 7 ++-
> 20 files changed, 102 insertions(+), 5 deletions(-)
>
> diff --git a/cpukit/score/cpu/arm/include/rtems/score/cpuimpl.h
> b/cpukit/score/cpu/arm/include/rtems/score/cpuimpl.h
> index edc452530f..d007a7982b 100644
> --- a/cpukit/score/cpu/arm/include/rtems/score/cpuimpl.h
> +++ b/cpukit/score/cpu/arm/include/rtems/score/cpuimpl.h
> @@ -106,6 +106,11 @@ void _CPU_Context_volatile_clobber( uintptr_t pattern );
>
> void _CPU_Context_validate( uintptr_t pattern );
>
> +RTEMS_INLINE_ROUTINE void _CPU_Instruction_no_operation( void )
> +{
> + __asm__ volatile ( "nop" );
> +}
> +
> #ifdef __cplusplus
> }
> #endif
> diff --git a/cpukit/score/cpu/bfin/include/rtems/score/cpuimpl.h
> b/cpukit/score/cpu/bfin/include/rtems/score/cpuimpl.h
> index ee188bebce..5d8bd77161 100644
> --- a/cpukit/score/cpu/bfin/include/rtems/score/cpuimpl.h
> +++ b/cpukit/score/cpu/bfin/include/rtems/score/cpuimpl.h
> @@ -37,6 +37,11 @@ RTEMS_INLINE_ROUTINE void _CPU_Context_validate( uintptr_t
> pattern )
>}
> }
>
> +RTEMS_INLINE_ROUTINE void _CPU_Instruction_no_operation( void )
> +{
> + __asm__ volatile ( "nop" );
> +}
> +
> #ifdef __cplusplus
> }
> #endif
> diff --git a/cpukit/score/cpu/epiphany/include/rtems/score/cpuimpl.h
> b/cpukit/score/cpu/epiphany/include/rtems/score/cpuimpl.h
> index ee188bebce..5d8bd77161 100644
> --- a/cpukit/score/cpu/epiphany/include/rtems/score/cpuimpl.h
> +++ b/cpukit/score/cpu/epiphany/include/rtems/score/cpuimpl.h
> @@ -37,6 +37,11 @@ RTEMS_INLINE_ROUTINE void _CPU_Context_validate( uintptr_t
> pattern )
>}
> }
>
> +RTEMS_INLINE_ROUTINE void _CPU_Instruction_no_operation( void )
> +{
> + __asm__ volatile ( "nop" );
> +}
> +
> #ifdef __cplusplus
> }
> #endif
> diff --git a/cpukit/score/cpu/i386/include/rtems/score/cpuimpl.h
> b/cpukit/score/cpu/i386/include/rtems/score/cpuimpl.h
> index ee188bebce..5d8bd77161 100644
> --- a/cpukit/score/cpu/i386/include/rtems/score/cpuimpl.h
> +++ b/cpukit/score/cpu/i386/include/rtems/score/cpuimpl.h
> @@ -37,6 +37,11 @@ RTEMS_INLINE_ROUTINE void _CPU_Context_validate( uintptr_t
> pattern )
>}
> }
>
> +RTEMS_INLINE_ROUTINE void _CPU_Instruction_no_operation( void )
> +{
> + __asm__ volatile ( "nop" );
> +}
> +
> #ifdef __cplusplus
> }
> #endif
> diff --git a/cpukit/score/cpu/lm32/include/rtems/score/cpuimpl.h
> b/cpukit/score/cpu/lm32/include/rtems/score/cpuimpl.h
> index ee188bebce..5d8bd77161 100644
> --- a/cpukit/score/cpu/lm32/include/rtems/score/cpuimpl.h
> +++ b/cpukit/score/cpu/lm32/include/rtems/score/cpuimpl.h
> @@ -37,6 +37,11 @@ RTEMS_INLINE_ROUTINE void _CPU_Context_validate( uintptr_t
> pattern )
>}
> }
>
> +RTEMS_INLINE_ROUTINE void _CPU_Instruction_no_operation( void )
> +{
> + __asm__ volatile ( "nop" );
> +}
> +
> #ifdef __cplusplus
> }
> #endif
> diff --git a/cpukit/score/cpu/m32c/include/rtems/score/cpuimpl.h
> b/cpukit/score/cpu/m32c/include/rtems/score/cpuimpl.h
> index ee188bebce..5d8bd77161 100644
> --- a/cpukit/score/cpu/m32c/include/rtems/score/cpuimpl.h
> +++ b/cpukit/score/cpu/m32c/include/rtems/score/cpuimpl.h
> @@ -37,6 +37,11 @@ RTEMS_INLINE_ROUTINE void _CPU_Context_validate( uintptr_t
> pattern )
>}
> }
>
> +RTEMS_INLINE_ROUTINE void _CPU_Instruction_no_operation( void )
> +{
> + __asm__ volatile ( "nop" );
> +}
> +
> #ifdef __cplusplus
> }
> #endif
> diff --git a/cpukit/score/cpu/m68k/include/rtems/score/cpuimpl.h
>
Re: Fwd: Build Linux: PASSED 5/rtems-moxie on x86_64-linux-gnu
On 20/07/18 15:39, Joel Sherrill wrote: There is an odd warning about chown having an absolute path. Any idea what's up with your environment? This always shows up on openSUSE. -- 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 2/3] Allow external Newlib sources
On 20/07/18 16:19, Gedare Bloom wrote: I guess this just follows the pattern used for binutils/gdb on same targets. Seems fine to me. Yes, this is copy and paste form some lines above. -- 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 2/3] Allow external Newlib sources
I guess this just follows the pattern used for binutils/gdb on same
targets. Seems fine to me.
On Fri, Jul 20, 2018 at 4:53 AM, Sebastian Huber
wrote:
> ---
> source-builder/config/gcc-common-1.cfg | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/source-builder/config/gcc-common-1.cfg
> b/source-builder/config/gcc-common-1.cfg
> index 03d84bc..b432fdf 100644
> --- a/source-builder/config/gcc-common-1.cfg
> +++ b/source-builder/config/gcc-common-1.cfg
> @@ -66,8 +66,8 @@ BuildRoot: %{_tmppath}/%{name}-root-%(%{__id_u} -n)
>cd ${build_top}
>
># newlib
> - source_dir_newlib="newlib-%{newlib_version}"
> - %source setup newlib -q -D -n newlib-%{newlib_version}
> +
> source_dir_newlib=%{?newlib_external:%{newlib_expand_name}}%{!?newlib_external:"newlib-%{newlib_version}"}
> + %source setup newlib -q -D -n ${source_dir_newlib}
>%patch setup newlib -p1
>cd ${build_top}
>
> --
> 2.13.7
>
> ___
> 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: Build Linux: FAILED 5/rtems-m32c on x86_64-linux-gnu (m32c-rtems5-gcc-4.8.3-newlib-916ef5fb8865f72d0f5ad3f4f479adac44ea94b1-x86_64-linux-gnu-1)
Probably not too many. I believe most popular 16-bit targets these days are AVR/Arduino type that have their own libc and development ecosystem. I think we made a decision to deprecate/abandon 16-bit support some time ago... On Fri, Jul 20, 2018 at 7:10 AM, Sebastian Huber wrote: > How many 16-bit Newlib users are there? > > https://sourceware.org/ml/newlib/2018/msg00550.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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: coverage : error when running --coverage with rtems-test for whole testsuites
On Thu, Jul 19, 2018 at 6:29 PM, Vijay Kumar Banerjee wrote: > Hello, > > I used the following command > > > $HOME/development/rtems/test/rtems-tools/tester/rtems-test \ > --rtems-tools=$HOME/development/rtems/5 --log=coverage_analysis.log \ > --no-clean --coverage=score --rtems-bsp=leon3-qemu-cov \ > /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites > --debug-trace=cov > > > and I'm getting the following error > > === > error: coverage: covoar failure:: -9 > === > What does error code -9 mean from covoar? Does it make any progress at all? > This, however, runs fine for samples/ > does this command work for you without using the cov options? > I think this will probably be on hold as Chris seems to be > on a break, meanwhile, I want to do a wrapup work on > the non-gcov coverage reports, I seek suggestions/advice > for the same. > > The current state is that the coverage reports can be generated > for one symbol-set only, There's a ticket for the support of > generating separate reports of multiple sets from covoar. > > https://devel.rtems.org/ticket/3441 > > Please let me know of any suggestions including suggestions > regarding documentation as Coverage needs more > documentation. > What is the existing documentation for coverage? > Thanks > -- vijay > > ___ > 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: Build Linux: FAILED 5/rtems-x86_64 on x86_64-linux-gnu (x86_64-rtems5-binutils-2.31.1-x86_64-linux-gnu-1)
Hello, is the x86_64 patch still necessary for Binutils 2.31.1? -- 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: Build Linux: FAILED 5/rtems-m32c on x86_64-linux-gnu (m32c-rtems5-gcc-4.8.3-newlib-916ef5fb8865f72d0f5ad3f4f479adac44ea94b1-x86_64-linux-gnu-1)
How many 16-bit Newlib users are there? https://sourceware.org/ml/newlib/2018/msg00550.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 2/3] Allow external Newlib sources
---
source-builder/config/gcc-common-1.cfg | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/source-builder/config/gcc-common-1.cfg
b/source-builder/config/gcc-common-1.cfg
index 03d84bc..b432fdf 100644
--- a/source-builder/config/gcc-common-1.cfg
+++ b/source-builder/config/gcc-common-1.cfg
@@ -66,8 +66,8 @@ BuildRoot: %{_tmppath}/%{name}-root-%(%{__id_u} -n)
cd ${build_top}
# newlib
- source_dir_newlib="newlib-%{newlib_version}"
- %source setup newlib -q -D -n newlib-%{newlib_version}
+
source_dir_newlib=%{?newlib_external:%{newlib_expand_name}}%{!?newlib_external:"newlib-%{newlib_version}"}
+ %source setup newlib -q -D -n ${source_dir_newlib}
%patch setup newlib -p1
cd ${build_top}
--
2.13.7
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 3/3] 5: Update Newlib
Update #3342.
Update #3343.
Update #3452.
---
rtems/config/5/rtems-default.bset | 2 +-
rtems/config/5/rtems-epiphany.bset | 2 +-
rtems/config/5/rtems-m32c.bset | 2 +-
rtems/config/5/rtems-or1k.bset | 2 +-
rtems/config/5/rtems-riscv32.bset | 2 +-
rtems/config/5/rtems-riscv64.bset | 2 +-
...ib-916ef5fb8865f72d0f5ad3f4f479adac44ea94b1.cfg | 29 ++
...ib-916ef5fb8865f72d0f5ad3f4f479adac44ea94b1.cfg | 10 +++
...ib-916ef5fb8865f72d0f5ad3f4f479adac44ea94b1.cfg | 10 +++
...ib-916ef5fb8865f72d0f5ad3f4f479adac44ea94b1.cfg | 35 ++
10 files changed, 90 insertions(+), 6 deletions(-)
create mode 100644
rtems/config/tools/rtems-gcc-2e2052934b0c82e0726ed44de4a9b0a29ed6b276-newlib-916ef5fb8865f72d0f5ad3f4f479adac44ea94b1.cfg
create mode 100644
rtems/config/tools/rtems-gcc-4.8.3-newlib-916ef5fb8865f72d0f5ad3f4f479adac44ea94b1.cfg
create mode 100644
rtems/config/tools/rtems-gcc-4.9.3-newlib-916ef5fb8865f72d0f5ad3f4f479adac44ea94b1.cfg
create mode 100644
rtems/config/tools/rtems-gcc-7.3.0-newlib-916ef5fb8865f72d0f5ad3f4f479adac44ea94b1.cfg
diff --git a/rtems/config/5/rtems-default.bset
b/rtems/config/5/rtems-default.bset
index eed39fd..446c8bd 100644
--- a/rtems/config/5/rtems-default.bset
+++ b/rtems/config/5/rtems-default.bset
@@ -11,7 +11,7 @@
devel/expat-2.1.0-1
tools/rtems-binutils-2.31.1
-tools/rtems-gcc-7.3.0-newlib-3.0.0
+tools/rtems-gcc-7.3.0-newlib-916ef5fb8865f72d0f5ad3f4f479adac44ea94b1
tools/rtems-gdb-8.0.1-1
tools/rtems-tools-5-1
tools/rtems-kernel-5
diff --git a/rtems/config/5/rtems-epiphany.bset
b/rtems/config/5/rtems-epiphany.bset
index 566cb1a..345756a 100644
--- a/rtems/config/5/rtems-epiphany.bset
+++ b/rtems/config/5/rtems-epiphany.bset
@@ -34,6 +34,6 @@
5/rtems-autotools
devel/expat-2.1.0-1
tools/rtems-binutils-2.31.1
-tools/rtems-gcc-7.3.0-newlib-3.0.0
+tools/rtems-gcc-7.3.0-newlib-916ef5fb8865f72d0f5ad3f4f479adac44ea94b1
tools/rtems-gdb-7.8.1-1
tools/rtems-tools-5-1
diff --git a/rtems/config/5/rtems-m32c.bset b/rtems/config/5/rtems-m32c.bset
index 63fb260..6fe0169 100644
--- a/rtems/config/5/rtems-m32c.bset
+++ b/rtems/config/5/rtems-m32c.bset
@@ -41,6 +41,6 @@
5/rtems-autotools
devel/expat-2.1.0-1
tools/rtems-binutils-2.31.1
-tools/rtems-gcc-4.8.3-newlib-3.0.0
+tools/rtems-gcc-4.8.3-newlib-916ef5fb8865f72d0f5ad3f4f479adac44ea94b1
tools/rtems-gdb-8.0.1-1
tools/rtems-tools-5-1
diff --git a/rtems/config/5/rtems-or1k.bset b/rtems/config/5/rtems-or1k.bset
index d29bb85..7b7bb73 100644
--- a/rtems/config/5/rtems-or1k.bset
+++ b/rtems/config/5/rtems-or1k.bset
@@ -33,6 +33,6 @@
5/rtems-autotools
devel/expat-2.1.0-1
tools/rtems-binutils-2.31.1
-tools/rtems-gcc-4.9.3-newlib-3.0.0
+tools/rtems-gcc-4.9.3-newlib-916ef5fb8865f72d0f5ad3f4f479adac44ea94b1
tools/rtems-tools-5-1
tools/rtems-gdb-7.11-2
diff --git a/rtems/config/5/rtems-riscv32.bset
b/rtems/config/5/rtems-riscv32.bset
index 5dce1da..56f3729 100644
--- a/rtems/config/5/rtems-riscv32.bset
+++ b/rtems/config/5/rtems-riscv32.bset
@@ -11,7 +11,7 @@
devel/expat-2.1.0-1
tools/rtems-binutils-2.31.1
-tools/rtems-gcc-2e2052934b0c82e0726ed44de4a9b0a29ed6b276-newlib-3.0.0
+tools/rtems-gcc-2e2052934b0c82e0726ed44de4a9b0a29ed6b276-newlib-916ef5fb8865f72d0f5ad3f4f479adac44ea94b1
tools/rtems-gdb-160d1b3d74593bf42155da24569f54a6e7140f65
tools/rtems-tools-5-1
tools/rtems-kernel-5
diff --git a/rtems/config/5/rtems-riscv64.bset
b/rtems/config/5/rtems-riscv64.bset
index 6d4ff2b..a0e51f1 100644
--- a/rtems/config/5/rtems-riscv64.bset
+++ b/rtems/config/5/rtems-riscv64.bset
@@ -11,7 +11,7 @@
devel/expat-2.1.0-1
tools/rtems-binutils-2.31.1
-tools/rtems-gcc-2e2052934b0c82e0726ed44de4a9b0a29ed6b276-newlib-3.0.0
+tools/rtems-gcc-2e2052934b0c82e0726ed44de4a9b0a29ed6b276-newlib-916ef5fb8865f72d0f5ad3f4f479adac44ea94b1
tools/rtems-gdb-160d1b3d74593bf42155da24569f54a6e7140f65
tools/rtems-tools-5-1
tools/rtems-kernel-5
diff --git
a/rtems/config/tools/rtems-gcc-2e2052934b0c82e0726ed44de4a9b0a29ed6b276-newlib-916ef5fb8865f72d0f5ad3f4f479adac44ea94b1.cfg
b/rtems/config/tools/rtems-gcc-2e2052934b0c82e0726ed44de4a9b0a29ed6b276-newlib-916ef5fb8865f72d0f5ad3f4f479adac44ea94b1.cfg
new file mode 100644
index 000..29bd167
--- /dev/null
+++
b/rtems/config/tools/rtems-gcc-2e2052934b0c82e0726ed44de4a9b0a29ed6b276-newlib-916ef5fb8865f72d0f5ad3f4f479adac44ea94b1.cfg
@@ -0,0 +1,29 @@
+%include %{_configdir}/checks.cfg
+%include %{_configdir}/base.cfg
+
+%define gcc_version 2e2052934b0c82e0726ed44de4a9b0a29ed6b276
+%define gcc_external 1
+%define gcc_expand_name gnu-mirror-gcc-%{gcc_version}
+%source set gcc --rsb-file=%{gcc_expand_name}.tar.gz
https://codeload.github.com/RTEMS/gnu-mirror-gcc/tar.gz/%{gcc_version}
+%hash sha512 %{gcc_expand_name}.tar.gz
de1e26769a81332e914946f536b0fafaf66b0a99cd017315f6531946a7dd1959e5332a793b65cbd0bb73cc086efd8df2e3abaf74d272197c7635d91e1ef94b71
[PATCH 1/3] 5: Update to Binutils 2.31.1
---
rtems/config/5/rtems-default.bset| 2 +-
rtems/config/5/rtems-epiphany.bset | 2 +-
rtems/config/5/rtems-m32c.bset | 2 +-
rtems/config/5/rtems-or1k.bset | 2 +-
rtems/config/5/rtems-riscv32.bset| 2 +-
rtems/config/5/rtems-riscv64.bset| 2 +-
rtems/config/tools/rtems-binutils-2.31.1.cfg | 27 +++
7 files changed, 33 insertions(+), 6 deletions(-)
create mode 100644 rtems/config/tools/rtems-binutils-2.31.1.cfg
diff --git a/rtems/config/5/rtems-default.bset
b/rtems/config/5/rtems-default.bset
index dcafbdc..eed39fd 100644
--- a/rtems/config/5/rtems-default.bset
+++ b/rtems/config/5/rtems-default.bset
@@ -10,7 +10,7 @@
5/rtems-autotools
devel/expat-2.1.0-1
-tools/rtems-binutils-2.30
+tools/rtems-binutils-2.31.1
tools/rtems-gcc-7.3.0-newlib-3.0.0
tools/rtems-gdb-8.0.1-1
tools/rtems-tools-5-1
diff --git a/rtems/config/5/rtems-epiphany.bset
b/rtems/config/5/rtems-epiphany.bset
index b7ac799..566cb1a 100644
--- a/rtems/config/5/rtems-epiphany.bset
+++ b/rtems/config/5/rtems-epiphany.bset
@@ -33,7 +33,7 @@
#
5/rtems-autotools
devel/expat-2.1.0-1
-tools/rtems-binutils-2.30
+tools/rtems-binutils-2.31.1
tools/rtems-gcc-7.3.0-newlib-3.0.0
tools/rtems-gdb-7.8.1-1
tools/rtems-tools-5-1
diff --git a/rtems/config/5/rtems-m32c.bset b/rtems/config/5/rtems-m32c.bset
index addce75..63fb260 100644
--- a/rtems/config/5/rtems-m32c.bset
+++ b/rtems/config/5/rtems-m32c.bset
@@ -40,7 +40,7 @@
#
5/rtems-autotools
devel/expat-2.1.0-1
-tools/rtems-binutils-2.30
+tools/rtems-binutils-2.31.1
tools/rtems-gcc-4.8.3-newlib-3.0.0
tools/rtems-gdb-8.0.1-1
tools/rtems-tools-5-1
diff --git a/rtems/config/5/rtems-or1k.bset b/rtems/config/5/rtems-or1k.bset
index 15be88e..d29bb85 100644
--- a/rtems/config/5/rtems-or1k.bset
+++ b/rtems/config/5/rtems-or1k.bset
@@ -32,7 +32,7 @@
#
5/rtems-autotools
devel/expat-2.1.0-1
-tools/rtems-binutils-2.30
+tools/rtems-binutils-2.31.1
tools/rtems-gcc-4.9.3-newlib-3.0.0
tools/rtems-tools-5-1
tools/rtems-gdb-7.11-2
diff --git a/rtems/config/5/rtems-riscv32.bset
b/rtems/config/5/rtems-riscv32.bset
index 07853b5..5dce1da 100644
--- a/rtems/config/5/rtems-riscv32.bset
+++ b/rtems/config/5/rtems-riscv32.bset
@@ -10,7 +10,7 @@
5/rtems-autotools
devel/expat-2.1.0-1
-tools/rtems-binutils-160d1b3d74593bf42155da24569f54a6e7140f65
+tools/rtems-binutils-2.31.1
tools/rtems-gcc-2e2052934b0c82e0726ed44de4a9b0a29ed6b276-newlib-3.0.0
tools/rtems-gdb-160d1b3d74593bf42155da24569f54a6e7140f65
tools/rtems-tools-5-1
diff --git a/rtems/config/5/rtems-riscv64.bset
b/rtems/config/5/rtems-riscv64.bset
index 0b4e676..6d4ff2b 100644
--- a/rtems/config/5/rtems-riscv64.bset
+++ b/rtems/config/5/rtems-riscv64.bset
@@ -10,7 +10,7 @@
5/rtems-autotools
devel/expat-2.1.0-1
-tools/rtems-binutils-160d1b3d74593bf42155da24569f54a6e7140f65
+tools/rtems-binutils-2.31.1
tools/rtems-gcc-2e2052934b0c82e0726ed44de4a9b0a29ed6b276-newlib-3.0.0
tools/rtems-gdb-160d1b3d74593bf42155da24569f54a6e7140f65
tools/rtems-tools-5-1
diff --git a/rtems/config/tools/rtems-binutils-2.31.1.cfg
b/rtems/config/tools/rtems-binutils-2.31.1.cfg
new file mode 100644
index 000..121736e
--- /dev/null
+++ b/rtems/config/tools/rtems-binutils-2.31.1.cfg
@@ -0,0 +1,27 @@
+#
+# Binutils 2.31.1
+#
+
+%include %{_configdir}/checks.cfg
+%include %{_configdir}/base.cfg
+
+%define binutils_version 2.31.1
+
+%hash sha512 binutils-%{binutils_version}.tar.bz2
b42954e6f49a0adcd2676bdd77dfb59bfc25cec8184b007521d1e2b1d5d0593b58639e3d9448d5a40fe024c3cea386a37743627d6bb16d502f52a4a32b9573bd
+
+#
+# Enable deterministic archives by default. This will be the default
+# there all tools using this binutils will create deterministic
+# archives.
+#
+%define with_deterministic_archives 1
+
+#
+# Enable 64-bit BFD support
+#
+%define with_64_bit_bfd 1
+
+#
+# The binutils build instructions. We use 2.xx Release 1.
+#
+%include %{_configdir}/binutils-2-1.cfg
--
2.13.7
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 1/3] score: Move context validation declarations
The context validation support functions _CPU_Context_validate() and
_CPU_Context_volatile_clobber() are used only by one test program
(spcontext01). Move the function declarations to the CPU port
implementation header file.
---
cpukit/score/cpu/arm/include/rtems/score/cpu.h | 4 ---
cpukit/score/cpu/arm/include/rtems/score/cpuimpl.h | 4 +++
cpukit/score/cpu/bfin/include/rtems/score/cpu.h| 12 -
.../score/cpu/bfin/include/rtems/score/cpuimpl.h | 12 +
.../score/cpu/epiphany/include/rtems/score/cpu.h | 12 -
.../cpu/epiphany/include/rtems/score/cpuimpl.h | 12 +
cpukit/score/cpu/i386/include/rtems/score/cpu.h| 12 -
.../score/cpu/i386/include/rtems/score/cpuimpl.h | 12 +
cpukit/score/cpu/lm32/include/rtems/score/cpu.h| 12 -
.../score/cpu/lm32/include/rtems/score/cpuimpl.h | 12 +
cpukit/score/cpu/m32c/include/rtems/score/cpu.h| 12 -
.../score/cpu/m32c/include/rtems/score/cpuimpl.h | 12 +
cpukit/score/cpu/m68k/include/rtems/score/cpu.h| 12 -
.../score/cpu/m68k/include/rtems/score/cpuimpl.h | 12 +
cpukit/score/cpu/mips/include/rtems/score/cpu.h| 12 -
.../score/cpu/mips/include/rtems/score/cpuimpl.h | 12 +
cpukit/score/cpu/moxie/include/rtems/score/cpu.h | 12 -
.../score/cpu/moxie/include/rtems/score/cpuimpl.h | 12 +
cpukit/score/cpu/nios2/include/rtems/score/cpu.h | 4 ---
.../score/cpu/nios2/include/rtems/score/cpuimpl.h | 4 +++
cpukit/score/cpu/no_cpu/include/rtems/score/cpu.h | 31 --
.../score/cpu/no_cpu/include/rtems/score/cpuimpl.h | 31 ++
cpukit/score/cpu/or1k/include/rtems/score/cpu.h| 4 ---
.../score/cpu/or1k/include/rtems/score/cpuimpl.h | 4 +++
cpukit/score/cpu/powerpc/include/rtems/score/cpu.h | 4 ---
.../cpu/powerpc/include/rtems/score/cpuimpl.h | 4 +++
cpukit/score/cpu/riscv/include/rtems/score/cpu.h | 4 ---
.../score/cpu/riscv/include/rtems/score/cpuimpl.h | 4 +++
cpukit/score/cpu/sh/include/rtems/score/cpu.h | 12 -
cpukit/score/cpu/sh/include/rtems/score/cpuimpl.h | 12 +
cpukit/score/cpu/sparc/include/rtems/score/cpu.h | 4 ---
.../score/cpu/sparc/include/rtems/score/cpuimpl.h | 4 +++
cpukit/score/cpu/sparc64/include/rtems/score/cpu.h | 12 -
.../cpu/sparc64/include/rtems/score/cpuimpl.h | 12 +
cpukit/score/cpu/v850/include/rtems/score/cpu.h| 12 -
.../score/cpu/v850/include/rtems/score/cpuimpl.h | 12 +
cpukit/score/cpu/x86_64/include/rtems/score/cpu.h | 16 ---
.../score/cpu/x86_64/include/rtems/score/cpuimpl.h | 12 +
testsuites/sptests/spcontext01/init.c | 4 ++-
39 files changed, 202 insertions(+), 204 deletions(-)
diff --git a/cpukit/score/cpu/arm/include/rtems/score/cpu.h
b/cpukit/score/cpu/arm/include/rtems/score/cpu.h
index 4260e98221..ef2bbf6bfb 100644
--- a/cpukit/score/cpu/arm/include/rtems/score/cpu.h
+++ b/cpukit/score/cpu/arm/include/rtems/score/cpu.h
@@ -493,10 +493,6 @@ void _CPU_Context_restore( Context_Control *new_context )
#define _CPU_Start_multitasking _ARMV7M_Start_multitasking
#endif
-void _CPU_Context_volatile_clobber( uintptr_t pattern );
-
-void _CPU_Context_validate( uintptr_t pattern );
-
#ifdef RTEMS_SMP
uint32_t _CPU_SMP_Initialize( void );
diff --git a/cpukit/score/cpu/arm/include/rtems/score/cpuimpl.h
b/cpukit/score/cpu/arm/include/rtems/score/cpuimpl.h
index 0885c2ef39..edc452530f 100644
--- a/cpukit/score/cpu/arm/include/rtems/score/cpuimpl.h
+++ b/cpukit/score/cpu/arm/include/rtems/score/cpuimpl.h
@@ -102,6 +102,10 @@ static inline struct Per_CPU_Control
*_ARM_Get_current_per_CPU_control( void )
#endif /* ARM_MULTILIB_ARCH_V4 */
+void _CPU_Context_volatile_clobber( uintptr_t pattern );
+
+void _CPU_Context_validate( uintptr_t pattern );
+
#ifdef __cplusplus
}
#endif
diff --git a/cpukit/score/cpu/bfin/include/rtems/score/cpu.h
b/cpukit/score/cpu/bfin/include/rtems/score/cpu.h
index c19a077bd3..bca3c81418 100644
--- a/cpukit/score/cpu/bfin/include/rtems/score/cpu.h
+++ b/cpukit/score/cpu/bfin/include/rtems/score/cpu.h
@@ -819,18 +819,6 @@ void _CPU_Context_restore_fp(
Context_Control_fp **fp_context_ptr
);
-static inline void _CPU_Context_volatile_clobber( uintptr_t pattern )
-{
- /* TODO */
-}
-
-static inline void _CPU_Context_validate( uintptr_t pattern )
-{
- while (1) {
-/* TODO */
- }
-}
-
/** @} */
/* FIXME */
diff --git a/cpukit/score/cpu/bfin/include/rtems/score/cpuimpl.h
b/cpukit/score/cpu/bfin/include/rtems/score/cpuimpl.h
index 789f2badd9..ee188bebce 100644
--- a/cpukit/score/cpu/bfin/include/rtems/score/cpuimpl.h
+++ b/cpukit/score/cpu/bfin/include/rtems/score/cpuimpl.h
@@ -25,6 +25,18 @@
extern "C" {
#endif
+RTEMS_INLINE_ROUTINE void _CPU_Context_volatile_clobber( uintptr_t pattern )
+{
+ /* TODO */
+}
+
+RTEMS_INLINE_ROUTINE void
[PATCH 2/3] score: Add _CPU_Instruction_no_operation()
This helps to reduce the use of architecture-specific defines throughout
the code base.
---
cpukit/score/cpu/arm/include/rtems/score/cpuimpl.h | 5 +
cpukit/score/cpu/bfin/include/rtems/score/cpuimpl.h | 5 +
cpukit/score/cpu/epiphany/include/rtems/score/cpuimpl.h | 5 +
cpukit/score/cpu/i386/include/rtems/score/cpuimpl.h | 5 +
cpukit/score/cpu/lm32/include/rtems/score/cpuimpl.h | 5 +
cpukit/score/cpu/m32c/include/rtems/score/cpuimpl.h | 5 +
cpukit/score/cpu/m68k/include/rtems/score/cpuimpl.h | 5 +
cpukit/score/cpu/mips/include/rtems/score/cpuimpl.h | 5 +
cpukit/score/cpu/moxie/include/rtems/score/cpuimpl.h| 5 +
cpukit/score/cpu/nios2/include/rtems/score/cpuimpl.h| 5 +
cpukit/score/cpu/no_cpu/include/rtems/score/cpuimpl.h | 10 ++
cpukit/score/cpu/or1k/include/rtems/score/cpuimpl.h | 5 +
cpukit/score/cpu/powerpc/include/rtems/score/cpuimpl.h | 5 +
cpukit/score/cpu/riscv/include/rtems/score/cpuimpl.h| 5 +
cpukit/score/cpu/sh/include/rtems/score/cpuimpl.h | 5 +
cpukit/score/cpu/sparc/include/rtems/score/cpuimpl.h| 5 +
cpukit/score/cpu/sparc64/include/rtems/score/cpuimpl.h | 5 +
cpukit/score/cpu/v850/include/rtems/score/cpuimpl.h | 5 +
cpukit/score/cpu/x86_64/include/rtems/score/cpuimpl.h | 5 +
testsuites/sptests/spcache01/init.c | 7 ++-
20 files changed, 102 insertions(+), 5 deletions(-)
diff --git a/cpukit/score/cpu/arm/include/rtems/score/cpuimpl.h
b/cpukit/score/cpu/arm/include/rtems/score/cpuimpl.h
index edc452530f..d007a7982b 100644
--- a/cpukit/score/cpu/arm/include/rtems/score/cpuimpl.h
+++ b/cpukit/score/cpu/arm/include/rtems/score/cpuimpl.h
@@ -106,6 +106,11 @@ void _CPU_Context_volatile_clobber( uintptr_t pattern );
void _CPU_Context_validate( uintptr_t pattern );
+RTEMS_INLINE_ROUTINE void _CPU_Instruction_no_operation( void )
+{
+ __asm__ volatile ( "nop" );
+}
+
#ifdef __cplusplus
}
#endif
diff --git a/cpukit/score/cpu/bfin/include/rtems/score/cpuimpl.h
b/cpukit/score/cpu/bfin/include/rtems/score/cpuimpl.h
index ee188bebce..5d8bd77161 100644
--- a/cpukit/score/cpu/bfin/include/rtems/score/cpuimpl.h
+++ b/cpukit/score/cpu/bfin/include/rtems/score/cpuimpl.h
@@ -37,6 +37,11 @@ RTEMS_INLINE_ROUTINE void _CPU_Context_validate( uintptr_t
pattern )
}
}
+RTEMS_INLINE_ROUTINE void _CPU_Instruction_no_operation( void )
+{
+ __asm__ volatile ( "nop" );
+}
+
#ifdef __cplusplus
}
#endif
diff --git a/cpukit/score/cpu/epiphany/include/rtems/score/cpuimpl.h
b/cpukit/score/cpu/epiphany/include/rtems/score/cpuimpl.h
index ee188bebce..5d8bd77161 100644
--- a/cpukit/score/cpu/epiphany/include/rtems/score/cpuimpl.h
+++ b/cpukit/score/cpu/epiphany/include/rtems/score/cpuimpl.h
@@ -37,6 +37,11 @@ RTEMS_INLINE_ROUTINE void _CPU_Context_validate( uintptr_t
pattern )
}
}
+RTEMS_INLINE_ROUTINE void _CPU_Instruction_no_operation( void )
+{
+ __asm__ volatile ( "nop" );
+}
+
#ifdef __cplusplus
}
#endif
diff --git a/cpukit/score/cpu/i386/include/rtems/score/cpuimpl.h
b/cpukit/score/cpu/i386/include/rtems/score/cpuimpl.h
index ee188bebce..5d8bd77161 100644
--- a/cpukit/score/cpu/i386/include/rtems/score/cpuimpl.h
+++ b/cpukit/score/cpu/i386/include/rtems/score/cpuimpl.h
@@ -37,6 +37,11 @@ RTEMS_INLINE_ROUTINE void _CPU_Context_validate( uintptr_t
pattern )
}
}
+RTEMS_INLINE_ROUTINE void _CPU_Instruction_no_operation( void )
+{
+ __asm__ volatile ( "nop" );
+}
+
#ifdef __cplusplus
}
#endif
diff --git a/cpukit/score/cpu/lm32/include/rtems/score/cpuimpl.h
b/cpukit/score/cpu/lm32/include/rtems/score/cpuimpl.h
index ee188bebce..5d8bd77161 100644
--- a/cpukit/score/cpu/lm32/include/rtems/score/cpuimpl.h
+++ b/cpukit/score/cpu/lm32/include/rtems/score/cpuimpl.h
@@ -37,6 +37,11 @@ RTEMS_INLINE_ROUTINE void _CPU_Context_validate( uintptr_t
pattern )
}
}
+RTEMS_INLINE_ROUTINE void _CPU_Instruction_no_operation( void )
+{
+ __asm__ volatile ( "nop" );
+}
+
#ifdef __cplusplus
}
#endif
diff --git a/cpukit/score/cpu/m32c/include/rtems/score/cpuimpl.h
b/cpukit/score/cpu/m32c/include/rtems/score/cpuimpl.h
index ee188bebce..5d8bd77161 100644
--- a/cpukit/score/cpu/m32c/include/rtems/score/cpuimpl.h
+++ b/cpukit/score/cpu/m32c/include/rtems/score/cpuimpl.h
@@ -37,6 +37,11 @@ RTEMS_INLINE_ROUTINE void _CPU_Context_validate( uintptr_t
pattern )
}
}
+RTEMS_INLINE_ROUTINE void _CPU_Instruction_no_operation( void )
+{
+ __asm__ volatile ( "nop" );
+}
+
#ifdef __cplusplus
}
#endif
diff --git a/cpukit/score/cpu/m68k/include/rtems/score/cpuimpl.h
b/cpukit/score/cpu/m68k/include/rtems/score/cpuimpl.h
index ee188bebce..5d8bd77161 100644
--- a/cpukit/score/cpu/m68k/include/rtems/score/cpuimpl.h
+++ b/cpukit/score/cpu/m68k/include/rtems/score/cpuimpl.h
@@ -37,6 +37,11 @@ RTEMS_INLINE_ROUTINE void _CPU_Context_validate( uintptr_t
pattern )
}
}
+RTEMS_INLINE_ROUTINE void
[PATCH 3/3] score: Add _CPU_Instruction_illegal()
On some architectures/simulators it is difficult to provoke an
exception with misaligned or illegal data loads. Use an illegal
instruction instead.
Update #3433.
---
cpukit/score/cpu/arm/include/rtems/score/cpuimpl.h | 5 +
cpukit/score/cpu/bfin/include/rtems/score/cpuimpl.h | 5 +
cpukit/score/cpu/epiphany/include/rtems/score/cpuimpl.h | 5 +
cpukit/score/cpu/i386/include/rtems/score/cpuimpl.h | 5 +
cpukit/score/cpu/lm32/include/rtems/score/cpuimpl.h | 5 +
cpukit/score/cpu/m32c/include/rtems/score/cpuimpl.h | 5 +
cpukit/score/cpu/m68k/include/rtems/score/cpuimpl.h | 5 +
cpukit/score/cpu/mips/include/rtems/score/cpuimpl.h | 5 +
cpukit/score/cpu/moxie/include/rtems/score/cpuimpl.h| 5 +
cpukit/score/cpu/nios2/include/rtems/score/cpuimpl.h| 5 +
cpukit/score/cpu/no_cpu/include/rtems/score/cpuimpl.h | 10 ++
cpukit/score/cpu/or1k/include/rtems/score/cpuimpl.h | 5 +
cpukit/score/cpu/powerpc/include/rtems/score/cpuimpl.h | 5 +
cpukit/score/cpu/riscv/include/rtems/score/cpuimpl.h| 5 +
cpukit/score/cpu/sh/include/rtems/score/cpuimpl.h | 5 +
cpukit/score/cpu/sparc/include/rtems/score/cpuimpl.h| 5 +
cpukit/score/cpu/sparc64/include/rtems/score/cpuimpl.h | 5 +
cpukit/score/cpu/v850/include/rtems/score/cpuimpl.h | 5 +
cpukit/score/cpu/x86_64/include/rtems/score/cpuimpl.h | 5 +
testsuites/sptests/spfatal26/init.c | 13 ++---
20 files changed, 110 insertions(+), 3 deletions(-)
diff --git a/cpukit/score/cpu/arm/include/rtems/score/cpuimpl.h
b/cpukit/score/cpu/arm/include/rtems/score/cpuimpl.h
index d007a7982b..b856349db3 100644
--- a/cpukit/score/cpu/arm/include/rtems/score/cpuimpl.h
+++ b/cpukit/score/cpu/arm/include/rtems/score/cpuimpl.h
@@ -106,6 +106,11 @@ void _CPU_Context_volatile_clobber( uintptr_t pattern );
void _CPU_Context_validate( uintptr_t pattern );
+RTEMS_INLINE_ROUTINE void _CPU_Instruction_illegal( void )
+{
+ __asm__ volatile ( "udf" );
+}
+
RTEMS_INLINE_ROUTINE void _CPU_Instruction_no_operation( void )
{
__asm__ volatile ( "nop" );
diff --git a/cpukit/score/cpu/bfin/include/rtems/score/cpuimpl.h
b/cpukit/score/cpu/bfin/include/rtems/score/cpuimpl.h
index 5d8bd77161..78b87ef981 100644
--- a/cpukit/score/cpu/bfin/include/rtems/score/cpuimpl.h
+++ b/cpukit/score/cpu/bfin/include/rtems/score/cpuimpl.h
@@ -37,6 +37,11 @@ RTEMS_INLINE_ROUTINE void _CPU_Context_validate( uintptr_t
pattern )
}
}
+RTEMS_INLINE_ROUTINE void _CPU_Instruction_illegal( void )
+{
+ __asm__ volatile ( ".word 0" );
+}
+
RTEMS_INLINE_ROUTINE void _CPU_Instruction_no_operation( void )
{
__asm__ volatile ( "nop" );
diff --git a/cpukit/score/cpu/epiphany/include/rtems/score/cpuimpl.h
b/cpukit/score/cpu/epiphany/include/rtems/score/cpuimpl.h
index 5d8bd77161..78b87ef981 100644
--- a/cpukit/score/cpu/epiphany/include/rtems/score/cpuimpl.h
+++ b/cpukit/score/cpu/epiphany/include/rtems/score/cpuimpl.h
@@ -37,6 +37,11 @@ RTEMS_INLINE_ROUTINE void _CPU_Context_validate( uintptr_t
pattern )
}
}
+RTEMS_INLINE_ROUTINE void _CPU_Instruction_illegal( void )
+{
+ __asm__ volatile ( ".word 0" );
+}
+
RTEMS_INLINE_ROUTINE void _CPU_Instruction_no_operation( void )
{
__asm__ volatile ( "nop" );
diff --git a/cpukit/score/cpu/i386/include/rtems/score/cpuimpl.h
b/cpukit/score/cpu/i386/include/rtems/score/cpuimpl.h
index 5d8bd77161..78b87ef981 100644
--- a/cpukit/score/cpu/i386/include/rtems/score/cpuimpl.h
+++ b/cpukit/score/cpu/i386/include/rtems/score/cpuimpl.h
@@ -37,6 +37,11 @@ RTEMS_INLINE_ROUTINE void _CPU_Context_validate( uintptr_t
pattern )
}
}
+RTEMS_INLINE_ROUTINE void _CPU_Instruction_illegal( void )
+{
+ __asm__ volatile ( ".word 0" );
+}
+
RTEMS_INLINE_ROUTINE void _CPU_Instruction_no_operation( void )
{
__asm__ volatile ( "nop" );
diff --git a/cpukit/score/cpu/lm32/include/rtems/score/cpuimpl.h
b/cpukit/score/cpu/lm32/include/rtems/score/cpuimpl.h
index 5d8bd77161..78b87ef981 100644
--- a/cpukit/score/cpu/lm32/include/rtems/score/cpuimpl.h
+++ b/cpukit/score/cpu/lm32/include/rtems/score/cpuimpl.h
@@ -37,6 +37,11 @@ RTEMS_INLINE_ROUTINE void _CPU_Context_validate( uintptr_t
pattern )
}
}
+RTEMS_INLINE_ROUTINE void _CPU_Instruction_illegal( void )
+{
+ __asm__ volatile ( ".word 0" );
+}
+
RTEMS_INLINE_ROUTINE void _CPU_Instruction_no_operation( void )
{
__asm__ volatile ( "nop" );
diff --git a/cpukit/score/cpu/m32c/include/rtems/score/cpuimpl.h
b/cpukit/score/cpu/m32c/include/rtems/score/cpuimpl.h
index 5d8bd77161..78b87ef981 100644
--- a/cpukit/score/cpu/m32c/include/rtems/score/cpuimpl.h
+++ b/cpukit/score/cpu/m32c/include/rtems/score/cpuimpl.h
@@ -37,6 +37,11 @@ RTEMS_INLINE_ROUTINE void _CPU_Context_validate( uintptr_t
pattern )
}
}
+RTEMS_INLINE_ROUTINE void _CPU_Instruction_illegal( void )
+{
+ __asm__ volatile ( ".word 0" );
+}
+
RTEMS_INLINE_ROUTINE
