------=_Part_4172_4427992.1379442991495
Content-Type: text/plain; charset=ISO-8859-1

Every major compiler or platform has some facility to get backtraces, but
there is no standard.  For logging and debugging purposes, such a facility
can be quite handy.  Sometimes this information is desired without an
attached debugger, such as when collecting log information from clients or
simply for making certain runtime debug facilities easier to use.

Requirements, fulfilled on most platforms already by platform-dependent
APIs:

(1) Can very efficiently retrieve a single level of call stack history as
an opaque piece of data (the return address, typically)
(2) Can fairly efficiently retrieve the entire call stack history (walking
up the stack) as an opaque piece of data or an array of opaque data
(3) Can request symbols and line number information for a call stack
history item, which may or may not be available
(4) Does not guarantee "accurate" results due to optimization levels
potentially transforming the program significantly from the written source

Usage something like:

    #include <debug_bikeshed>

    auto my_caller = std::call_stack(1); // meant to be highly efficient,
useful for an in-process profiler or memory debugger
    auto limited_callstack = std::call_stack(10);
    auto callstack = std::call_stack(); // meant for debug-build logging or
the like

    // separate call to get symbols, as this may be quite slow and maybe
require blocking I/O
    for (const auto& sym : std::get_symbols(callstack))
      if (sym.has_file() && sym.has_line() && sym.has_function())
        std::cout << sym.file() << '(' << sym.line() << "): " <<
sym.function() << std::endl;
      else
        std::cout << sym.name() << std::endl;

The sym.name() does a best-attempt at formatting the available information
in an implementation-defined way.  Some implementations might have an
offset from a (mangled) function symbol name, some might have just an
absolute address, etc.  get_symbols() should _attempt_ to retrieve the file
name, unmangled function name (with class and scope), line number, etc.
 The implementation is free to return all, some, or none of these fields
depending on what the platform supports and what information is available
(e.g. if debugging information is available for the executable/library in
use).

As a QoI issue, sym.name() should produce its output in a format that the
implementation's preferred IDE natively groks.  e.g., Visual Studio should
format things such that lines clicked in the debug output window
automatically open the file/line referenced, and a GCC implementation
should use its output format that is understood by Vim/EMACS/etc. for the
same purpose.  Again, the specific format of sym.name() would be
implementation defined and users wanting a specific output would be free to
query the individual fields directly, as shown.

Prior art scrounged up with 15 seconds on Google:

   Some UNIX flavors via GCC APIs:
http://www.gnu.org/software/libc/manual/html_node/Backtraces.html and
https://github.com/mirrors/gcc/tree/master/libbacktrace
   Windows APIs:
http://www.codeproject.com/Articles/11132/Walking-the-callstack
   OSX and iOS:
https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSThread_Class/Reference/Reference.html
   Proposed Boost module:
http://lists.boost.org/Archives/boost/2010/10/172303.php

Most higher-level languages and runtimes have some similar facility, too.



--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_4172_4427992.1379442991495
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Every major compiler or platform has some facility to get =
backtraces, but there is no standard. &nbsp;For logging and debugging purpo=
ses, such a facility can be quite handy. &nbsp;Sometimes this information i=
s desired without an attached debugger, such as when collecting log informa=
tion from clients or simply for making certain runtime debug facilities eas=
ier to use.<div><br></div><div>Requirements, fulfilled on most platforms al=
ready by platform-dependent APIs:</div><div><br></div><div>(1) Can very eff=
iciently retrieve a single level of call stack history as an opaque piece o=
f data (the return address, typically)</div><div>(2) Can fairly efficiently=
 retrieve the entire call stack history (walking up the stack) as an opaque=
 piece of data or an array of opaque data</div><div>(3) Can request symbols=
 and line number information for a call stack history item, which may or ma=
y not be available</div><div>(4) Does not guarantee "accurate" results due =
to optimization levels potentially transforming the program significantly f=
rom the written source</div><div><br></div><div>Usage something like:</div>=
<div><br></div><div>&nbsp; &nbsp; #include &lt;debug_bikeshed&gt;</div><div=
><br></div><div>&nbsp; &nbsp; auto my_caller =3D std::call_stack(1); // mea=
nt to be highly efficient, useful for an in-process profiler or memory debu=
gger</div><div>&nbsp; &nbsp; auto limited_callstack =3D std::call_stack(10)=
;</div><div>&nbsp; &nbsp; auto callstack =3D std::call_stack(); // meant fo=
r debug-build logging or the like</div><div><br></div><div>&nbsp; &nbsp; //=
 separate call to get symbols, as this may be quite slow and maybe require =
