Subject: Re: [boost] Checking interest in stacktrace library
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2016-06-20 22:52:00
On Mon, Jun 20, 2016 at 9:26 PM, Gavin Lambert <gavinl_at_[hidden]>
> On 19/06/2016 09:18, Klemens Morgenstern wrote:
>> What functionality would you like to have in it?
>>> file & line number ... at least for the top frame and possibly
>>> optional. this would require a macro, but might be useful for
>>> debugging ...
>> With gcc you can find that out with addr2line if you have the address of
>> the function and or the source of the call (i.e. address of the
>> Not sure if that would need to be in the library then, though I don't
>> know the other compilers.
> You typically can't assume that you'll be able to get file and line from
> an address on a live system.
> Most installed software (via "install" on Linux or omitting the pdb file
> on Windows) consists of stripped binaries that specifically have the
> necessary information to do that omitted. (Since it can be quite large,
> and exposes things that proprietary folks prefer not to.)
Additionally.. Even if you go through the steps to include that information
in your custom binaries.. It is no uncommon for addr2line to not work even
with the information. That might not be common in run-of-the-mill Linux
systems. But it is common in custom built embedded Linux derivatives, like
Android variants and game consoles.
However it's still useful to be able to log a stack trace consisting only
> of addresses (and a build identifier) to a log file, that can then be
> reconstructed into line number info (via addr2line and similar tools) on
> another machine that has the non-stripped binaries (or PDB files) from the
> same build available.
Which makes that approach the common way of dealing with stack trace
information in the above context.
-- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk