RE: Release plans
On 20 July 2004 01:43, Bernie Pope wrote:
Since you are working on the backend is there any chance that GHC could support symbol names in the heap?
I tried to add this previously and failed miserably.
I would be happy with a flag, such as '-debug-symbols' or somesuch, that keeps source symbol names, at least for data constructors, and possibly functions.
This would be a BIG win for buddha and possibly other debugging tools.
Currently I have to turn on -prof which is a bad hack.
This is a good suggestion, but it's unlikely that we'll have time to add it before the release. I'd like to see us support more debugging information, preferably in a way that can be stripped from a binary. I'm not sure that we want to have yet another "way" to build libraries. Debugging is something that should be easy, otherwise the effort is too much and we resort to using Debug.trace (I'm guilty of this - I confess to never having tried any of the available debuggers simply because they're not immediate enough).
Will there be any big changes to the heap representation of objects with the new backend?
No change at all. Cheers, Simon
On Tue, Jul 20, 2004 at 09:29:38AM +0100, Simon Marlow wrote:
On 20 July 2004 01:43, Bernie Pope wrote:
Since you are working on the backend is there any chance that GHC could support symbol names in the heap?
I tried to add this previously and failed miserably.
I would be happy with a flag, such as '-debug-symbols' or somesuch, that keeps source symbol names, at least for data constructors, and possibly functions.
This would be a BIG win for buddha and possibly other debugging tools.
Currently I have to turn on -prof which is a bad hack.
This is a good suggestion, but it's unlikely that we'll have time to add it before the release. I'd like to see us support more debugging information, preferably in a way that can be stripped from a binary.
Good point.
I'm not sure that we want to have yet another "way" to build libraries.
I'm with you on that one.
Debugging is something that should be easy, otherwise the effort is too much and we resort to using Debug.trace (I'm guilty of this - I confess to never having tried any of the available debuggers simply because they're not immediate enough).
True. In the back of my mind I had the notion that C-- would provide some infrastructure for symbol tables and whatnot. Anyway I can see that this is not the kind of thing to jump into too hastily. Cheers, Bernie.
I'd like to see us support more debugging information, preferably in a way that can be stripped from a binary.
The easy way would be as .stabs entries since that's what gdb uses. However, stabs entries themselves are absolutely horrible (the design obviously started simple and acquired a bunch of ad hoc hacks along the way). But if you're willing to encode everything as strings, you could spit out a bunch of what look like filename directives but put general data in the strings instead of filenames. (Or read up on stabs directives carefully and try to force-fit Haskell into a design made for C, C++, etc.) -- Alastair
participants (3)
-
Alastair Reid -
Bernie Pope -
Simon Marlow