blocking I/O</div><div>&nbsp; &nbsp; for (const auto&amp; sym : std::get_sy=
mbols(callstack))<br></div><div>&nbsp; &nbsp; &nbsp; if (sym.has_file() &am=
p;&amp; sym.has_line() &amp;&amp; sym.has_function())</div><div>&nbsp; &nbs=
p; &nbsp; &nbsp; std::cout &lt;&lt; sym.file() &lt;&lt; '(' &lt;&lt; sym.li=
ne() &lt;&lt; "): " &lt;&lt; sym.function() &lt;&lt; std::endl;</div><div>&=
nbsp; &nbsp; &nbsp; else</div><div>&nbsp; &nbsp; &nbsp; &nbsp; std::cout &l=
t;&lt; sym.name() &lt;&lt; std::endl;</div><div><br></div><div>The sym.name=
() does a best-attempt at formatting the available information in an implem=
entation-defined way. &nbsp;Some implementations might have an offset from =
a (mangled) function symbol name, some might have just an absolute address,=
 etc. &nbsp;get_symbols() should _attempt_ to retrieve the file name, unman=
gled function name (with class and scope), line number, etc. &nbsp;The impl=
ementation is free to return all, some, or none of these fields depending o=
n what the platform supports and what information is available (e.g. if deb=
ugging information is available for the executable/library in use).</div><d=
iv><br></div><div>As a QoI issue, sym.name() should produce its output in a=
 format that the implementation's preferred IDE natively groks. &nbsp;e.g.,=
 Visual Studio should format things such that lines clicked in the debug ou=
tput window automatically open the file/line referenced, and a GCC implemen=
tation should use its output format that is understood by Vim/EMACS/etc. fo=
r the same purpose. &nbsp;Again, the specific format of sym.name() would be=
 implementation defined and users wanting a specific output would be free t=
o query the individual fields directly, as shown.</div><div><br></div><div>=
Prior art scrounged up with 15 seconds on Google:</div><div><br></div><div>=
&nbsp; &nbsp;Some UNIX flavors via GCC APIs:&nbsp;<a href=3D"http://www.gnu=
..org/software/libc/manual/html_node/Backtraces.html">http://www.gnu.org/sof=
tware/libc/manual/html_node/Backtraces.html</a>&nbsp;and&nbsp;<a href=3D"ht=
tps://github.com/mirrors/gcc/tree/master/libbacktrace">https://github.com/m=
irrors/gcc/tree/master/libbacktrace</a></div><div>&nbsp; &nbsp;Windows APIs=
:&nbsp;<a href=3D"http://www.codeproject.com/Articles/11132/Walking-the-cal=
lstack">http://www.codeproject.com/Articles/11132/Walking-the-callstack</a>=
</div><div>&nbsp; &nbsp;OSX and iOS:&nbsp;<a href=3D"https://developer.appl=
e.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSThread=
_Class/Reference/Reference.html">https://developer.apple.com/library/mac/do=
cumentation/Cocoa/Reference/Foundation/Classes/NSThread_Class/Reference/Ref=
erence.html</a></div><div>&nbsp; &nbsp;Proposed Boost module:&nbsp;<a href=
=3D"http://lists.boost.org/Archives/boost/2010/10/172303.php">http://lists.=
boost.org/Archives/boost/2010/10/172303.php</a>&nbsp; &nbsp;</div><div><br>=
</div><div>Most higher-level languages and runtimes have some similar facil=
ity, too.</div><div><br></div><div>&nbsp; &nbsp;</div><div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_4172_4427992.1379442991495--

.

On Tue, Sep 17, 2013 at 2:36 PM, Sean Middleditch
<sean.middleditch@gmail.com> wrote:
> Every major compiler or platform has some facility to get backtraces, but
> there is no standard. [...]

FYI, there are some proposals in this area:

http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3757.html

