> It's me FKtPp ;) writes:
>
> > When I try to compile XEmacs in mingw32 I notice that none of XEmacs
> > spawned subprocess could work. It was run-in-other-process that used to
> > emulate Unix signal that do not work in my end.
> >
> > I finally get a copy of XEmacs work by replace the run-in-other-process
> > thing with windows native stop process and control break event.
> >
> > Not sure if this is the same case in cygwin.
HST wrote:
> The advice from the Cygwin gurus is that mixing Windows and Cygwin
> process calls is . . . messy at best, but I'll have a look if you pass
> on your patches, please.
Getting back to this. Struggling to remember what little I ever knew
about debugging xemacs under Cygwin using gdb given the multiple
threads involved.
Anyone have any advice?
There are some suggestions around that you have to run under a raw
Windows console to avoid pty-related irrelevancies in the gdb-xemacs
interactions -- true?
What settings are recommended for the various gdb thread-related
controls, such as
non-stop
scheduler-multiple
scheduler-locking
etc. ?
Where do all these threads come from, anyway? If I try the same
pattern of breakpoints (Fstart_process_internal, then send_process) on
my Linux box, no threads involved. . .
Thanks
ht
--
Henry S. Thompson, School of Informatics, University of Edinburgh
10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 650-4587, e-mail: ht(a)inf.ed.ac.uk
URL:
http://www.ltg.ed.ac.uk/~ht/
[mail from me _always_ has a .sig like this -- mail without it is forged spam]
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta