From: Mark Geisert <mark@maxrnd.com>
To: cygwin-developers@cygwin.com
Subject: Re: Maybe consider rpmalloc
Date: Sun, 18 Apr 2021 22:16:00 -0700 [thread overview]
Message-ID: <bc002288-9481-e92c-6171-827472a12dbc@maxrnd.com> (raw)
In-Reply-To: <e82d01ea-e56b-e949-1188-ffac6d04875a@dronecode.org.uk>
Jon Turney wrote:
> On 14/04/2021 09:19, Mark Geisert wrote:
>> I need to identify what's being hit within ntdll.dll. Is it one or two
>> routines, or just hot locks. So that means getting the correct PDB file from
>> the MS Symbol Server and working with Windows tools I'm unfamiliar with. Sigh,
>> in an earlier life I had a gdb that we'd taught how to work
>
> Yes, this would indeed be a very useful thing to have in gdb.
>
> I'm not aware of any public work in that direction, though.
>
>> with PDB files; dunno if I could resurrect that. Profiling the Cygwin DLL
>> itself, call profiling I mean, might lead somewhere as well.
>
> In the past I've had some success with using the Very Sleepy profiler ([1]), which
> can use both PDB and DWARF symbols, on cygwin executables.
>
> [1] https://github.com/VerySleepy/verysleepy
Thanks for that link, Jon. That tool is potentially very useful. Are you sure it
understands DWARF though? It seems to show only a subset of cygwin1.dll symbols
but I can't immediately tell why those and not others. Perhaps they're just the
unmangled names present in the COFF symbol table?
Did you do anything in particular to assist it with debugging Cygwin exes? Like
adding to the Symbol Cache it builds? I only see PDB files in its cache so far.
I think building a "fake" PDB file for cygwin1.dll might be good enough, but if
there's an easier way I'd love to hear it.
Thanks again,
..mark
next prev parent reply other threads:[~2021-04-19 5:16 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-25 6:01 Cygwin malloc tune-up status Mark Geisert
2020-09-27 16:54 ` Johannes Schindelin
2020-09-29 2:22 ` Mark Geisert
2021-04-01 9:19 ` Teemu Nätkinniemi
2021-04-02 5:45 ` Maybe consider rpmalloc -- Was: " Mark Geisert
2021-04-03 2:53 ` Maybe consider rpmalloc Mark Geisert
2021-04-03 6:46 ` Teemu Nätkinniemi
2021-04-03 6:48 ` Teemu Nätkinniemi
2021-04-11 9:28 ` Mark Geisert
2021-04-12 8:48 ` Teemu Nätkinniemi
2021-04-13 8:24 ` Mark Geisert
2021-04-13 13:05 ` Teemu Nätkinniemi
2021-04-14 8:19 ` Mark Geisert
2021-04-14 18:36 ` Teemu Nätkinniemi
2021-04-14 18:53 ` Jon Turney
2021-04-19 5:16 ` Mark Geisert [this message]
2021-04-20 19:34 ` Jon Turney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bc002288-9481-e92c-6171-827472a12dbc@maxrnd.com \
--to=mark@maxrnd.com \
--cc=cygwin-developers@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).