This one does not do backtrace, but also helpful:

http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3757.html
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3758.html

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--047d7b3a9b121e059204e6992fc1
Content-Type: text/plain; charset=ISO-8859-1

What do you want to happen when symbol files are not present?

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Tue, Sep 17, 2013 at 11:36 AM, Sean Middleditch <
sean.middleditch@gmail.com> wrote:

> Every major compiler or platform has some facility to get backtraces, but
> there is no standard.  For logging and debugging purposes, such a facility
> can be quite handy.  Sometimes this information is desired without an
> attached debugger, such as when collecting log information from clients or
> simply for making certain runtime debug facilities easier to use.
>
> Requirements, fulfilled on most platforms already by platform-dependent
> APIs:
>
> (1) Can very efficiently retrieve a single level of call stack history as
> an opaque piece of data (the return address, typically)
> (2) Can fairly efficiently retrieve the entire call stack history (walking
> up the stack) as an opaque piece of data or an array of opaque data
> (3) Can request symbols and line number information for a call stack
> history item, which may or may not be available
> (4) Does not guarantee "accurate" results due to optimization levels
> potentially transforming the program significantly from the written source
>
> Usage something like:
>
>     #include <debug_bikeshed>
>
>     auto my_caller = std::call_stack(1); // meant to be highly efficient,
> useful for an in-process profiler or memory debugger
>     auto limited_callstack = std::call_stack(10);
>     auto callstack = std::call_stack(); // meant for debug-build logging
> or the like
>
>     // separate call to get symbols, as this may be quite slow and maybe
> require blocking I/O
>     for (const auto& sym : std::get_symbols(callstack))
>       if (sym.has_file() && sym.has_line() && sym.has_function())
>         std::cout << sym.file() << '(' << sym.line() << "): " <<
> sym.function() << std::endl;
>       else
>         std::cout << sym.name() << std::endl;
>
> The sym.name() does a best-attempt at formatting the available
> information in an implementation-defined way.  Some implementations might
> have an offset from a (mangled) function symbol name, some might have just
> an absolute address, etc.  get_symbols() should _attempt_ to retrieve the
> file name, unmangled function name (with class and scope), line number,
> etc.  The implementation is free to return all, some, or none of these
> fields depending on what the platform supports and what information is
> available (e.g. if debugging information is available for the
> executable/library in use).
>
> As a QoI issue, sym.name() should produce its output in a format that the
> implementation's preferred IDE natively groks.  e.g., Visual Studio should
> format things such that lines clicked in the debug output window
> automatically open the file/line referenced, and a GCC implementation
> should use its output format that is understood by Vim/EMACS/etc. for the
> same purpose.  Again, the specific format of sym.name() would be
> implementation defined and users wanting a specific output would be free to
> query the individual fields directly, as shown.
>
> Prior art scrounged up with 15 seconds on Google:
>
>    Some UNIX flavors via GCC APIs:
> http://www.gnu.org/software/libc/manual/html_node/Backtraces.html and
> https://github.com/mirrors/gcc/tree/master/libbacktrace
>    Windows APIs:
> http://www.codeproject.com/Articles/11132/Walking-the-callstack
>    OSX and iOS:
> https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSThread_Class/Reference/Reference.html
>    Proposed Boost module:
> http://lists.boost.org/Archives/boost/2010/10/172303.php
>
> Most higher-level languages and runtimes have some similar facility, too.
>
>
>
>  --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--047d7b3a9b121e059204e6992fc1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">What do you want to happen when symbol files are not prese=
nt?</div><div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"=
><div>Billy O&#39;Neal</div><div><a href=3D"https://bitbucket.org/BillyONea=
l/" target=3D"_blank">https://github.com/BillyONeal/</a></div>

<div><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D=
"_blank">http://stackoverflow.com/users/82320/billy-oneal</a></div><div>Mal=
ware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Tue, Sep 17, 2013 at 11:36 AM, Sean M=
iddleditch <span dir=3D"ltr">&lt;<a href=3D"mailto:sean.middleditch@gmail.c=
om" target=3D"_blank">sean.middleditch@gmail.com</a>&gt;</span> wrote:<br><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">

