Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0006238OCamlOCaml backend (code generation)public2013-11-14 11:492015-07-10 18:54
Assigned Toshinwell 
PlatformOSOS Version
Product Version 
Target Version4.03.0+devFixed in Version 
Summary0006238: please add an option to enable debug symbols only
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?
TagsNo tags attached.
Attached Files

- Relationships
related to 0006728acknowledged Enable -g and OCAMLRUNPARAM=b by default 

-  Notes
shinwell (developer)
2013-11-18 17:29

I think this is a reasonable thing to do. Watch this space.
gasche (developer)
2013-11-18 19:22

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.
doligez (administrator)
2014-02-19 16:50

Gabriel, your argument addresses backtraces only, not the bound-checking and disabled optimizations.
frisch (developer)
2014-12-23 16:06

> 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.

doligez (administrator)
2015-01-09 18:36

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.

- Issue History
Date Modified Username Field Change
2013-11-14 11:49 ygrek New Issue
2013-11-18 17:28 shinwell Assigned To => shinwell
2013-11-18 17:28 shinwell Status new => assigned
2013-11-18 17:29 shinwell Note Added: 0010644
2013-11-18 17:29 shinwell Status assigned => acknowledged
2013-11-18 19:22 gasche Note Added: 0010648
2014-02-19 16:50 doligez Note Added: 0010951
2014-12-19 15:19 whitequark Relationship added related to 0006728
2014-12-23 16:06 frisch Note Added: 0012963
2015-01-09 18:36 doligez Note Added: 0013044
2015-01-09 18:36 doligez Target Version => 4.02.3+dev
2015-07-10 18:54 doligez Target Version 4.02.3+dev => 4.03.0+dev

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker