Opened 15 years ago
Closed 13 years ago
#155 closed enhancement (fixed)
Need a way to determine symbol name from an address
Reported by: | Jakub Jermář | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | 0.4.3 |
Component: | helenos/lib/c | Version: | mainline |
Keywords: | Cc: | ||
Blocker for: | Depends on: | ||
See also: |
Description
For the sake of more readable uspace stack traces, it would be useful to be able to resolve memory addresses to symbol names, such as:
0x41cc → main()+0xc
where 0x41c0 is the address corresponding to symbol main.
Change History (5)
comment:1 by , 15 years ago
Summary: | Need a way to tell symbol name from an address → Need a way to determine symbol name from an address |
---|
comment:2 by , 15 years ago
comment:3 by , 15 years ago
Taskdump can print the stack trace including the symbol names. abort() could be modified to cause a special type of fault in a defined way. Thus we would get not only a stack trace (with symbol names), but also possibly a core file (when this is implemented). This would solve this problem for abort().
This would not solve the situation where we would want to print a stack trace without aborting the program (or dumping core), but we don't do that yet and cannot really imagine why we would do that.
comment:4 by , 14 years ago
Milestone: | 0.5.0 → 0.5.1 |
---|
comment:5 by , 13 years ago
Milestone: | 0.5.0 → 0.4.3 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
We can handle the abort() case as of mainline,845, so there is probably very little that could be done additionally. I am therefore closing the ticket.
In order to do this, symbol information must be available to the application at run time. I can think of several ways to accomplish this:
Keep in mind that loading the symbol table can consume a lot of memory and CPU time so it would be better to avoid if not necessary. On the other hand, loading the symbol table at the time the stack trace is taken seems risky. The task might not be in a state that makes this possible. For example, if we wanted to produce a stack trace upon a failed assertion (which I believe to be the primary use case) then this would probably cause trouble with assertions in code related to file-system API.