<div dir=3D"ltr">Every major compiler or platform has some facility to get =
backtraces, but there is no standard. =A0For logging and debugging purposes=
, such a facility can be quite handy. =A0Sometimes this information is desi=
red without an attached debugger, such as when collecting log information f=
rom clients or simply for making certain runtime debug facilities easier to=
 use.<div>

<br></div><div>Requirements, fulfilled on most platforms already by platfor=
m-dependent APIs:</div><div><br></div><div>(1) Can very efficiently retriev=
e a single level of call stack history as an opaque piece of data (the retu=
rn address, typically)</div>

<div>(2) Can fairly efficiently retrieve the entire call stack history (wal=
king up the stack) as an opaque piece of data or an array of opaque data</d=
iv><div>(3) Can request symbols and line number information for a call stac=
k history item, which may or may not be available</div>

<div>(4) Does not guarantee &quot;accurate&quot; results due to optimizatio=
n levels potentially transforming the program significantly from the writte=
n source</div><div><br></div><div>Usage something like:</div><div><br>
</div>
<div>=A0 =A0 #include &lt;debug_bikeshed&gt;</div><div><br></div><div>=A0 =
=A0 auto my_caller =3D std::call_stack(1); // meant to be highly efficient,=
 useful for an in-process profiler or memory debugger</div><div>=A0 =A0 aut=
o limited_callstack =3D std::call_stack(10);</div>

<div>=A0 =A0 auto callstack =3D std::call_stack(); // meant for debug-build=
 logging or the like</div><div><br></div><div>=A0 =A0 // separate call to g=
et symbols, as this may be quite slow and maybe require blocking I/O</div><=
div>=A0 =A0 for (const auto&amp; sym : std::get_symbols(callstack))<br>

</div><div>=A0 =A0 =A0 if (sym.has_file() &amp;&amp; sym.has_line() &amp;&a=
mp; sym.has_function())</div><div>=A0 =A0 =A0 =A0 std::cout &lt;&lt; sym.fi=
le() &lt;&lt; &#39;(&#39; &lt;&lt; sym.line() &lt;&lt; &quot;): &quot; &lt;=
&lt; sym.function() &lt;&lt; std::endl;</div>

<div>=A0 =A0 =A0 else</div><div>=A0 =A0 =A0 =A0 std::cout &lt;&lt; <a href=
=3D"http://sym.name" target=3D"_blank">sym.name</a>() &lt;&lt; std::endl;</=
div><div><br></div><div>The <a href=3D"http://sym.name" target=3D"_blank">s=
ym.name</a>() does a best-attempt at formatting the available information i=
n an implementation-defined way. =A0Some implementations might have an offs=
et from a (mangled) function symbol name, some might have just an absolute =
address, etc. =A0get_symbols() should _attempt_ to retrieve the file name, =
unmangled function name (with class and scope), line number, etc. =A0The im=
plementation is free to return all, some, or none of these fields depending=
 on what the platform supports and what information is available (e.g. if d=
ebugging information is available for the executable/library in use).</div>

<div><br></div><div>As a QoI issue, <a href=3D"http://sym.name" target=3D"_=
blank">sym.name</a>() should produce its output in a format that the implem=
entation&#39;s preferred IDE natively groks. =A0e.g., Visual Studio should =
format things such that lines clicked in the debug output window automatica=
lly open the file/line referenced, and a GCC implementation should use its =
output format that is understood by Vim/EMACS/etc. for the same purpose. =
=A0Again, the specific format of <a href=3D"http://sym.name" target=3D"_bla=
nk">sym.name</a>() would be implementation defined and users wanting a spec=
ific output would be free to query the individual fields directly, as shown=
..</div>

<div><br></div><div>Prior art scrounged up with 15 seconds on Google:</div>=
<div><br></div><div>=A0 =A0Some UNIX flavors via GCC APIs:=A0<a href=3D"htt=
p://www.gnu.org/software/libc/manual/html_node/Backtraces.html" target=3D"_=
blank">http://www.gnu.org/software/libc/manual/html_node/Backtraces.html</a=
>=A0and=A0<a href=3D"https://github.com/mirrors/gcc/tree/master/libbacktrac=
e" target=3D"_blank">https://github.com/mirrors/gcc/tree/master/libbacktrac=
e</a></div>

