strace stacktrace: offsets printed

[Masatake YAMATO]

Sorry to be late to reply.

Could you look at print_stack_frame in undwind.c?

    static int
    print_stack_frame(struct tcb *tcp,
		      call_action_fn call_action,
		      error_action_fn error_action,
		      void *data,
		      unw_cursor_t *cursor,
		      char **symbol_name,
		      size_t *symbol_name_size)
    {
	    ...
			true_offset = ip - cur_mmap_cache->start_addr +
				cur_mmap_cache->mmap_offset;
			call_action(data,
				    cur_mmap_cache->binary_filename,
				    *symbol_name,
				    function_offset,
				    true_offset);
            ...


Do you mean you want strace to print the value of 'ip' in stead of true_offset?

Masatake YAMATO

	    
> Hi,
> 
> I'm glad that strace 4.9 has integrated the features previously part
> of strace-plus. I successfully built and run it on a PowerPC linux
> system.
> 
> One thing I noticed: the function addresses printed are offset against
> the virtual memory location of the text section, i.e. strace prints
> 0xdcc but this actually corresponds to 0x10000dcc.
> 
> When no symbolic information is available in the build (because it's
> stripped), it would be nice that the addresses are in the second
> format so that they can be matched directly with the contents of the
> non-stripped ELF file (for example with the output of 'nm').
> 
> From a comment in unwind.c (above the definition of
> STACK_ENTRY_SYMBOL_FMT) I have the impression that this is by design,
> but I wonder how usable this output is: how can one easily create a
> symbolic stacktrace from it?
> 
> Not having symbolic information in applications is very typical in
> embedded development. In this case, stacktraces taken from target only
> have address information, and using fairly simple tools this
> information can be matched against the output of nm to produce a
> symbolic stacktrace, or sent to addr2line to get line number
> information.
> 
> Best regards,
> Thomas