public inbox for cygwin-developers@cygwin.com
 help / color / mirror / Atom feed
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

  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).