Re: [PATCH 11/25] Merge sapi/Makefile.am into cpukit/Makefile.am
On 24/09/2018 08:35, Chris Johns wrote: On 24/09/2018 15:44, Sebastian Huber wrote: A quick and dirty fix could look like this: diff --git a/tester/rtems/testing/coverage/symbol-sets.ini b/tester/rtems/testing/coverage/symbol-sets.ini index 2685ef4..d9afe85 100644 --- a/tester/rtems/testing/coverage/symbol-sets.ini +++ b/tester/rtems/testing/coverage/symbol-sets.ini @@ -29,9 +29,10 @@ # [symbol-sets] -sets = score,rtems,sapi,libdl,posix,libirfs,libdosfs,libdevfs,libimfs,libcsupport,libbspcmdline,libcpuuse,libstackchk,libfsmount,libstringto,libdevnull,libdumpbuf,libblock +sets = cpukit,score,rtems,sapi,libdl,posix,libirfs,libdosfs,libdevfs,libimfs,libcsupport,libbspcmdline,libcpuuse,libstackchk,libfsmount,libstringto,libdevnull,libdumpbuf,libblock [libraries] +cpukit = @BUILD-TARGET@/c/@BSP@/cpukit/libcpukit.a score = @BUILD-TARGET@/c/@BSP@/cpukit/score/libscore.a rtems = @BUILD-TARGET@/c/@BSP@/cpukit/rtems/librtems.a sapi = @BUILD-TARGET@/c/@BSP@/cpukit/sapi/libsapi.a Then build up a regular expression using all libraries other than libcpukit.a, e.g. '(cpukit/score)|(cpukit/rtems)|(cpukit/sapi)'. Then use this regular expression in cache.load_symbols (symbols, regex, true) to filter the symbols. We need the complete set of symbols for a "component" so we can determine the level of coverage. I am not sure we can have a symbols in more than one component, ie cpukit and cpukit/score? The approach above would keep the cover tool compatible with the existing build tree and the new build tree with a reduced library set. Is this grouping on source path or still via libraries? Using internal libraries seems fragile to me. If we completely flatten the build to create a single library, which could happen, we would need to use source paths. The grouping would be based on the source path. We would have to go from the symbol to the ELF file to the DWARF info of the compilation unit. All info should be directly via the ELF and DWARF format. I do not know if we need to reference the ELF symbol table or we can just use the DWARF CU data. The use of objdump should be avoided. I only briefly look into this, but you have to go from the rld::symbols::symbol to the DWARF info somehow if DesiredSymbols.cc:95 is the right spot to add this stuff. -- 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] testsuite/dl02: Fix a bug to check that dl02-o2 is loaded
---
testsuites/libtests/dl02/dl-load.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/testsuites/libtests/dl02/dl-load.c
b/testsuites/libtests/dl02/dl-load.c
index 601d621..2189773 100644
--- a/testsuites/libtests/dl02/dl-load.c
+++ b/testsuites/libtests/dl02/dl-load.c
@@ -53,7 +53,7 @@ int dl_load_test(void)
if (!o1)
return 1;
o2 = dl_load_obj("/dl02-o2.o");
- if (!o1)
+ if (!o2)
return 1;
#if 0
--
2.7.4
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 11/25] Merge sapi/Makefile.am into cpukit/Makefile.am
On 24/09/2018 17:55, Sebastian Huber wrote: > On 24/09/2018 08:35, Chris Johns wrote: >> On 24/09/2018 15:44, Sebastian Huber wrote: >>> A quick and dirty fix could look like this: >>> >>> diff --git a/tester/rtems/testing/coverage/symbol-sets.ini >>> b/tester/rtems/testing/coverage/symbol-sets.ini >>> index 2685ef4..d9afe85 100644 >>> --- a/tester/rtems/testing/coverage/symbol-sets.ini >>> +++ b/tester/rtems/testing/coverage/symbol-sets.ini >>> @@ -29,9 +29,10 @@ >>> # >>> >>> [symbol-sets] >>> -sets = >>> score,rtems,sapi,libdl,posix,libirfs,libdosfs,libdevfs,libimfs,libcsupport,libbspcmdline,libcpuuse,libstackchk,libfsmount,libstringto,libdevnull,libdumpbuf,libblock >>> >>> >>> +sets = >>> cpukit,score,rtems,sapi,libdl,posix,libirfs,libdosfs,libdevfs,libimfs,libcsupport,libbspcmdline,libcpuuse,libstackchk,libfsmount,libstringto,libdevnull,libdumpbuf,libblock >>> >>> >>> >>> [libraries] >>> +cpukit = @BUILD-TARGET@/c/@BSP@/cpukit/libcpukit.a >>> score = @BUILD-TARGET@/c/@BSP@/cpukit/score/libscore.a >>> rtems = @BUILD-TARGET@/c/@BSP@/cpukit/rtems/librtems.a >>> sapi = @BUILD-TARGET@/c/@BSP@/cpukit/sapi/libsapi.a >>> >>> Then build up a regular expression using all libraries other than >>> libcpukit.a, >>> e.g. '(cpukit/score)|(cpukit/rtems)|(cpukit/sapi)'. Then use this regular >>> expression in cache.load_symbols (symbols, regex, true) to filter the >>> symbols. >> We need the complete set of symbols for a "component" so we can determine the >> level of coverage. I am not sure we can have a symbols in more than one >> component, ie cpukit and cpukit/score? > > The approach above would keep the cover tool compatible with the existing > build > tree and the new build tree with a reduced library set. > The tool is under going change and the current format is new. I do not see an overriding reason to maintain backward compatibility. >> >> Is this grouping on source path or still via libraries? Using internal >> libraries >> seems fragile to me. If we completely flatten the build to create a single >> library, which could happen, we would need to use source paths. > > The grouping would be based on the source path. > Agreed. >> >>> We would have to go from the symbol to the ELF file to the DWARF info of the >>> compilation unit. >> All info should be directly via the ELF and DWARF format. I do not know if we >> need to reference the ELF symbol table or we can just use the DWARF CU data. >> The >> use of objdump should be avoided. > > I only briefly look into this, but you have to go from the > rld::symbols::symbol > to the DWARF info somehow if DesiredSymbols.cc:95 is the right spot to add > this > stuff. > You could be right. The DWARF info will contain all symbols and more. Should these files move to the rtems.git repo? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 3/3] c11_thread01/test.c: Fix minor issues
---
c11/c11_thread01/test.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/c11/c11_thread01/test.c b/c11/c11_thread01/test.c
index 831bcc7..12b9a64 100644
--- a/c11/c11_thread01/test.c
+++ b/c11/c11_thread01/test.c
@@ -19,12 +19,14 @@ void initialize_subsystem_once(void)
{
printf("*** Subsystem initialization should only happen once\n");
}
+
void initialize_subsystem(void)
{
- static once_flag initialize_subsystem_only_once= ONCE_FLAG_INIT;
+ static once_flag initialize_subsystem_only_once = ONCE_FLAG_INIT;
call_once(&initialize_subsystem_only_once, initialize_subsystem_once);
}
+
int Thread1_Body(void *arg)
{
thrd_t *t = (thrd_t *) arg;
@@ -42,7 +44,7 @@ int Thread1_Body(void *arg)
puts("Thread1 - join Thread2" );
rc = thrd_join(thread2, &result);
assert(rc == thrd_success);
- printf("Thread1 - thread1 exited with %d\n", result);
+ printf("Thread1 - thread2 exited with %d\n", result);
puts("Thread1 - exit" );
thrd_exit(0);
@@ -94,7 +96,7 @@ int main(int argc, char **argv)
rc = thrd_equal(thread1, thread1);
assert(rc != 0);
- puts("main - sleep and let Thread2 run");
+ puts("main - sleep and let other threads run");
rc = thrd_sleep(&delay, NULL);
assert(rc == 0);
--
1.8.3.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 1/3] rtems_waf: Update to pick up rtems5 not having bin/
--- rtems_waf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rtems_waf b/rtems_waf index de75eec..c0d52d5 16 --- a/rtems_waf +++ b/rtems_waf @@ -1 +1 @@ -Subproject commit de75eecdc19c97c6e0e2fb902ffab3dbbf089eb5 +Subproject commit c0d52d5fcd9cad9b63479b92a0abf4fa5f5c99f3 -- 1.8.3.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 2/3] README.waf: Update waf URL and sis->erc32
--- README.waf | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/README.waf b/README.waf index dd339f4..bf379ae 100644 --- a/README.waf +++ b/README.waf @@ -3,7 +3,7 @@ RTEMS Waf You can find the Waf project here: - http://code.google.com/p/waf/ + https://waf.io Simple instructions on How to set up Waf is here: @@ -28,14 +28,14 @@ Steps 5. Configure with your specific settings. In this case the path to the tools and RTEMS and provided on the command line and so do not need to be in your - path or environment [1] and we limit the build to 'sparc/sis' BSP: + path or environment [1] and we limit the build to 'sparc/erc32' BSP: $ waf configure --rtems=$HOME/Development/rtems/build/4.11 \ --rtems-tools=$HOME/Development/rtems/4.11 \ ---rtems-bsps=sparc/sis +--rtems-bsps=sparc/erc32 You can use '--rtems-archs=sparc,i386' or - '--rtems-bsps=sparc/sis,i386/pc586' to build for more than BSP at a time. + '--rtems-bsps=sparc/erc32,i386/pc586' to build for more than BSP at a time. 6. Build: -- 1.8.3.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 11/25] Merge sapi/Makefile.am into cpukit/Makefile.am
On 25/09/2018 00:27, Chris Johns wrote: We would have to go from the symbol to the ELF file to the DWARF info of the compilation unit. All info should be directly via the ELF and DWARF format. I do not know if we need to reference the ELF symbol table or we can just use the DWARF CU data. The use of objdump should be avoided. I only briefly look into this, but you have to go from the rld::symbols::symbol to the DWARF info somehow if DesiredSymbols.cc:95 is the right spot to add this stuff. You could be right. The DWARF info will contain all symbols and more. Should these files move to the rtems.git repo? The *.ini files or which files? I would leave the files where they are and fix the issues first. Afterwards I would think about moving files around across repositories. -- 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 11/25] Merge sapi/Makefile.am into cpukit/Makefile.am
On 25/09/2018 15:30, Sebastian Huber wrote: > On 25/09/2018 00:27, Chris Johns wrote: > We would have to go from the symbol to the ELF file to the DWARF info of > the > compilation unit. All info should be directly via the ELF and DWARF format. I do not know if we need to reference the ELF symbol table or we can just use the DWARF CU data. The use of objdump should be avoided. >>> I only briefly look into this, but you have to go from the >>> rld::symbols::symbol >>> to the DWARF info somehow if DesiredSymbols.cc:95 is the right spot to add >>> this >>> stuff. >>> >> You could be right. The DWARF info will contain all symbols and more. >> >> Should these files move to the rtems.git repo? > > The *.ini files or which files? Just the INI files, the files which describe the data. > I would leave the files where they are and fix > the issues first. Afterwards I would think about moving files around across > repositories. Oh of course, that is fine and it makes sense. I would like to understand the tasks and agree on them. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
