Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

esp_log_write is placed in IRAM but esp_log_writev is not (IDFGH-13682) #14557

Closed
3 tasks done
robin96c opened this issue Sep 12, 2024 · 4 comments
Closed
3 tasks done
Assignees
Labels
Resolution: Done Issue is done internally Status: Done Issue is done internally Type: Bug bugs in IDF

Comments

@robin96c
Copy link

Answers checklist.

  • I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
  • I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
  • 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.

  1. Build an app that uses the logging component. I build for esp32s3.
  2. 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

@robin96c robin96c added the Type: Bug bugs in IDF label Sep 12, 2024
@espressif-bot espressif-bot added the Status: Opened Issue is new label Sep 12, 2024
@github-actions github-actions bot changed the title esp_log_write is placed in IRAM but esp_log_writev is not esp_log_write is placed in IRAM but esp_log_writev is not (IDFGH-13682) Sep 12, 2024
@sudeep-mohanty
Copy link
Collaborator

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.

@Alvin1Zhang
Copy link
Collaborator

Thanks for reporting, sorry for the slow turnaround, fix on master branch is available at 9eeee92.

@Indastri
Copy link
Collaborator

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!

@Indastri Indastri added Resolution: Done Issue is done internally and removed Resolution: NA Issue resolution is unavailable labels Jan 30, 2025
@AxelLin
Copy link
Contributor

AxelLin commented Feb 1, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Resolution: Done Issue is done internally Status: Done Issue is done internally Type: Bug bugs in IDF
Projects
None yet
Development

No branches or pull requests

7 participants