`esp_log_write` is placed in IRAM but `esp_log_writev` is not (IDFGH-13682)
Answers checklist.
- [X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
- [X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
- [X] I have searched the issue tracker for a similar issue and not found a similar issue.
IDF version.
v5.2.1
Operating System used.
Linux
How did you build your project?
Command line with idf.py
If you are using Windows, please specify command line type.
None
What is the expected behavior?
I was looking into the logging system. I noticed some logging functions are placed into IRAM by means of the linker file.
One of such functions is esp_log_write. esp_log_write calls esp_log_writev, but this last function is NOT placed in IRAM. To my understanding, this nullifies the advantage of not needing to access the flash during a log call.
What is the actual behavior?
Only esp_log_write is placed into IRAM.
Once you dig deeper, there are also other functions that are called while outputting a log that are also not in IRAM:
- esp_log_get_level_master
- s_log_level_get_and_unlock
- get_cached_log_level
- (...)
I'm no expert in this, and I don't know if all these functions need to be placed into IRAM. But it seems weird that some functions are in IRAM while others are not. The reason why I'm digging into this is because I will set a new logger output with esp_log_set_vprintf, and I was wondering if that new function should be put into IRAM.
Steps to reproduce.
- Build an app that uses the logging component. I build for esp32s3.
- Get the sectors of the logging functions:
xtensa-esp32s3-elf-objdump build/your_app.elf -t | grep esp_log
4038a418 g F .iram0.text 00000047 esp_log_timestamp
4038a378 g F .iram0.text 0000001d esp_log_early_timestamp
420eb6f4 g F .flash.text 0000002e esp_log_writev
(...)
4038a350 g F .iram0.text 00000026 esp_log_write
4038a398 g F .iram0.text 00000027 esp_log_impl_lock
Build or installation Logs.
No response
More Information.
No response
Hi @robin96c, Thank for reporting this to us. Indeed, the linker.lf is out dated and doesn't have all the dependency call chain listed. We will take a look.
Thanks for reporting, sorry for the slow turnaround, fix on master branch is available at https://github.com/espressif/esp-idf/commit/9eeee92d6b8f661135aa423acddb1bec235ea674.
Since there was no response from the user - closing this issue. If the issue persists or if you have any other problems, please reopen this or create a new issue.
Cheers!
Thanks for reporting, sorry for the slow turnaround, fix on master branch is available at 9eeee92.
This issue was reported on v5.2.1, but the fix is not yet available in 5.2 branch.
Hi @AxelLin, the fix is currently being backported to v5.2 branch, reopening until fixed. cc @SoucheSouche @KonstantinKondrashov
Hi @AxelLin, the fix is currently being backported to v5.2 branch, reopening until fixed. cc @SoucheSouche @KonstantinKondrashov
@Indastri The v5.2.4 does not include this fix, what's wrong?
Hi @AxelLin, the fix is currently being backported to v5.2 branch, reopening until fixed. cc @SoucheSouche @KonstantinKondrashov
@Indastri The v5.2.4 does not include this fix, what's wrong?
The fix does not exist in any release branches so far. It's only available in master.
@AxelLin as I stated before, the fix is currently being backported. Not yet available in other branches.
Cheers!
Thanks for reporting, latest updates:
- fix on release/5.2 is available at https://github.com/espressif/esp-idf/commit/4e30b88527a47dea2bf9d06d79662624e488c07a.
- fix on release/5.3 is available at https://github.com/espressif/esp-idf/commit/79bf6acddba4e614de4925e19aba52cfd9e0cdf2.
Will update again once fix on those release branches are available. Thanks.