adding -ticky to, say, WAY_debug_HC_OPTS?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

adding -ticky to, say, WAY_debug_HC_OPTS?

Nicolas Frisby
(I admit that I remain intimidated by the build system.)

I'm renabling some ticky counter bumps from within the RTS. The most direct
path I see to this involves adding -ticky to makefile variables such
as WAY_debug_HC_OPTS. (See the APPENDIX for why I need that.)

It seems that the debug way is only used in the build system for building
the RTS. Is that right?

If so, will a flag added to the debug HC_OPTS vars in ways.mk only be used
when compiling from .cmm sources? If so, my -ticky flag won't be putting
ticky counters into any .o file where I'm not expecting them, right?

So:

1) Is it a bad idea to add -ticky to the non-threaded and
non-profiling WAY_debug*_HC_OPTS variables in ways.mk?

2) Alternative designs? A few come to mind, but they're more
invasive/fragile.

Thank you for your time.



APPENDIX

For example:

 * The (generated) definition of stg_ap_*_info uses BUILD_PAP

 * The definition of BUILD_PAP uses TICK_ALLOC_PAP

 * TICK_ALLOC_PAP is elaborated by CmmParse.y using
StgCmmTicky.tickyAllocPAP

  * tickyAllocPAP emits no code unless Opt_Ticky is present.

  * -ticky is not currently in the relevant command lines
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130325/dc0848fa/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

adding -ticky to, say, WAY_debug_HC_OPTS?

Simon Marlow-7
On 25/03/13 10:35, Nicolas Frisby wrote:
> (I admit that I remain intimidated by the build system.)
> I'm renabling some ticky counter bumps from within the RTS. The most
> direct path I see to this involves adding -ticky to makefile variables
> such as WAY_debug_HC_OPTS. (See the APPENDIX for why I need that.)
> It seems that the debug way is only used in the build system for
> building the RTS. Is that right?
 >
> If so, will a flag added to the debug HC_OPTS vars in ways.mk
> <http://ways.mk> only be used when compiling from .cmm sources? If so,
> my -ticky flag won't be putting ticky counters into any .o file where
> I'm not expecting them, right?

I think that approach should be fine, but it wouldn't hurt to do some
sanity checks (e.g. log the build output and search for occurrences of
-ticky, to make sure it doesn't leak somewhere you don't expect it to).

Cheers,
        Simon


> So:
> 1) Is it a bad idea to add -ticky to the non-threaded and
> non-profiling WAY_debug*_HC_OPTS variables in ways.mk <http://ways.mk>?
> 2) Alternative designs? A few come to mind, but they're more
> invasive/fragile.
> Thank you for your time.
> APPENDIX
> For example:
>   * The (generated) definition of stg_ap_*_info uses BUILD_PAP
>   * The definition of BUILD_PAP uses TICK_ALLOC_PAP
>   * TICK_ALLOC_PAP is elaborated by CmmParse.y using
> StgCmmTicky.tickyAllocPAP
>    * tickyAllocPAP emits no code unless Opt_Ticky is present.
>    * -ticky is not currently in the relevant command lines
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>