How to work out why a data constructor is allocated using gdb?

[Matthew Pickering]

It occurred to me today that in order to work out where a constructor
is allocated from you can look in the profiling header.

The profiling header contains information about the cost centre stack
at the precise point of allocation. You should be able
to look at this to see what the call stack was and the source position
of the cost centre at the bottom of the stack.

Cheers,

Matt

On Tue, Aug 13, 2019 at 8:29 AM Matthew Pickering
<matthewtpickering at gmail.com> wrote:
>
> Hi,
>
> I am trying to work out questions such as
>
> * Why are there thousands of Module data constructors allocated when
> building something with GHC
> * What is allocating all a lot of strings when building GHC?
>
> In order to do this I can use gdb in order to find some of the
> Module/String closures but then I'm a bit stuck about what to do.
>
> gdb displays a list of all the Module closures for example and then
> you can usually try to find the retainer for Module by using findPtr.
>
> If the retainer is a THUNK closure, it would be easy, as THUNK
> closures have DWARF information which maps straight to a particular
> line. However if the retainer is just some other
> data constructor, for example, the Module is stored in a Map, it's
> data constructors all the way up and none of them have DWARF info. I
> need to fall back to domain specific knowledge
> to work out where such a sequence of constructors might appear in my program.
>
> * Is there anything better I can do to map a constructor allocation to
> a more precise source location?
>
> The string closures were causing me some particular issues as
> `findPtr` was not showing any retainers so it's hard to work out why
> they are not GCd.
>
> * What situations can an object be retained but show no retainer when
> using findPtr?
>
> Cheers,
>
> Matt