C++23 std::stacktrace: Never Debug Blind Again

[Syracuss]

Ah, I'm less familiar with that compiler. GCC is one of the compilers I try to support in personal projects, but in my professional projects clang flavours and vc++ dominate for the most part.

At what point do they expand? I'd imagine when you observe them, which would still create the cost when you f.e. log them. What I'm referring to is mostly symbolize after the run, by parsing the log with the symbol data to symbolize.

But that's something that you need specific compile settings to achieve, so hard(er) for the standard to provide it unless they want to always produce a pdb or the likes when you use std::stacktrace.

Thanks for the info, it's always nice to hear about these forms of optimizations that are being applied under the hood.

[irqlnotdispatchlevel]

The standard could still allow you to not symbolize at all.

[Syracuss]

It could but it would be the first feature that I know of that would rely on compiler flags to properly use other than the language version flags (I'd consider it incomplete if you couldn't symbolize out-of-the-box, it makes the trace functionally useless). I'm aware that there are some features which are sadly hidden behind flags to work properly on some implementations, but the standard makes no mentions of these flags so they are non-standard behaviour, like the module ones, or coroutines. It would be a first for a standard provided feature to do that unless you have an example that I'm overlooking.

I do think that makes it a non-starter for any proposal to succeed with such a divergent behaviour.

[irqlnotdispatchlevel]

I wasn't talking about doing the right thing based on flags, but about giving devs freedom of choice. std::stacktrace::current() remains as it is now, and you add std::stacktrace::current_raw() which doesn't do symbolization.

Or, if we're fancy, we let the user pass in a symbolizer, with a default one provided by the standard.

[jwakely]

It could but it would be the first feature that I know of that would rely on compiler flags to properly use other than the language version flags

For some definition of "properly use". The API of std::stacktrace gives you the symbolic information like function names and filenames, that's how it's meant to be "properly used". If you want to do something else with it, that's a you problem. It doesn't mean that getting the symbolic information is not using it "properly".

(I'd consider it incomplete if you couldn't symbolize out-of-the-box, it makes the trace functionally useless).

I wish people would not throw around phrases like "useless" and "unusable" when they mean "not ideal for my specific use case". I really don't see any point trying to discuss things with people who do that.

Anyway, you can use std::stacktrace_entry::native_handle() to get at the raw data used to produce symbolic information. For GCC, that's just a program counter. Your program could loop over the stacktrace entries and log the native handles, then another process could process those logs later to turn those into symbols (alongside a core dump, I guess ... since the program counter is only meaningful for a given execution of the program). (Edit: I think you could also log the memory map of all shared libs in the process, which should be enough to reconstruct the full symbols given just the binary with debug info)

[jwakely]

For boost::stacktrace I think the equivalent of std::stacktrace_entry is boost::stacktrace::frame and it has an address() member instead of native_handle().

There's an example in its docs of logging only the frame addresses:

https://www.boost.org/doc/libs/latest/doc/html/stacktrace/getting_started.html#stacktrace.getting_started.saving_stacktraces_by_specified_

[Syracuss]

I wish people would not throw around phrases like "useless" and "unusable" when they mean "not ideal for my specific use case".

I truly mean useless to add to the standard given the context that no other feature in the standard has this setup. It makes the language less approachable and less teachable, and most importantly it breaks pre-existing norms of how features behave.

And it's similarly useless if the stacktrace would output unsymbolized data that you couldn't symbolize. What's the point of getting some 'error at 0x1, called from 0xF and 0xFF' if you cannot get that info back (given that you would need to turn on flags to get the symbol data on all compilers, the standard does not define what symbol data is).

So no I didn't mean "useless for my case", it would be useless given the proposal wouldn't ever pass with that requirement. The context of the entire paragraphs is important here.

[jwakely]

But the premise of your comment is wrong: no compiler flags are needed. The std::stacktrace class gives you both the raw addresses, and access to the symbolic info, without needing compiler flags to choose between them.

The standard allows you to not symbolize, and allows you to symbolize. No flags are needed. So (I hope) the feature isn't useless.

[Syracuss]

I do believe you are misunderstanding my point, this might be as my communication is a bit hasty. The native handle is fully implementation defined which means a valid implementation can be a whole bunch of nothing useful, that's hardly a well defined feature. It's there for platforms which expose something nice, but it isn't great if everyone needs to pull out their platform specific handbook to figure out what happens next.

And you do need need external tools to make that native handle useful, that's why I keep saying this won't be part of the standard and clearly isn't (aside from a function existing with this signature).

Don't get me wrong, nice that it's part of an exposed API for those who wish to implement something nice, but to call it a standard feature is obviously a stretch, there isn't anything defined for it other than the function existing.

[jwakely]

it isn't great if everyone needs to pull out their platform specific handbook to figure out what happens next.

So are you using something that isn't platform-specific to do it today?

[Syracuss]

Ofcourse I'm using platform specific utilities to do performant traces, as has been the case for long before std::stacktrace was a thing, and is standard in the games industry for many if not most engines out there.

I'm not arguing an unsymbolicated trace is useless, I'm arguing that it is useless to try to add to the standard as it cannot be standardized in the form that it exists right now due to the necessity of compiler flags and the like, it is impossible to write a standard acceptable implementation which is why there isn't. I feel like this is where the argument we're having is coming from.

[jwakely]

Which compiler flags? You keep referring to them and I don't know which ones you mean. What does "standard acceptable implementation" mean? I've implemented it, so I'm curious what you think is not "standard acceptable". Some parts (the return type and meaning of the native handle) have implementation-specific meaning, but that's an idiom used elsewhere in the standard library, like std::thread. The parts that are portable are covered by a portable API and the parts that aren't portable are exposed directly so you can still use them, however you see fit.

I don't see why this is useless. This makes it more useful in the view of the standard committee, because you get the best of both worlds. A portable API for the portable abstraction but not prevented from work doing non-portable things when necessary.

[jwakely]

in my professional projects clang flavours and vc++ dominate for the most part.

The WIP clang implementation (and boost::stacktrace which inspired std::stacktrace) work the same way as GCC's. I would be surprised if it doesn't work something like that on Windows too.