Open Source Tools for Renesas’s ポイント | Open Source Tools for Renesas

Open Source Tools for Renesas’s ポイント

Open Source Tools for Renesas 824 ポイント.

フォロー

Open Source Tools for Renesas's ポイント

Total 824

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

+5

10月 16, 2017 Up vote 回答 Difference between Windows and Linux RX 1703 toolchain when using optimised libraries

+10

10月 14, 2017 Answered Difference between Windows and Linux RX 1703 toolchain when using optimised libraries

+10

10月 6, 2017 Answered ” GNURX “supporting “HEW”.

+10

10月 5, 2017 Answered const *variableName is placed in ROM instead of RAM

+1

9月 20, 2017 Commented Hello Steve, Fortunately, we believe we were able to reproduce your problem, so please hold on on the sample project for now. We are investigating what the issue might be and will be returning shortly with our conclusions. Thank you, The GNU Tools Team

+1

9月 20, 2017 Commented Hello Steven, It looks like “Default:0xfa722” represents the address of your variable, not its contents as a string. Its contents is more likely to be available on the “Details:’\0′” which present a NULL string . As you haven’t considered sending your project for analysis, we would like to ask you to try the latest RL78 GCC, version 2017q1 available here: https://gcc-renesas.com/rl78/rl78-download-toolchains/ If the problem still persists, please return to us with a sample project we can use for analysis. You can check your library settings under Project Properties|C/C++ Build|Settings. Hope this helps, but we insist in inspecting your project in order to provide a more accurate and a more prompt resolution to your problem. – Best Regards, Grigore Dobra, The GNU Tools Team

+1

7月 10, 2017 Commented Hello, To upload files, please submit a private support ticket. You will be able to attach files there. We can keep this thread open nonetheless. -- Thank you, The GNU Tools Team

+1

5月 31, 2017 Commented Thank you for the details provided. It seems that you may be trying to compile the RX toolchain source code. While multiple versions of the libc.a library exist (including ones compiled for big endian formats, e.g. referring to the "-mbig-endian-data" flag), the compiler (rx-elf-gcc) should know on its own to which library to link to. However, when using the linker (rx-elf-ld) manually, you would have to specify the proper library on your own. If you could share a test command, or a sample project we could work with, it would quickly allow us to be able to assess the impact of the issue reported and provide more accurate feedback. -- Thank you, The GNU Tools Team.

+1

5月 31, 2017 Commented Hello, Thank you for reaching out to us! If this issue persists, could you please open a support ticket and specify what toolchain you were attempting to compile and for which target, as well as the operating system you were using for the procedure? We should be able to assist faster this way. -- Thank you, The GNU Tools Team

+10

3月 17, 2017 Answered GCC for Renesas RX Setup can not auth. code validate thru HTTP proxy — Installation canceled

+1

2月 3, 2017 Commented Hello Adam, It looks like -fshort-wchar makes the code incompatible with the system libraries. This is why the linker warns about the mismatch. It's not a warning that should be silenced, but if you want to, you can do it using the -no-wchar-size-warning user-defined option in the linker section. — Thank you, The GNU Tools Team

+1

2月 3, 2017 Commented Hello Adam, We see 46 warnings in your project, prior to the warning mentioned by you. The problem may not be related to wchar size despite the warning, could you please try solving these warnings first and then letting us know if you are still experiencing the same problem? — Thank you, The GNU Tools Team

+1

1月 24, 2017 Commented Hello, Thank you for your patience. By default, malloc() will work without any prior setup and thus the heap memory will be allocated after the end of .bss section. For example: if the end of .bss is 0x20060a28, calling malloc() will return a pointer to 0x20060a30. If you like to overwrite this and take control of where to place the heap, you should instead overwrite the _sbrk()/_sbrk_r() function. Also, we have noticed that you have posted another question with the same issue on the forum. If you opened that issue by mistake, would you like us to close it and continue answering in here? Thank you again for your patience and please, let us know if we can be of further assistance. -- Kind regards, The GNU Tools Team

+1

11月 18, 2016 Commented Hi Tony, Thank you for confirming - we will close this thread as a result thereof, and continue in the dedicated support ticket for this issue. -- Thank you, Ciprian The GNU Tools Team

+1

11月 18, 2016 Commented Hello Adam, Thank you for your patience in resolving this matter. Unfortunately, due to circumstances outside our control, this issue is still pending – although actively being worked on at this time. As soon as this is ready, we will inform you of course. — Thank you, The GNU Tools Team

+10

11月 17, 2016 Answered Exception for GNUARM-NONEv15.01-EABI

+1

11月 16, 2016 Commented Hello Tony, Thank you for contacting us! We have noticed that you have also posted a support request on the site, would you like us to continue answering in there? It is better to use that for more accurate tracking purposes. Please let me know. -- Thank you, Ciprian The GNU Tools Team

+1

11月 7, 2016 Commented Hello, Thank you for your patience. Just wanted to inform you that since the 23rd of October, 2016, the updated (mobile-friendly) migration guides are ready and available on https://gcc-renesas.com. -- Thank you, The GNU Tools Team

+1

11月 4, 2016 Commented 信行さん、私たちは常に助けて幸せです。残念ながら、あなたは、製品を統合することができるようにe2Studioのバージョン5.1が必要です。 e2Studioの古いバージョンではサポートされていません。 -- どうもありがとうございました Ciprian 支援チーム

+1

11月 4, 2016 Commented 信行さん、私たちはあなたの進め方についての情報を含む電子メールを送信しました。あなたが他の問題がある場合はお知らせください。 -- どうもありがとうございました Ciprian 支援チーム

« 前へ 1 2 3 … 6 7 8 9 10 11 12 次へ »

サポート