This is the mail archive of the cygwin mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 10/20/2014 3:03 PM, Corinna Vinschen wrote:
On Oct 20 18:43, Corinna Vinschen wrote:On Oct 20 09:03, Ken Brown wrote:When trying to debug emacs in gdb, I see several threads, but it's not always clear who created those threads and what they're doing. As an example, I attached gdb to an emacs-X11 process (running under X) shortly after starting it, and I obtained the backtrace appended at the end of this message. I assume Thread 12 was created by gdb.[...]I don't have any idea where the other threads came from. Presumably at least one of them was created by Glib. The situation is similar with emacs-w32 and emacs-nox, but with fewer threads. In general, is there a way I can understand where all the threads come from?There's no simple generic way to do that, afaik. One big problem is to have all the symbols. You should definitely install the debuginfo packages of all potentially affected packages, not only cygwin-debuginfo. If you want to find out where threads are called from the application, you might get a clue by running emacs under GDB and set a breakpoint to pthread_create.Btw., I don't know if that helps, but the function names of native Windows functions given in the GDB backtrace may be off because GDB doesn't have access to the Windows DLL symbol tables. If you want to analyze the stacks from that side, you should install WinDbg(*) and the symbol files for your OS(**). If you start the process from WinDbg, you can better see the Windows functions called from these threads, while not getting any info about the functions from inside the application or the Cygwin DLLs.
Thanks, I'll give that a try.
One of the headaches when porting is sometimes the ABI. While on Linux the first 6 arguments to a function are given in registers, on Windows only 4 args are in registers. This can result in bugs when calling functions with more than 4 parameters, which are invisible on Linux, due to the way 32 bit parameter are stored in registers on x86_64. This happened to us already for at least one package.
Am I right in thinking this can only be an issue if the source includes assembler code?
Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |