Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

please add an option to enable debug symbols only #6238

Open
vicuna opened this issue Nov 14, 2013 · 19 comments
Open

please add an option to enable debug symbols only #6238

vicuna opened this issue Nov 14, 2013 · 19 comments

Comments

@vicuna
Copy link

vicuna commented Nov 14, 2013

Original bug ID: 6238
Reporter: @ygrek
Assigned to: @mshinwell
Status: acknowledged (set by @mshinwell on 2013-11-18T16:29:38Z)
Resolution: open
Priority: normal
Severity: feature
Target version: undecided
Category: back end (clambda to assembly)
Related to: #6728
Monitored by: @gasche @ygrek @yakobowski @alainfrisch

Bug description

Rationale:
currently option -g mixes several things up - generation debug symbols, storing backtrace information, adding more precise bounds checking, disabling some optimizations (in bytecode).
For profiling one usually wants the same binary code that is run in production but with debug symbols. So the speed of the code is the same, but there is some extra information available on demand, and this build can be run on production at highest speed and then profiled live if any problem arises. Option -g makes this approach less attractive because of incurred performance cost (e.g. storing backtrace).
Can we please have another option to only write out (native, i.e. DWARF) debugging info and perform no other changes to generated code?

@vicuna
Copy link
Author

vicuna commented Nov 18, 2013

Comment author: @mshinwell

I think this is a reasonable thing to do. Watch this space.

@vicuna
Copy link
Author

vicuna commented Nov 18, 2013

Comment author: @gasche

While I think this is a reasonable feature, I think that in the long term the way to go is rather to provide more control to performance-conscious users of which raises will trigger backtrace recording (eg. the raise-variants work of Alain). Indeed, there should be a sweet spot where most exceptions used for control flow do not record any trace, only actually exceptional exceptions do, and you have a system that is both efficient (essentially as the no-trace one) and auditable in case of unplanned failure (a good reason to have some backtraces even in production). I can understand people disabling everything for absolute performances (and right now it's probably easier to implement), but long-term I think that's more of a minority use-case.

Of course if someone is ready to do the work, that's great in any case.

@vicuna
Copy link
Author

vicuna commented Feb 19, 2014

Comment author: @damiendoligez

Gabriel, your argument addresses backtraces only, not the bound-checking and disabled optimizations.

@vicuna
Copy link
Author

vicuna commented Dec 23, 2014

Comment author: @alainfrisch

more precise bounds checking

Have you seen cases where keeping multiple call sites for caml_ml_array_bound_error yields a noticeable performance penalty?

disabling some optimizations (in bytecode)

Since the request is to have a mode with maximal runtime performance (while keeping debugging information), I don't think that bytecode is relevant.

Alain

@vicuna
Copy link
Author

vicuna commented Jan 9, 2015

Comment author: @damiendoligez

In any case, the request is for adding debugging info to the executable, while guaranteeing no run-time overhead, and this seems quite reasonable to me.

@vicuna
Copy link
Author

vicuna commented Apr 18, 2016

Comment author: @gasche

Mark, is it time for a gentle ping?

@vicuna
Copy link
Author

vicuna commented Jun 9, 2016

Comment author: @mshinwell

Please see the comment on the pull request

#574

@github-actions
Copy link

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

@github-actions github-actions bot added the Stale label May 15, 2020
@jberdine
Copy link
Contributor

Just for info, we would appreciate such a full-speed plus debug info binary mode.

@gasche gasche removed the Stale label May 15, 2020
@gasche
Copy link
Member

gasche commented May 15, 2020

Thanks @jberdine for your help with bug triaging (and your feedback) these days.

@github-actions
Copy link

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

@damiendoligez
Copy link
Member

@gasche do you think this could be a "good first issue"?

@gasche
Copy link
Member

gasche commented Jul 22, 2021

Yes, but I think that we should start gathering a consensus on the naming of such an option, because while the implementation may be relatively simple, picking a good name probably is not.

@github-actions
Copy link

github-actions bot commented Aug 3, 2022

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

@github-actions github-actions bot added the Stale label Aug 3, 2022
@github-actions github-actions bot closed this as completed Oct 5, 2022
@Octachron Octachron reopened this Oct 5, 2022
@Octachron
Copy link
Member

The feature wish seems reasonable to me, and seems to have only be stuck due to naming paralysis.

@github-actions github-actions bot removed the Stale label Oct 7, 2022
@cjc25
Copy link

cjc25 commented Oct 8, 2022

In case someone is waiting for name inspiration, clang uses -gmlt ("minimum line table") to include symbol info only (e.g. function {names, filenames, line numbers}). gcc analogously has -g1

@ygrek
Copy link
Contributor

ygrek commented Oct 10, 2022

-glevel options for gcc only change the amount of debugging information emitted, it doesn't change emitted code, this is what this issue is about

@nojb
Copy link
Contributor

nojb commented Oct 10, 2022

Sorry for the naïve question, but as the issue description above mentions native code, what "debug symbols" are we talking about? The location information for each instruction?

@ygrek
Copy link
Contributor

ygrek commented Oct 10, 2022

(native, i.e. DWARF) debugging info

previously (at the time this issue was created) it was function names, afaihs now we also have source locations

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

9 participants