<div>=A0 =A0Windows APIs:=A0<a href=3D"http://www.codeproject.com/Articles/=
11132/Walking-the-callstack" target=3D"_blank">http://www.codeproject.com/A=
rticles/11132/Walking-the-callstack</a></div><div>=A0 =A0OSX and iOS:=A0<a =
href=3D"https://developer.apple.com/library/mac/documentation/Cocoa/Referen=
ce/Foundation/Classes/NSThread_Class/Reference/Reference.html" target=3D"_b=
lank">https://developer.apple.com/library/mac/documentation/Cocoa/Reference=
/Foundation/Classes/NSThread_Class/Reference/Reference.html</a></div>

<div>=A0 =A0Proposed Boost module:=A0<a href=3D"http://lists.boost.org/Arch=
ives/boost/2010/10/172303.php" target=3D"_blank">http://lists.boost.org/Arc=
hives/boost/2010/10/172303.php</a>=A0 =A0</div><div><br></div><div>Most hig=
her-level languages and runtimes have some similar facility, too.</div>

<span class=3D"HOEnZb"><font color=3D"#888888"><div><br></div><div>=A0 =A0<=
/div><div><br></div></font></span></div><span class=3D"HOEnZb"><font color=
=3D"#888888">

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b3a9b121e059204e6992fc1--

.

On Tue, Sep 17, 2013 at 12:17 PM, Billy O'Neal <billy.oneal@gmail.com> wrote:
> What do you want to happen when symbol files are not present?

I pretty explicitly covered that, second to last full paragraph.
Implementation _should_ retrieve as much symbol information as it can,
but is free to return only some or none of the possible information,
depending on platform information or availability of symbol data.
It's still quite useful to get the raw dump of address from a stack
trace to store and process offline with another tool during
post-deployment forensics, though of course having the symbols during
development/debugging is handier still.

>
> Billy O'Neal
> https://github.com/BillyONeal/
> http://stackoverflow.com/users/82320/billy-oneal
> Malware Response Instructor - BleepingComputer.com
>
>
> On Tue, Sep 17, 2013 at 11:36 AM, Sean Middleditch
> <sean.middleditch@gmail.com> wrote:
>>
>> Every major compiler or platform has some facility to get backtraces, but
>> there is no standard.  For logging and debugging purposes, such a facility
>> can be quite handy.  Sometimes this information is desired without an
>> attached debugger, such as when collecting log information from clients or
>> simply for making certain runtime debug facilities easier to use.
>>
>> Requirements, fulfilled on most platforms already by platform-dependent
>> APIs:
>>
>> (1) Can very efficiently retrieve a single level of call stack history as
>> an opaque piece of data (the return address, typically)
>> (2) Can fairly efficiently retrieve the entire call stack history (walking
>> up the stack) as an opaque piece of data or an array of opaque data
>> (3) Can request symbols and line number information for a call stack
>> history item, which may or may not be available
>> (4) Does not guarantee "accurate" results due to optimization levels
>> potentially transforming the program significantly from the written source
>>
>> Usage something like:
>>
>>     #include <debug_bikeshed>
>>
>>     auto my_caller = std::call_stack(1); // meant to be highly efficient,
>> useful for an in-process profiler or memory debugger
>>     auto limited_callstack = std::call_stack(10);
>>     auto callstack = std::call_stack(); // meant for debug-build logging
>> or the like
>>
>>     // separate call to get symbols, as this may be quite slow and maybe
>> require blocking I/O
>>     for (const auto& sym : std::get_symbols(callstack))
>>       if (sym.has_file() && sym.has_line() && sym.has_function())
>>         std::cout << sym.file() << '(' << sym.line() << "): " <<
>> sym.function() << std::endl;
>>       else
>>         std::cout << sym.name() << std::endl;
>>
>> The sym.name() does a best-attempt at formatting the available information
>> in an implementation-defined way.  Some implementations might have an offset
>> from a (mangled) function symbol name, some might have just an absolute
>> address, etc.  get_symbols() should _attempt_ to retrieve the file name,
>> unmangled function name (with class and scope), line number, etc.  The
>> implementation is free to return all, some, or none of these fields
>> depending on what the platform supports and what information is available
>> (e.g. if debugging information is available for the executable/library in
>> use).
>>
>> As a QoI issue, sym.name() should produce its output in a format that the
>> implementation's preferred IDE natively groks.  e.g., Visual Studio should
>> format things such that lines clicked in the debug output window
>> automatically open the file/line referenced, and a GCC implementation should
>> use its output format that is understood by Vim/EMACS/etc. for the same
>> purpose.  Again, the specific format of sym.name() would be implementation
>> defined and users wanting a specific output would be free to query the
>> individual fields directly, as shown.
>>
>> Prior art scrounged up with 15 seconds on Google:
>>
>>    Some UNIX flavors via GCC APIs:
>> http://www.gnu.org/software/libc/manual/html_node/Backtraces.html and
>> https://github.com/mirrors/gcc/tree/master/libbacktrace
>>    Windows APIs:
>> http://www.codeproject.com/Articles/11132/Walking-the-callstack
>>    OSX and iOS:
>> https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSThread_Class/Reference/Reference.html
>>    Proposed Boost module:
>> http://lists.boost.org/Archives/boost/2010/10/172303.php
>>
>> Most higher-level languages and runtimes have some similar facility, too.
>>
>>
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/jF29zuOkWlo/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.



