Re: [PATCH] Fix 'build_max_size_human' ref. before assignment
On 13/01/2019 23:17, Chris Johns wrote: On 14/1/19 8:05 am, Chris Johns wrote: On 11/1/19 4:31 pm, Sebastian Huber wrote: - Am 11. Jan 2019 um 0:11 schrieb Chris Johns chr...@rtems.org: On 10/1/19 11:17 pm, Sebastian Huber wrote: This patch resulted in this mail report issue: Your mail to 'build' with the subject Build Linux: FAILED 6/rtems-epiphany on x86_64-linux-gnu (epiphany-rtems6-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885-newlib-fbd3835384fa586fd32ce80280d81bb51ab042ba-x86_64-linux-gnu-1) Is being held until the list moderator can review it for approval. The reason it is being held: Message body is too big: 1093190 bytes with a limit of 256 KB Are you asking for the size limit on the list to be raised? No, but is this the normal size for a failed report? It should not be. I will accept the post and then we can see the reason. The report captures the last part of the build and it looks like the lines in the section of the libstdc++ library being built are long. The use of full length hashes in gcc and newlib has increased the path lengths. I increased the number of lines captured a while ago because the number of cores being used when building meant distance in the output between the error and the end of the log can be a long way. Maybe a smarter parser should be added and just the error logged? When I look for tool chain build errors I simply go to the end of the log file and then search backwards for "error:". -- 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: Status of RISCV port on sis
Sounds great. It might be worth it to add an entry for sis here [1] [1] https://github.com/riscv/riscv-wiki/wiki/RISC-V-Software-Status On Sun, 13 Jan 2019 at 15:30, Jiri Gaisler wrote: > > > On 1/13/19 2:48 PM, Sebastian Huber wrote: > > - Am 13. Jan 2019 um 0:09 schrieb Jiri Gaisler j...@gaisler.se: > > > >> On 1/11/19 1:36 PM, Jiri Gaisler wrote: > >>> On 1/9/19 10:46 AM, Sebastian Huber wrote: > Hello Jiri, > > could you please rebase your work to this RTEMS commit: > > https://git.rtems.org/rtems/commit/?id=b9ffc41c9678fb3c5386c1a6ab394656ec85dbc6 > > >>> This works fine for me - I can now pass all uni-processor tests. On SMP, > >>> I still > >>> have a few fails but I think they are related to the simulator and the > >>> compressed RISC-V instruction set. I will investigate further ... > >> The atomic LR/SC instructions did not work as expected in the simulator, > >> which > >> caused the failures. After cleaning that up, all tests now pass. I have > >> tested > >> up to 4 cpus and various frequencies and time slots in the sim with no > >> fails, > >> so it seems fairly robust. I will clean up my bsp sources and post the > >> patches > >> on the list for review. I will also provide a patch for the RISC-V version > >> of > >> gdb-8.2 to add the new sim. Thanks for the help to get this going..! > >> > >> > >> $ rtems-test --rtems-bsp=riscv-sis riscv-rtems5/c/grlib/testsuites > >> --log=all.txt > >> > >> > >> Passed:630 > >> Failed: 0 > >> User Input: 5 > >> Expected Fail: 0 > >> Indeterminate: 0 > >> Benchmark: 3 > >> Timeout: 0 > >> Invalid: 0 > >> Wrong Version: 0 > >> Wrong Build: 0 > >> Wrong Tools: 0 > >> -- > >> Total: 638 > >> User Input: > >> monitor.exe > >> termios.exe > >> top.exe > >> capture.exe > >> fileio.exe > >> Benchmark: > >> linpack.exe > >> dhrystone.exe > >> whetstone.exe > >> Average test time: 0:00:00.732410 > >> Testing time : 0:07:47.277261 > > This is really great. This is the second free simulator (the other is SIS) > > which is capable enough to run all tests successfully. We should think > > about making a RISC-V BSP the default in the documentation instead of erc32. > > Good idea. ERC32 is getting old and is not really known outside the space > community. I still need to add the M, F and D extensions to the RISC-V sim > though, so we can test all of the (32-bit) combinations. I should be able to > do this next week and then I can post all patches for review and testing. > Code coverage support is still on the list, it will follow once the sim has > settled a bit ... > > > > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel -- Hesham ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GNU ld --wrap limitations
On 15/1/19 5:54 pm, Sebastian Huber wrote: > On 14/01/2019 23:33, Chris Johns wrote: >> On 14/1/19 8:22 pm, Sebastian Huber wrote: >>> while testing the event recording with the libbsd I noticed a GNU ld --wrap >>> limitation: >>> >>> https://www.sourceware.org/ml/binutils/2018-12/msg00210.html >>> >> I have been watching the thread. There is a limit to what binutils or any >> method >> can do as compiler technology improves. >> >> An example we currently build RTEMS with a single C file on the command >> line, I >> wonder what RTEMS's score would look like if all C files are passed to the >> compiler at once and it can optimise over all files as if included in a >> single >> source file. A number of externals we current have would not be visible and >> traceable using this method. > > If I use -flto in my simple test case, then the wrapping via LD doesn't work > at > all. LTO is a compiler based optimiser run at link time. It is like the example I gave of compiling all the source with a single gcc command. > >> >>> It turned out that the wrapping doesn't work for references internal to a >>> translation unit. >> The reach for this issue is changing as the push to better optimise the >> generated code. If the compiler can remove or optimise an external call as an >> internally reference it will. > > This is not a compiler optimization issue. I view this as an optimisation to speed up the linking process by not letting it know there is a reference. :) > The wrapping doesn't work with -O0 > for all references internal to the translation unit. I doubt it would have. This about the generated code. Inlining of code can also happen where a function instance is present for external linkage and the same code is internally inlined. You see this with breakpoints that are not hit because the external instance of the function is the breakpoint. > You see "call h" and "call puts". The h() function is defined in the > translation > unit. This call is not wrapped. I have seen this happen but never looked deeper into the exact reason. > >> >>> My hope was that the RTEMS Trace Linker doesn't have this >>> limitation, but the documentation says (user manual): >>> >>> "The trace linker’s major role is to wrap functions in the existing >>> executable >>> with trace code. The >>> directions on how to wrap application functions is provided by the generator >>> configuration. The >>> wrapping function uses a GNU linker option called –wrap=symbol." >>> >> https://devel.rtems.org/wiki/Developer/Tracing/Trace_Linker#Limitation >> >> ... highlights the need for an external reference. > > It says > > "Functions must have external linkage to allow the linker to wrap the symbol." > > this is not the same as > > "highlights the need for an external reference" > > You need an undefined reference to a symbol. References inside a translation > unit are apparently not undefined references. Does DWARF give us any better insight and the information needed? > It took me a while to figure out why the wrapping of ether_input() and > ether_output() didn't work. That is frustrating. > I tried to improve the LD documentation a bit as a result. I saw this. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Fix 'build_max_size_human' ref. before assignment
On 15/1/19 11:31 pm, Sebastian Huber wrote: > On 13/01/2019 23:17, Chris Johns wrote: >> On 14/1/19 8:05 am, Chris Johns wrote: >>> On 11/1/19 4:31 pm, Sebastian Huber wrote: - Am 11. Jan 2019 um 0:11 schrieb Chris Johns chr...@rtems.org: > On 10/1/19 11:17 pm, Sebastian Huber wrote: >> This patch resulted in this mail report issue: >> >> Your mail to 'build' with the subject >> >> Build Linux: FAILED 6/rtems-epiphany on x86_64-linux-gnu >> (epiphany-rtems6-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885-newlib-fbd3835384fa586fd32ce80280d81bb51ab042ba-x86_64-linux-gnu-1) >> >> >> >> >> Is being held until the list moderator can review it for approval. >> >> The reason it is being held: >> >> Message body is too big: 1093190 bytes with a limit of 256 KB >> > Are you asking for the size limit on the list to be raised? No, but is this the normal size for a failed report? >>> It should not be. I will accept the post and then we can see the reason. >>> >> The report captures the last part of the build and it looks like the lines in >> the section of the libstdc++ library being built are long. The use of full >> length hashes in gcc and newlib has increased the path lengths. >> >> I increased the number of lines captured a while ago because the number of >> cores >> being used when building meant distance in the output between the error and >> the >> end of the log can be a long way. >> >> Maybe a smarter parser should be added and just the error logged? > > When I look for tool chain build errors I simply go to the end of the log file > and then search backwards for "error:". > There are linker and I think assembler errors which do not work as well ... https://git.rtems.org/rtems-tools/tree/tester/rt/check.py#n447 Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Fix 'build_max_size_human' ref. before assignment
On 16/01/2019 02:27, Chris Johns wrote: On 15/1/19 11:31 pm, Sebastian Huber wrote: On 13/01/2019 23:17, Chris Johns wrote: On 14/1/19 8:05 am, Chris Johns wrote: On 11/1/19 4:31 pm, Sebastian Huber wrote: - Am 11. Jan 2019 um 0:11 schrieb Chris Johns chr...@rtems.org: On 10/1/19 11:17 pm, Sebastian Huber wrote: This patch resulted in this mail report issue: Your mail to 'build' with the subject Build Linux: FAILED 6/rtems-epiphany on x86_64-linux-gnu (epiphany-rtems6-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885-newlib-fbd3835384fa586fd32ce80280d81bb51ab042ba-x86_64-linux-gnu-1) Is being held until the list moderator can review it for approval. The reason it is being held: Message body is too big: 1093190 bytes with a limit of 256 KB Are you asking for the size limit on the list to be raised? No, but is this the normal size for a failed report? It should not be. I will accept the post and then we can see the reason. The report captures the last part of the build and it looks like the lines in the section of the libstdc++ library being built are long. The use of full length hashes in gcc and newlib has increased the path lengths. I increased the number of lines captured a while ago because the number of cores being used when building meant distance in the output between the error and the end of the log can be a long way. Maybe a smarter parser should be added and just the error logged? When I look for tool chain build errors I simply go to the end of the log file and then search backwards for "error:". There are linker and I think assembler errors which do not work as well ... https://git.rtems.org/rtems-tools/tree/tester/rt/check.py#n447 Ok, it is not that simple. I guess we have to improve this each time we see a 1MiB error log context. -- 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: Rework parts of the user manual
On 14/01/2019 07:37, Sebastian Huber wrote: On 13/01/2019 23:04, Chris Johns wrote: On 12/1/19 1:59 am, Sebastian Huber wrote: this is the first patch set targeting the user manual. My goal is to write an easy to follow quick start chapter which references other chapters for the details. Is there a build of this I could please review? https://ftp.rtems.org/pub/rtems/people/sebh/user.pdf Had you time to look at the document? I would like to continue with work in the Quick Start chapter and this makes only sense if the pending patches are merged. -- 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
