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

Open
3 tasks done
robin96c opened this issue Sep 12, 2024 · 8 comments
Open
3 tasks done
Assignees
Labels
Status: In Progress Work is in progress 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.

@Indastri
Copy link
Collaborator

Indastri commented Feb 3, 2025

Hi @AxelLin, the fix is currently being backported to v5.2 branch, reopening until fixed. cc @SoucheSouche @KonstantinKondrashov

@Indastri Indastri reopened this Feb 3, 2025
@espressif-bot espressif-bot added Status: In Progress Work is in progress and removed Status: Done Issue is done internally Resolution: Done Issue is done internally labels Feb 3, 2025
@AxelLin
Copy link
Contributor

AxelLin commented Feb 25, 2025

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?

@AxelLin
Copy link
Contributor

AxelLin commented Feb 25, 2025

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.

@Indastri
Copy link
Collaborator

@AxelLin as I stated before, the fix is currently being backported. Not yet available in other branches.

Cheers!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: In Progress Work is in progress Type: Bug bugs in IDF
Projects
None yet
Development

No branches or pull requests

7 participants