Open Source Tools for Renesas’s reputation | Open Source Tools for Renesas

Open Source Tools for Renesas’s reputation

Open Source Tools for Renesas 822 Rep.

Follow

Open Source Tools for Renesas's reputation

Total 822

0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0

+5

June 10, 2021 Up vote answer Where is the document of LLVM-RL78 ABI

+1

June 8, 2021 Commented Hello, Thank you for reaching out to us! We are grateful for your suggestion and we have already opened an internal ticket for improving those features. Please let us know if we can be of further assistance. __ Best regards, The Open Source Tools Team

+1

May 28, 2021 Commented Dear NoMaY-san, Thank you - an URL of the repository would work for us. Alternatively, we can also accept ZIP files if you submit a new ticket through the internal support system. __ Best regards, The Open Source Tools Team

+1

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

+1

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

+1

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

+1

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

+1

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

+1

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

+1

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

+1

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

+1

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

+1

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

+1

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

+1

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

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

Support