Re: [Mingw-users] how to port libcsdbg to mingw

[Tasos P. <t.p...@gm...>]

No worries ;)

On Fri, Oct 25, 2013 at 3:59 PM, K. Frank <kfr...@gm...> wrote:

> Hi Tasos!
>
> My reply is mostly about your library, and not so much about
> mingw, so I guess it's semi-OT.  But let me go ahead anyway.
>


My library instruments all functions in all threads (unless told not to, it
is selectable what to instrument) and simulates the call stacks of all
threads. So anytime, anywhere in the code, you can access this data
and see what any thread is doing... This for example can be done from
a discrete, separate thread. Or it can be done from a signal handler.
libcsdbg
is thread safe, so there will be no data races. In the multithread example
in
libcsdbg/example the process catches SIGINT (all signals are asynchronous)
and dumps all stacks of all threads to the stderr. For example if you
register
a handler for sigsegv and your app crashes it is easy to see what each
thread
was doing, before it crashed.

So, if your code is in c++ (or c) my lib can help. BUT if the crashes happen
inside JVM then jvm itself must be compiled with -finstrument-functions and
linked with libcsdbg. I have done this with the whole QT and it worked fine!

Now as far as i know Linux pthread or other mutexes don't hold the
information
you need, but deadlocks can be resolved, using a signal handler (async) and
therein call my lib. It will give you info about the state of your app when
it locked

For debugging deadlocks I have used a java tool (that relies on an
> api exposed by the jvm) where you can show the stack traces of
> all threads, even though none of them (none of the threads that
> you explicitly control in your program) are running.
>
> These stack traces show you which threads waiting on mutexes
> (e.g., myMutex.wait() at the top of the stack trace), but also show
> you which threads are holding which mutexes.  (This latter might
> not e possible with unmodified windows and/or posix mutexes;
> I think java mutexes are heavier-weight and store who is holding
> them.)  As you can imagine, this level of information can sometimes
> point you directly to the cause of a deadlock.
>
> Is this something your debugger could help with?  Debugging
> deadlocks can sometimes be hard.
>


This is under way, it is one of the main "todos" in the upcoming
version!

Also, regarding threading, it would be great if your debugger
> would work with posix and/or windows threads on windows,
> but (from my perspective), best of all would be if it would work
> out of the box with standard c++11 threads (and be "friendly"
> to c++11 threads, regardless of which threading model (e.g.,
> posix or windows) they're built upon).
>
>

Yeah, you're right. As a matter of fact, libcsdbg only DEPENDS
- only heavily - on g++ (to instrument functions) and on libbfd
(to parse symbol tables). All else it does on its own. The only thing
it needs from the threading system, is to identify the current running
thread (pthread_self() or gettid(), etc). That's all! So the code is
actually *almost* portable for windows and other platforms (with gnu tools).
This is something that the BUILD SYSTEM will address on upcoming versions
 and the "wish" was that would be ready by now!!!... But it isn't...
Actually i'm the author of the lib, while others work on the build system
so i can pull my tail out on this one ;). Anyway you are right, for the time
being i've removed that from the details. You know at freecode that always
takes a while ;)


> I'm a bit confused by one note on the projecgt web site:  You
> list "Windows (32 and 64 bit)" as operating systems.  Does
> that exist now (in some form), or is that future wish-list item?
>
> >
> > and here
> >
> > https://sourceforge.net/projects/libcsdbg/?source=navbar
> >
> > The library currently heavily depends on g++ and on libbfd. i would like
> to
> > port this to mingw to be available to
> > windows c++ developers as well. i know that mingw has bundled the
> binutils
> > package...
> >
> > how easy would be to port the library?
>
>
Thanks for your info, it will come in handy with win32 systems. I knew about
the pthreads-win32 (after all windows IS Posix) stuff but i need to know
about the other threading systems as well. As i said i don't mess with
threads
i just need to identify WHICH ONE is running. So you're on the spot on that.
About other os-dependencies, just minor stuff... For example on linux i use
libdl and dl_iterate_phdr and a little of procfs, to help identify the
program
running and the DSO it loads, to load their symtables AUTOMATICALLY.
If for example i don't find sth similar in mingw, it can always be done by
the
user of libcsdbg calling a function or two, to tell the library what to load

Please subscribe and check the new version coming up in a week or so.
You will see how easy it is to integrate libcsdbg, with multithread programs
that load multiple instrumented DSOs! Just a line of code does that!!!


Let me echo Earnie's answer here:  It could be relatively
> straightforward, or it could be very hard.  It really depends on
> how much low-level posix / os stuff you (or dependencies)
> use.  Without knowing anything about the internals of your
> library, I guessing it will be rather hard.
>
> > does mingw have pthread compatibility (after all its part of glibc)?
> > could any mingw developer help me on this?
>
> Mingw works with (and ships with, I think) a windows pthreads
> library, pthreads-win32, that I am pretty sure is a separate
> project, and not formally part of mingw (but, please, let Earnie
> or somebody correct me if I a wrong).
>
> I'm not an expert, but I believe that pthreads-win32 is a highly
> pthreads-compliant implementation.  However, there is one
> point (that may or may not affect you).  On linux (and all?
> other unix pthreads implementations), a pthread handle is
> an integral value.  In pthreads-win32, it is a structure.  As I
> understand it, the pthreads standard only requires an opaque
> handle, so pthreads-win32 is compliant.  However lots of
> linux pthreads client code makes use of the fact that the
> handle is an integer.  If your code (or its dependencies) do
> that, you'll have to unravel that little knot.
>
>
> K. Frank
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
> _______________________________________________
> MinGW-users mailing list
> Min...@li...
>
> This list observes the Etiquette found at
> http://www.mingw.org/Mailing_Lists.
> We ask that you be polite and do the same.  Disregard for the list
> etiquette may cause your account to be moderated.
>
> _______________________________________________
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
> Also: mailto:min...@li...?subject=unsubscribe
>