Fork us on GitHub Follow us on Facebook Follow us on Twitter

Opened 10 years ago

Closed 8 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 Changed 10 years ago by Jakub Jermář

Summary: Need a way to tell symbol name from an addressNeed a way to determine symbol name from an address

comment:2 Changed 10 years ago by Jiri Svoboda

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:

  • write the symbol table to a loadable segment (same as we do in the kernel),
  • have the loader load the symbol table along with the loadable segments,
  • have the C library load the symbol table at start-up time
  • have the C library load the symbol table upon first query

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.

comment:3 Changed 10 years ago by Jiri Svoboda

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 Changed 9 years ago by Jakub Jermář

Milestone: 0.5.00.5.1

comment:5 Changed 8 years ago by Jakub Jermář

Milestone: 0.5.00.4.3
Resolution: fixed
Status: newclosed

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.

Note: See TracTickets for help on using tickets.