Open Source Tools Support’s reputation

Open Source Tools Support's reputation

Total 637

0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,10,0,0,10,0,0,0,0,0,0,0,1,0

May 27, 2021 Commented Dear NoMaY-san, Thank you once again for your feedback. We will inform the team responsible for maintaining the project generated files to change iodefine.h according to your proposal. The LLVM RL78 compiler will be improved as soon as possible. __ Best regards, The Open Source Tools Team

+10

May 27, 2021 Answered LLVM-RL78 clang assembler shows stack dump when wrong assembly code is written

May 26, 2021 Commented Dear NoMaY-san, We have investigated the issue and we can confirm that the code generated by GNURL78 is incorrect. This is indeed one of the reasons GCC RL78 generates smaller code. Although not optimal for code size, the code generated by LLVM RL78 is correct. Please let us know if your intention is to continue your development process with the GCC RL78 compiler, or if you are willing to switch to the new LLVM RL78 compiler? We appreciate the feedback we are receiving from you. We are actively improving and enhancing the LLVM RL78 compiler, and you will always be able to get the latest updates performed to it, both in terms of runtime performance and code size enhancements. __ Best regards, The Open Source Tools Team

May 21, 2021 Commented Dear NoMaY-san, We are grateful for your feedback and we are already on a path to improve this in the next release of LLVM RL78. __ Best regards, The Open Source Tools Team

May 4, 2021 Commented Hello, We can assure you that the conversion works. However, there are a few known open issues, which we are hopeful will see the light of day in e2studio 2021-7. You may check the release notes of e2studio 2021-04 to find out more information about these. __ Thank you, The Open Source Tools Team

+10

May 4, 2021 Answered Where is the document of LLVM-RL78 ABI

April 28, 2021 Commented Hello, Thank you for reaching out to us! We passed your inquiry to the team that handles Smart Configurator and Code Generator and we will come back with a reply as soon as possible. __ Thank you for your patience, The Open Source Tools Team

April 13, 2021 Commented Dear NoMaY, While investigating this and looking into the projects you attached we discovered that the difference comes from where you add the options (library linking options) in the linking command. The linker searches for external functions from left to right in the libraries specified on the command line. This means that a library containing the definition of a function should appear after any source files or object files which use it. So the following is not correct: rx-elf-gcc %OPTIONS% -o "HardwareDebug/TestGUNRXprintf.elf" HardwareDebug/TestGUNRXprintf.o HardwareDebug/hwinit.o HardwareDebug/inthandler.o HardwareDebug/start.o HardwareDebug/vects.o -T "generate/linker_script.ld" Instead, adding the options after the object files is: rx-elf-gcc -o "HardwareDebug/TestGUNRXprintf.elf" HardwareDebug/TestGUNRXprintf.o HardwareDebug/hwinit.o HardwareDebug/inthandler.o HardwareDebug/start.o HardwareDebug/vects.o %OPTIONS% -T "generate/linker_script.ld" You can observe the same behavior when using e2 studio: the library linking options are added after the object files. __ Best regards, The Open Source Tools Team

+10

March 30, 2021 Answered About Our Services

February 25, 2021 Commented Dear user, We are happy to report that this issue should be resolved in the new 2020q4 release of the GCC for Renesas RX toolchain, present on our website for download at: https://gcc-renesas.com/downloads/download.php?f=rx/8.3.0.202004/gcc-8.3.0.202004-GNURX-ELF.exe If you have any further questions about the issue, please let us know. __ Thank you, The GNU Tools Team

January 25, 2021 Commented @NoMaY-jp: thank you very much for your insights, they are very valuable, as always. We also highly appreciate your due diligence in assisting users whenever possible.

+10

December 26, 2020 Answered add RL78 toolchain to e2 in linux

October 16, 2020 Commented Dear user, Please note that while we are offering support for the toolchains that we build, but we are not offering support for e2studio itself - a dedicated forum for e2studio help may be found at renesasrulz.com, another useful resource which has been mentioned several times in the forum herein. The initial user above has not provided any steps required for us to reproduce the problem. When we had asked for that, he had not replied any longer. Possibly because, just like yourself, he had realized that he had selected the wrong target devices when choosing to look for toolchains - therefore, the mishap that we have described earlier, appearing on the user-side. This is not a problem with the toolchain, and as it turns out, also not a problem with e2studio (where it actually works like that by design, an intended behavior) - this was an omission on the user side. We're glad to see things worked out. Should you have any actual technical issues we can help with, please feel free to reach out to us at any time. – Thank you, The GNU Tools Team

October 16, 2020 Commented Dear user, That is an incorrect claim, and in fact a mishap on the user-side. As expected under an enterprise-focused development environment, once you fire up the e2studio installer and you choose to have support for a specific platform (e.g. RX), then the installer will only look for relevant items (e.g. RX toolchains) pertaining to the selection you had made. Therefore, by choosing RX support, you only get relevant RX-focused toolchains. Should you have any more concerns, feel free to let us know. We'll be happy to help you out, if we can.

+10

July 31, 2020 Answered Toolchain usage in docker

June 15, 2020 Commented Hello, Thank you for your reply! The Unified Assembler Language - the one you are using in your sample code- is the common syntax for ARM and Thumb instructions. It supersedes earlier versions of both the ARM and Thumb assembler languages. The .syntax unified is needed if you want to use the Unified Assembler Language as for GCC the default is not unified. https://sourceware.org/binutils/docs/as/ARM_002dInstruction_002dSet.html#ARM_002dInstruction_002dSet You can however try and replace the .thumb directive by adding the -mthumb option to the assembler/ compiler. It looks like cortex-M23 and M33 are also Thumb only processors, so you will also need these directives. __ Thank you, The GNU Tools Team

May 1, 2020 Commented Thank you for sharing the solution that you have found! To answer your question, we are currently considering the possibility of an official Debian package for the toolchain. Once a decision has been reached, we will announce it on our website. __ Thank you, The GNU Tools Team

January 23, 2020 Selected answer “undefined reference to `memset’” bug

+10

January 22, 2020 Answered “undefined reference to `memset’” bug

December 14, 2019 Commented Hello, Thank you for your patience! After a thorough investigation, we concluded that the displayed behavior, even if it resembles a compiler issue, is not constituting a compiler bug. Although... typedef void (*numentry_t)(int cnt, int arg1, …); typedef void (*numentry1_t)(int cnt, int arg1); look similar, they are quite different. While it is true that for both instructions the first argument, int cnt, is saved in R1 as the RX ABI indeed dictates, when it comes to the second argument, things are starting to drift away: For (*numentry1_t)(int cnt, int arg1) the second argument is saved in R2 as expected, but for the (*numentry_t)(int cnt, int arg1, …) instruction, the arg1 is saved into the stack. The reason why this happens is that RX not only passes variable arguments on the stack, but in this case it is also using the second argument (arg1) as a mean for the va_start to locate the first variable argument to save on the stack. This is also mentioned in chapter 7.6 of the ISO/IEC standard: "The rightmost parameter plays a special role in the access mechanism, and will be designated parmN in this description." The same behavior can be seen in other compilers that are built with respect to the same ABI. For example, CCRX is also placing arg1 on the stack in case of a variable list of arguments. Please let us know if we can be of further assistance, __ Best Regards, The GNU Tools Team

« Previous 1 2 3 4 5 6 7 8 9 10 Next »