--
Sean Middleditch
http://seanmiddleditch.com

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

2013/9/17 Sean Middleditch <sean@middleditch.us>:
> On Tue, Sep 17, 2013 at 12:17 PM, Billy O'Neal <billy.oneal@gmail.com> wrote:
>> What do you want to happen when symbol files are not present?
>
> I pretty explicitly covered that, second to last full paragraph.
> Implementation _should_ retrieve as much symbol information as it can,
> but is free to return only some or none of the possible information,
> depending on platform information or availability of symbol data.
> It's still quite useful to get the raw dump of address from a stack
> trace to store and process offline with another tool during
> post-deployment forensics, though of course having the symbols during
> development/debugging is handier still.

I understood the question in the sense whether throwing an exception
or any other error strategy would also be a feasible option.

- Daniel

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On Tue, Sep 17, 2013 at 11:44 AM, Zhihao Yuan <zy@miator.net> wrote:
> On Tue, Sep 17, 2013 at 2:36 PM, Sean Middleditch
> <sean.middleditch@gmail.com> wrote:
>> Every major compiler or platform has some facility to get backtraces, but
>> there is no standard. [...]
>
> FYI, there are some proposals in this area:
>
> http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3757.html
>
> This one does not do backtrace, but also helpful:
>
> http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3757.html

This is the same as the first one, did you mean that?  Neither this
nor the next paper seem to have anything about programmatically
retrieving backtraces but only mention that optional ability for an
exception to include a stack trace in an error string of a thrown
exception.  Exceptions are _hardly_ the only place that such traces
are useful information, and besides, a number of environments don't
even support exceptions but still support other debugging features.
Being able to collect a trace or a portion of a trace efficiently and
turn it into a string _later_ (maybe even out of process) is pretty
critical for memory debugging or in-process profilers (instrumented or
sampling) as common on, say, high-quality game engines.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On Tue, Sep 17, 2013 at 3:57 PM, Sean Middleditch <sean@middleditch.us> wrote:
> This is the same as the first one, did you mean that?

My bad, bad pasting.

http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3441.html

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

2013/9/17 Sean Middleditch <sean@middleditch.us>:
> Exceptions are _hardly_ the only place that such traces
> are useful information, and besides, a number of environments don't
> even support exceptions but still support other debugging features.
> Being able to collect a trace or a portion of a trace efficiently and
> turn it into a string _later_ (maybe even out of process) is pretty
> critical for memory debugging or in-process profilers (instrumented or
> sampling) as common on, say, high-quality game engines.

Agreed. An interesting option to combine exceptions with stacktrace
information is to add it to a corresponding error_info object like
boost::error_info or via

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3757.html

- Daniel

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On Tue, Sep 17, 2013 at 12:59 PM, Zhihao Yuan <zy@miator.net> wrote:
> http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3441.html

No idea how I manged to miss that, but yeah, that looks like almost
exactly what I'd be looking for.  Thank you for the link.

--
Sean Middleditch
http://seanmiddleditch.com

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.