- User Since
- May 14 2018, 8:27 AM (18 w, 1 d)
Thu, Sep 6
Wed, Sep 5
Tue, Aug 28
Remove unused symbol
As I mentioned before this patch actually has no effect on dtrace. My first conclusion was caused by the non-deterministic nature of the problem i.e. dtrace behavior may change after recompilation of the same file. But the process always crashes under dtrace.
Fri, Aug 24
Addressing @simonmar comments
Rebase on remote/master
Should fix tests
Thu, Aug 23
Have you tried debugging on Linux? I believe that perf can use dtrace probe points.
Mon, Aug 20
@lelf Yeah. It looks like this renders dtrace totally unusable (or more unusable). On 8.4.3 and master ghc crashes after getting some probes (https://ghc.haskell.org/trac/ghc/ticket/15543) but with this patch, it crashes immediately. Any clues? (I have almost no idea how dtrace works, how to debug it and how to debug ghc on MacOS, there is even no stack trace in lldb)
Aug 17 2018
There is one test failure not related to the changes (I reproduced on the parent commit)
Aug 16 2018
Pushing to staging
Rebase to fix submodule changes
Aug 15 2018
@lelf I ran two binaries built with stock ghc 8.4.2 and my patch on top of the master and very the same results from dtrace
Aug 10 2018
Aug 9 2018
Jun 27 2018
@bgamari ping :)
Jun 25 2018
Do we care that perf will say 0x0000000000331e15 instead of s3ri_info?
I don't think there is any difference for a normal user between an address and a random symbol.
Always keep top-level fn symbols and dsp
Jun 20 2018
@angerman I successfully built a simple binary and a stage2 compiler with -fllvm. Do you have an idea what can go wrong and what/how should I test?
Jun 19 2018
It took a while to answer :)
Jun 18 2018
I have an idea why it's happening and I plan to investigate it later.
Address the comments
Jun 12 2018
Include @simonmar comment into the code
Make comment readable
Addressing comments and making a code comment readable
May 24 2018
May 23 2018
Could you provide the same Perf-list without the D4713 interaction?
This patch only makes sense on top of the D4713.
@simonmar Knowing perf logic I can speculate why we do have more unknown addresses after D4713 but this actually requires a separate investigation. I can explain how perf treats symbols if you want.
As a proof that D4713 and not this diff leads to the increase of the unknown addresses:
- Stock GHC (15 unknown addresses in Haskell) https://gist.github.com/last-g/80d3f5b81f2430cc3c8760a58a53d277
- D4713 (42 unknown addresses in Haskell) https://gist.github.com/last-g/77b061a20f17bc9539aad7f4f4affe14
- D4713 + D4722 (this one) (43 unknown addresses in Haskell) https://gist.github.com/last-g/76be1a8ca77b07d3c9e7d6e81f643031
May 22 2018
this reduces the granularity of labels. The perf output in particular becomes is obviously less detailed, and also worryingly seems to have more unknown addresses in it.