Building libraries with ticky-ticky
Hi, I have some code I want to use ticky-ticky profiling on (if it matters, I want some of the data ticky-ticky collects about frequency of updates and related matters.) However, I'm specifically interested in the code running with some modificiations I've made to the RTS, so I need to build GHC with ticky-ticky. That in itself isn't hard--the documentation said to just run "make way=t" in rts/, which seemed to work; but the documentation also said that to get meaningful numbers, I should make sure to build the libraries with ticky-ticky (which makes sense--I'm interested in the same data whether or not the updates happen in a function from List or one I wrote, &c.) The documentation does *not*, however, say (anywhere I can find) how to do this! My natural guess was to go into mk/build.mk, and add -ticky to GhcLibHcOpts, but that didn't work (regardless of whether I had previously built a ticky rts, this produced a multitude of linker errors.) I also tried, on a lark, adding "t" to GhcLibWays, and this didn't die, but I'm unclear if it...did anything at all, really. I see no way to really tell one way or another. So, any help or advice on how to tell the GHC build system to build a set of libraries with ticky-ticky profiling enabled would be greatly appreciated. (FWIW, I'm not distributing anything, so it'd be more than adequate for stuff to be broken for non ticky use, I just need to build some test executables and be sure they're logging the right data.) Thanks, AHH
On 7/18/08, Andrew Hunter
The documentation does *not*, however, say (anywhere I can find) how to do this! My natural guess was to go into mk/build.mk, and add -ticky to GhcLibHcOpts, but that didn't work (regardless of whether I had previously built a ticky rts, this produced a multitude of linker errors.) I also tried, on a lark, adding "t" to GhcLibWays, and this didn't die, but I'm unclear if it...did anything at all, really. I see no way to really tell one way or another.
Hi, Andrew-- I'm not surprised that building the libraries with ticky enabled doesn't work, because when I fixed ticky-ticky profiling a year and a half ago after it was bit-rotted, I hardly tested it and all and certainly didn't try building the ticky libraries. If I try "make way=t" in libraries/, which should be the proper way to build the ticky libraries, I get errors, so I'm surprised it succeeded for you (unless the build system thought that the libraries were up-to-date and didn't try building the ticky version.) The reason you got linker errors was because, I assume, you had compiled the libraries with -ticky but you weren't passing the -ticky flag to GHC when you compiled your program. If you don't pass the -ticky flag, GHC doesn't link with the ticky RTS, so the library code will include all sorts of undefined symbols. But since you said below that it's OK if things are broken for non-ticky use, you should just be able to do: $ cd libraries/ $ make clean $ make EXTRA_HC_OPTS=-ticky $ cd [wherever] $ ghc -o foo -ticky foo.hs $ ./foo +RTS -rfoo.ticky -RTS and foo.ticky will contain your profiling report. You just won't be able to compile any programs without -ticky this way. In the meantime, I'll look into making the "ticky" way work so that it'll be possible to have ticky and non-ticky libraries coexisting. If you have any more questions about ticky-ticky profiling, please CC both me and this list, since I don't always read the list carefully. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "Faith, faith is an island in the setting sun / But proof, yes, proof is the bottom line for everyone."--Paul Simon
On Sun, Jul 20, 2008 at 09:08:58PM -0700, Tim Chevalier wrote:
I'm not surprised that building the libraries with ticky enabled doesn't work, because when I fixed ticky-ticky profiling a year and a half ago after it was bit-rotted, I hardly tested it and all and certainly didn't try building the ticky libraries.
I'm not surprised to see this answer--looking at tickets and mailing lists, it was clear that ticky-ticky wasn't in the best of shape, but I couldn't figure out what exactly the state of affairs was, so I figured I'd ask.
The reason you got linker errors was because, I assume, you had compiled the libraries with -ticky but you weren't passing the -ticky flag to GHC when you compiled your program. If you don't pass the -ticky flag, GHC doesn't link with the ticky RTS, so the library code will include all sorts of undefined symbols.
Right--thing is, it seemed I was getting linker errors on compiling the *libraries*--which seems weird, given that the libraries shouldn't be getting linked, should they? I'm not entirely sure this is what I was seeing, so, well, not a huge consideration, but it does seem weird.
But since you said below that it's OK if things are broken for non-ticky use, you should just be able to do: $ cd libraries/ $ make clean $ make EXTRA_HC_OPTS=-ticky $ cd [wherever] $ ghc -o foo -ticky foo.hs $ ./foo +RTS -rfoo.ticky -RTS and foo.ticky will contain your profiling report. You just won't be able to compile any programs without -ticky this way.
After removing "p" from GhcLibWays, which makes sense--the docs make it clear we can't combine prof and ticky, though it also implies that it maybe *should* work; might someone what to look into this?--this worked great, thanks. My tests are running nicely and giving what seems like accurate data. Thanks for the very helpful response.
In the meantime, I'll look into making the "ticky" way work so that it'll be possible to have ticky and non-ticky libraries coexisting.
Sweet. Admittedly I'm not yet a GHC wizard, but I'd love to help out by fixing this--do you have a rough idea of what would need to be done, or what in fact is the current problem? Thanks a lot, AHH
On 7/20/08, Andrew Hunter
Right--thing is, it seemed I was getting linker errors on compiling the *libraries*--which seems weird, given that the libraries shouldn't be getting linked, should they? I'm not entirely sure this is what I was seeing, so, well, not a huge consideration, but it does seem weird.
That is indeed weird, and I don't know why that would be happening. It didn't happen after you rebuilt in a clean directory, though, right? (Or at least that's what you seem to imply below.)
After removing "p" from GhcLibWays, which makes sense--the docs make it clear we can't combine prof and ticky, though it also implies that it maybe *should* work; might someone what to look into this?--this worked great, thanks. My tests are running nicely and giving what seems like accurate data. Thanks for the very helpful response.
I think combining prof and ticky might be nontrivial, because the RTS has all sorts of conditional compilation in it that may be predicated on prof and ticky being mutually exclusive. At least, it's not something I would want to dive into implementing unless I had a good reason, and after all, you can just recompile the same code repeatedly with different options to get both prof and ticky results (although that could get annoying.)
Sweet. Admittedly I'm not yet a GHC wizard, but I'd love to help out by fixing this--do you have a rough idea of what would need to be done, or what in fact is the current problem?
I'm not a GHC wizard either, which is why the code that's there doesn't work so well. And I suspect that solving the problem will require some build system hacking, which is an area I'm not familiar with at all, so I can't give much advice about how to solve the problem. You're welcome to try, though. I added a ticket at: http://hackage.haskell.org/trac/ghc/ticket/2455 so if you make any progress, you should add a comment there. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "What doesn't kill you makes you look really, really bad." --Carrie Fisher
participants (2)
-
Andrew Hunter -
Tim Chevalier