Ticket #155 (closed enhancement: fixed)

Opened 2 years ago

Last modified 10 months ago

Need a way to determine symbol name from an address

Reported by: jermar 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

comment:1 Changed 2 years ago by jermar

  • Summary changed from Need a way to tell symbol name from an address to Need a way to determine symbol name from an address

comment:2 Changed 2 years ago by 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 2 years ago by 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 16 months ago by jermar

  • Milestone changed from 0.5.0 to 0.5.1

comment:5 Changed 10 months ago by jermar

  • Status changed from new to closed
  • Resolution set to fixed
  • Milestone changed from 0.5.0 to 0.4.3

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.