Re: Issue with GDB under Cygwin and XP
A Monday 18 February 2008 03:55:45, Ray Hurst wrote: > Di I need to actually take the source changes from this thread and apply > them to my build? > Or is there a patch file available? That *is* a patch file. It's a text file with inline disposition, so you can get at the exact file contents without html munging by clicking "Raw text" link at the top of the page. You could also use the mailer support for retrieving messages but would be harder I guess. Or, you could wait a few days until I submit new patches upstream. -- Pedro Alves -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Issue with GDB under Cygwin and XP
A Sunday 17 February 2008 03:37:38, Christopher Faylor wrote: > On Sun, Feb 17, 2008 at 03:19:02AM +0000, Pedro Alves wrote: > >http://sourceware.org/ml/gdb-patches/2007-11/msg00567.html > > Was that patch applied? AFAICT from the ChangeLog's it wasn't. > > If not, have you pinged anyone about this Pedro? > Sorry for the 3AM-not-saying-anything-else-but-post-a-patch-link, and not noticing the thread was broken, so the follow-ups were not linked from that message. http://sourceware.org/ml/gdb-patches/2007-12/msg00049.html http://sourceware.org/ml/gdb-patches/2007-12/msg00439.html No, it's not appied yet. I need to split the patch into 2 or 3 parts before it is has a chance of being checked in upstream. I'll see if I can find time by the end of the week. Notice that this is a problem with stabs debug info. With dwarf you don't get this problem. -- Pedro Alves -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Issue with GDB under Cygwin and XP
A Friday 15 February 2008 23:21:45, Ray Hurst wrote: > Here is a run of a HellowWorld program (listed below in gdb). > > Can someone tell me why the variables a, b, c are not the correct > values. I dumped the local stack and the variables are correct on the > stack. > > I'm running Windows XP under cygwin. > gcc 4.2.3 > http://sourceware.org/ml/gdb-patches/2007-11/msg00567.html -- Pedro Alves -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.5.24-2: unalbe to get a core Dump file
Brian Dessent wrote: As already mentioned downthread, if you want a core dump you should simply set error_start=c:/cygwin/bin/dumper.exe, modulo dumper bugs (which should have all been fixed in the latest version.) The cvs version still doesn't work for me if I link it with the distributed bfd -- it crashes in that case. The latest fixes were done with a bfd from cvs. I haven't tried the latest test version, but should have the same problem. -- Pedro Alves -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [gdb] Data watchpoints in Windows weirdness. Call for testers.
René Berber wrote:
Pedro Alves wrote:
Corinna Vinschen wrote:
Gdb 6.6 (installed with Insight 6.6) doesn't seem to have the problem:
Unfortunatelly it does. :( If you are seing a different output, it
may be because you built the test app with different -O setting.
-O0 is better for watchpoint support, as at higher optimization
levels, the variables may be loaded in registers, and so you won't
see some writes.
8 {
(gdb) c
Continuing.
Program received signal SIGTRAP, Trace/breakpoint trap.
main () at test.c:11
11printf ("count %d\n", count);
(gdb)
Continuing.
Here gdb could't determine which watchpoint triggered, so it
didn't evaluate the watched expressions, and didn't show
the old/new values. It should have shown:
> Old value = 0
> New value = 999
due to the 'count = 999;'
Hardware watchpoint 1: count
Old value = 0
New value = 1000
Here you should have seen:
> Old value = 999
> New value = 1000
The problem is shown in your log file:
gdb: kernel event for pid=1444 tid=2104 code=EXCEPTION_DEBUG_EVENT)
gdb: Target exception EXCEPTION_SINGLE_STEP at 0x00401099
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x401099
stopped_data_addr:
CONTROL (DR7): 000d0101 STATUS (DR6):
DR6 should have been != 0.
DR0: addr=0x00403010, ref.count=1 DR1: addr=0x, ref.count=0
DR2: addr=0x, ref.count=0 DR3: addr=0x, ref.count=0
infrun: random signal 5
^^^
Hence, gdb assumed it was random.
Program received signal SIGTRAP, Trace/breakpoint trap.
infrun: stop_stepping
remove_watchpoint (addr=403010, len=4, type=data-write):
CONTROL (DR7): 000d0100 STATUS (DR6):
DR0: addr=0x, ref.count=0 DR1: addr=0x, ref.count=0
DR2: addr=0x, ref.count=0 DR3: addr=0x, ref.count=0
main () at test.c:11
11printf ("count %d\n", count);
(gdb) c
I've reproduced it in a MinGW gdb. So I'm now 100% sure it is not a
Cygwin problem.
I'm still thinking that it is a gdb bug, in the sense that there must be
something different with the debug registers handling that I didn't quite
understand yet. I'll try to build a small native win32 minimal debugger
that reproduces it, and if that doesn't make the problem obvious, post
a query in some Windows discussion group.
Thanks again!
Cheers,
Pedro Alves
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: [gdb] Data watchpoints in Windows weirdness. Call for testers.
Corinna Vinschen wrote: I could reproduce it on Win2K SP4, Vista, and under WOW64 on Vista 64. Thank you. Cheers, Pedro Alves -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [gdb] Data watchpoints in Windows weirdness. Call for testers.
René Berber wrote: (...) Program received signal SIGTRAP, Trace/breakpoint trap. main () at main.c:18 18Sleep (1000); (gdb) p count $3 = 1001 (gdb) c Continuing. Hardware watchpoint 2: count Old value = 0 New value = 1002 (...) Thanks! That clearly shows the exact same problem. Somehow, the code in the while(1) loop starts behaving, and for the same executable, the symptom manifests exactly across machines. If one tweaks the program a little, the problem shows up in different lines. Could you tell me what version of Windows was that? I'd be perfect if someone with access to a Windows != XP machine could do the same test. Cheers, Pedro Alves -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [gdb] Data watchpoints in Windows weirdness. Call for testers.
Christopher Faylor escreveu:
On Mon, Oct 08, 2007 at 02:43:31PM +0200, Corinna Vinschen wrote:
On Oct 3 01:47, Pedro Alves wrote:
By a long shot, Cygwin doesn't do anything funny like hooking
GetThreadContext, does it?
cgf might be better suited to answer this, but AFAICS, Cygwin
doesn't hook any system function. It just uses them.
Cygwin doesn't hook GetThreadContext or any other system call. It does play
with the threads stack frame when the thread is first created however.
OTOH, there are two calls to SetThreadContext in Cygwin, both of them
changing Eip. Could that be a problem?
Those should only be triggered in circumstances where a cygwin program
is interrupted outside of the cygwin dll itself.
Thanks guys. I would imagine that to make a difference the
GetThreadContext in the context of gdb itself would have to be hooked.
Any change someone does the little testing to make sure I'm not
having a local problem here?
as easy as:
gcc main.c -o main.exe -g3 -O0
gdb main.exe
start
watch count
'continue' several times, and send me or post here the results.
A log with the these on would be nice, but not essencial:
set debug infrun 1
set debugevents 1
set debugexceptions 1
maint show-debug-regs 1
Cheers,
Pedro Alves
#include
#include
volatile int count = 0;
int
main ()
{
printf ("count %d\n", count);
count = 999;
printf ("count %d\n", count);
count++;
while (1)
{
printf ("count %d\n", count);
count++;
Sleep (1000);
}
return 0;
}
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
[gdb] Data watchpoints in Windows weirdness. Call for testers.
DR2: addr=0x, ref.count=0 DR3: addr=0x,
ref.count=0
infrun: random signal 5
^^^
Program received signal SIGTRAP, Trace/breakpoint trap.
infrun: stop_stepping
remove_watchpoint (addr=403010, len=4, type=data-write):
CONTROL (DR7): 000d0100 STATUS (DR6):
DR0: addr=0x, ref.count=0 DR1: addr=0x,
ref.count=0
DR2: addr=0x, ref.count=0 DR3: addr=0x,
ref.count=0
main () at main.c:11
11printf ("count %d\n", count);
A good run:
(gdb) c
Continuing.
infrun: proceed (addr=0x, signal=144, step=0)
insert_watchpoint (addr=403010, len=4, type=data-write):
CONTROL (DR7): 000d0101 STATUS (DR6):
DR0: addr=0x00403010, ref.count=1 DR1: addr=0x,
ref.count=0
DR2: addr=0x, ref.count=0 DR3: addr=0x,
ref.count=0
infrun: resume (step=0, signal=0)
ContinueDebugEvent (cpid=4112, ctid=4740, DBG_CONTINUE);
infrun: wait_for_inferior
gdb: kernel event for pid=4112 tid=4740 code=EXCEPTION_DEBUG_EVENT)
gdb: Target exception EXCEPTION_SINGLE_STEP at 0x004010c9
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x4010c9
watchpoint_hit (addr=403010, len=-1, type=data-write):
CONTROL (DR7): 000d0101 STATUS (DR6): 0ff1
DR0: addr=0x00403010, ref.count=1 DR1: addr=0x,
ref.count=0
DR2: addr=0x, ref.count=0 DR3: addr=0x,
ref.count=0
infrun: BPSTATE_WHAT_STOP_NOISY
infrun: stop_stepping
remove_watchpoint (addr=403010, len=4, type=data-write):
CONTROL (DR7): 000d0100 STATUS (DR6): 0ff1
DR0: addr=0x, ref.count=0 DR1: addr=0x,
ref.count=0
DR2: addr=0x, ref.count=0 DR3: addr=0x,
ref.count=0
Hardware watchpoint 2: count
Old value = 0
New value = 1001
main () at main.c:18
18Sleep (1000);
So, again, can anyone confirm me this behavior, preferably on
different Windows versions, so I can either submit a workaround
patch upstream, or fix it in a better way? You can test with
stock Cygwin gcc and gdb.
For the brave souls that want to test a workaround, the fix_hwatch.diff
patch applies to gdb's CVS head. It isn't cleaned up, but shows what
I've been testing if you're curious - the important change is in
cygwin_get_dr6.
Thanks!
Cheers,
Pedro Alves
#include
#include
volatile int count = 0;
int
main ()
{
printf ("count %d\n", count);
count = 999;
printf ("count %d\n", count);
count++;
while (1)
{
printf ("count %d\n", count);
count++;
Sleep (1000);
}
return 0;
}
---
gdb/win32-nat.c | 136 +++-
1 file changed, 126 insertions(+), 10 deletions(-)
Index: src/gdb/win32-nat.c
===
--- src.orig/gdb/win32-nat.c 2007-10-03 01:28:32.0 +0100
+++ src/gdb/win32-nat.c 2007-10-03 01:29:18.0 +0100
@@ -103,6 +103,15 @@ static int debug_registers_used;
#define DEBUG_MEM(x) if (debug_memory) printf_unfiltered x
#define DEBUG_EXCEPT(x) if (debug_exceptions) printf_unfiltered x
+//#define DO_DEBUG_DR
+
+#ifdef DO_DEBUG_DR
+# define DEBUG_DR(x) \
+ do { printf_unfiltered x; } while (0)
+#else
+# define DEBUG_DR(x) do ; while (0)
+#endif
+
static void win32_stop (void);
static int win32_win32_thread_alive (ptid_t);
static void win32_kill_inferior (void);
@@ -259,6 +268,25 @@ thread_rec (DWORD id, int get_context)
else if (get_context < 0)
th->suspend_count = -1;
th->reload_context = 1;
+
+#ifdef DO_DEBUG_DR
+ {
+ DEBUG_DR (("thread_rec\n"));
+ memset (&th->context, 0, sizeof th->context);
+ th->context.ContextFlags = CONTEXT_DEBUGGER_DR;
+ CHECK (GetThreadContext (th->h, &th->context));
+ /* Copy dr values from that thread. */
+ dr[0] = th->context.Dr0;
+ dr[1] = th->context.Dr1;
+ dr[2] = th->context.Dr2;
+ dr[3] = th->context.Dr3;
+ dr[6] = th->context.Dr6;
+ dr[7] = th->context.Dr7;
+ DEBUG_DR (("dr0 = 0x%x\n", (int)dr[0]));
+ DEBUG_DR (("dr6 = 0x%x\n", (int)dr[6]));
+ DEBUG_DR (("dr7 = 0x%x\n", (int)dr[7]));
+ }
+#endif
}
return th;
}
@@ -282,6 +310,7 @@ win32_add_thread (DWORD id, HANDLE h)
thread_head.next = th;
add_thread (pid_to_ptid (id));
/* Set the debug registers for the new thread in they are used. */
+ DEBUG_DR (("win32_add_thread dr6 = 0x%x\n", (int)dr[6]));
if (debug_registers_used)
{
/* On
Re: Latest mutt (1.4.2.2-1) does not work on (my) XP
I just downloaded the source and compiled it, *without changing anything*, and the resulting binary worked without problems. The final binary also has only 526kb, much smaller than the one I got from the same binary package. (I was expecting +- the same output) Hope it helps Thanks -- Pedro Alves [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Latest mutt (1.4.2.2-1) does not work on (my) XP
Attached cygcheck output On Mon, Aug 20, 2007 at 10:57:52PM +0100, Pedro Alves wrote: > > > Hello. > > > I can't run latest mutt, version mutt-1.4.2.2-1 on my XP. For every > operation I try to do I get an error like 'cannot create temporary file'. > It's not a permission problem... files are created (even tried different > temp dirs) with 0 size. > > > Reverting to version 1.4.2.1i-1 everything works. > > > I don't know what changed, but the main binary of 1.4.2.1i-1 has 539136 > bytes and 1.4.2.2-1 has 1554944 bytes (3 times more). > > > Tips appreciated. > > > Thanks > > -- > Pedro Alves > > -- > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > Problem reports: http://cygwin.com/problems.html > Documentation: http://cygwin.com/docs.html > FAQ: http://cygwin.com/faq/ -- Pedro Alves [EMAIL PROTECTED] Cygwin Configuration Diagnostics Current System Time: Tue Aug 21 10:26:47 2007 Windows XP Professional Ver 5.1 Build 2600 Service Pack 2 Path: C:\cygwin\home\pedro\bin C:\cygwin\usr\local\bin C:\cygwin\usr\local\sbin C:\cygwin\opt\j2sdk1.4.1_01\bin\ C:\cygwin\usr\share\texmf\bin C:\cygwin\usr\X11\bin C:\cygwin\usr\sbin C:\cygwin\usr\mylocal\bin C:\cygwin\sbin C:\cygwin\home\pedro\bin C:\cygwin\usr\local\bin C:\cygwin\usr\local\sbin C:\cygwin\opt\j2sdk1.4.1_01\bin\ C:\cygwin\usr\share\texmf\bin C:\cygwin\usr\X11\bin C:\cygwin\usr\sbin C:\cygwin\usr\mylocal\bin C:\cygwin\sbin C:\cygwin\home\pedro\bin C:\cygwin\usr\local\bin C:\cygwin\usr\local\sbin C:\cygwin\opt\j2sdk1.4.1_01\bin\ C:\cygwin\usr\share\texmf\bin C:\cygwin\usr\X11\bin C:\cygwin\usr\sbin C:\cygwin\usr\mylocal\bin C:\cygwin\sbin C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin C:\cygwin\usr\X11R6\bin . C:\cygwin\bin C:\cygwin\usr\X11R6\bin c:\Programas\Java\jdk1.5.0_04\bin c:\oraclent\bin . c:\WINDOWS\system32 c:\WINDOWS c:\WINDOWS\System32\Wbem c:\Programas\apache-ant-1.6.5\bin c:\Programas\Ficheiros comuns\GTK\2.0\bin c:\Programas\OpenOffice.org 2.2\program c:\Documents and Settings\pedro_alves\bin c:\Programas\Microsoft Visual Studio .NET 2003\Common7\IDE c:\Programas\Microsoft SQL Server\80\Tools\BINN c:\PROGRA~1\GNU\WINCVS~1.3\CVSNT c:\mysql\bin c:\Programas\CVSNT\ c:\Programas\Nmapl c:\dev\pgsql\bin C:\cygwin\lib\lapack Output from C:\cygwin\bin\id.exe (nontsec) UID: 12139(pedro_alves) GID: 10545(mkgroup-l-d) 0(root) 544(Administradores)545(Utilizadores) 10545(mkgroup-l-d) Output from C:\cygwin\bin\id.exe (ntsec) UID: 12139(pedro_alves) GID: 10545(mkgroup-l-d) 0(root) 544(Administradores)545(Utilizadores) 10545(mkgroup-l-d) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS USER = 'pedro_alves' LD_LIBRARY_PATH = '/usr/local/lib' PWD = '/cygdrive/c/Documents and Settings/pedro_alves' HOME = '/cygdrive/c/Documents and Settings/pedro_alves' MAKE_MODE = 'unix' HOMEPATH = '\Documents and Settings\pedro_alves' MANPATH = '/usr/local/man:/usr/man/preformat:/usr/man:/usr/X11R6/man:/usr/openwin/m:/usr/share/texmf/man:/usr/local/man:/usr/man/preformat:/usr/man:/usr/X11R6/man:/usr/openwin/m:/usr/share/texmf/man:/usr/local/man:/usr/man/preformat:/usr/man:/usr/X11R6/man:/usr/openwin/m:/usr/share/texmf/man:/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man' APPDATA = 'C:\Documents and Settings\pedro_alves\Application Data' SSH_AGENT_PID = '1572' HOSTNAME = 'pt0105002' PILOTRATE = '115200' XKEYSYMDB = '/usr/X11R6/lib/X11/XKeysymDB' CI_HOLOS_CLI = 'C:\Programas\Seagate Software\Open Olap\' PROCESSOR_IDENTIFIER = 'x86 Family 6 Model 13 Stepping 6, GenuineIntel' SHELL = '/bin/sh' TERM = 'screen' WINDIR = 'C:\WINDOWS' VS80COMNTOOLS = 'C:\Programas\Microsoft Visual Studio 8\Common7\Tools\' PS1_COLOR = '[32m' TEXDOCVIEW_txt = 'cygstart %s' TEXDOCVIEW_dvi = 'cygstart %s' CVSROOT = ':pserver:[EMAIL PROTECTED]:/usr/local/cvsroot' WINDOWID = '2097166' USERDOMAIN = 'TEKEVER' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\Documents and Settings\All Users' LC_ALL = 'en_US' XAPPLRESDIR = '/usr/X11R6/lib/X11/app-defaults' XTERM_SHELL = '/usr/bin/bash' XCMSDB = '/usr/X11R6/lib/X11/Xcms.txt' !:: = '::\' TEMP = '/cygdrive/c/DOCUME~1/PED
Re: Latest mutt (1.4.2.2-1) does not work on (my) XP
On Mon, Aug 20, 2007 at 06:21:38PM -0400, Christopher Faylor wrote: > > What does "tried different temp dirs" mean? How did you try them? By > setting an environment variable. editing ~/.muttrc's tmpdir property > > Please provide a *specific* operation that does not work. The simplest one, pressing '?' for help. Also, pressing enter to see a message does not work, always returns the same error and a file with size 0 is created in the temp dir >gwin.com/faq/ -- Pedro Alves -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Latest mutt (1.4.2.2-1) does not work on (my) XP
Hello. I can't run latest mutt, version mutt-1.4.2.2-1 on my XP. For every operation I try to do I get an error like 'cannot create temporary file'. It's not a permission problem... files are created (even tried different temp dirs) with 0 size. Reverting to version 1.4.2.1i-1 everything works. I don't know what changed, but the main binary of 1.4.2.1i-1 has 539136 bytes and 1.4.2.2-1 has 1554944 bytes (3 times more). Tips appreciated. Thanks -- Pedro Alves -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: hacked package on server
Carlo Florendo wrote: The switch from: "do you want to format your drive?: +-+ +-+ + yes + + no + +-+ +-+ to: "do you want to format your drive?: ++ +-+ + format + + cancel + ++ +-+ ... Makes it much easier to understand what the software's up to. That's right. It's sad that I never thought of this before. With this suggestion of yours, all doubts will be erased about the true nature of Cygwin. Problems such as not knowing the answer to a clear question will eventually disapper from the mailing list and we will all be happier. It seems that there are people that like to bash everyone. I don't care a bit about this message box. I read my dialogs, thank you. Modern GUIs are changing to use verbs/actions in dialogs, instead of the simple yes/no, that forces the reader to do an indirection. Unfortunately, the Windows doesn't provide an easy facility (read 1 line of code) to do it, so most Windows apps don't. Take a look at kde, or gnome, and you'll see it everywhere. Heck, it's even in the some UIG. Shocking! http://developer.kde.org/documentation/design/ui/summary.html 'Dialogues that ask questions should not use Yes/No; this forces the user to tke an extra mental step such as "Am I saying Yes to deleting this file, or am I saying yes to keeping this file?"' Again, I don't care a bit about this use case. I've spent more time replying to this thread then I initially thought I would. So, ta da! Pedro Alves -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: hacked package on server
Erich Dollansky wrote: Carlo Florendo wrote: Brian Mathis wrote: The OP said: > "Do you want to skip the package?" and has a yes and no button. > I read it quickly and pressed no before thinking about it" ^^ So you see, it's a problem of thought. The UI message *is* very clear. One simply needs to think before acting. the message is clear. The user answers that he wants to install. As I understand this threat, the message is misleading in this case. I noticed this many times with the installer. A person who knows the installer, can give the proper answer. A normal user will answer the question as he understands it using plain English. Do you want to skip the package? No! Why did I start the installer in the first place? To install the package. Perhaps the screen should flash, and a loud beep should sound every time a MessageBox not related to "install to package" wants to show up. Then wait 3 seconds, show a "warning, going out of install mode" MessageBox, sleep a bit more, and only then show the skip message box. I mean, there has got to be a way to for the program to ask the user a non install related package, right? Seriously: Everyone's clicked on a wrong button before. I know I have - I just don't remember the last time. The switch from: "do you want to format your drive?: +-+ +-+ + yes + + no + +-+ +-+ to: "do you want to format your drive?: ++ +-+ + format + + cancel + ++ +-+ ... Makes it much easier to understand what the software's up to. And, paint the pushbuttons the same color you've done your bikeshed. Cheers, Pedro Alves -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: hacked package on server
Bengt-Arne Fjellner wrote: Well in my opinion It could even be better to have an unchecked checkbox like: Wrong MD5 sum detected. This package look broken. Try another mirror. ( ) Yes I Really want to install this even if it looks broken. OK Or something like that. Then its two clicks or several keystrokes before one can continue. yes, and having something like: are you sure (user clicks yes) are you really sure? (user clicks yes again) are you really, really sure? ... also makes it several clicks. The best solution, would be to replace the yes/no buttons with verbs/actions, like skip/'install anyway'/abort. I haven't looked at the code, but it is probably using MessageBox(Ex), which doesn't allow that. Coding an extended messagebox isn't *that* hard, but, it is still work that takes motivation to do. The second best, and quickest, would be for a patch to show up implementing Thorsten's suggestion that cfg pointed out. Until someone steps up to do the work, this discussion is just going to fade out and die. Cheers, Pedro Alves -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Installing Cron on Windows 2003 Server...
Eric Blake wrote: Pedro Alves portugalmail.pt> writes: Dave Korn wrote: Ctrl+D is a better way to close the file actually. If you mean EOF, why not *say* EOF? Unless you type it one time too much, and ... uupps, there goes the shell :) Which is why I have 'set -o ignoreeof' in my ~/.bashrc. Perfect! Thanks. Cheers, Pedro Alves Or you could set the IGNOREEOF environment variable. And you don't like ^D? Then stty can change EOF to some other sequence. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Installing Cron on Windows 2003 Server...
Dave Korn wrote: Ctrl+D is a better way to close the file actually. If you mean EOF, why not *say* EOF? :-) Unless you type it one time too much, and ... uupps, there goes the shell :) Cheers, Pedro Alves -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: GDB Ctrl-C Interrupt Fails WORKAROUND
Christopher Faylor wrote: ? Maybe we're not talking about the same thing but I don't see why it matters what the order of function calls is. If the inferior process has already responded to a CTRL-C you don't want it to get another interrupt. Yep, we were not talking about the same thing... I was under the impression that gdb always saw the CTRL_C event, and was then resending it to the inferior in win32_stop, and then it was the CTRL_C event sent with GenerateConsoleCtrlEvent that wasn't getting through. I was suggesting to use DebugBreakProcess in win32_stop, but that would solve a different problem. I spend a little time trying to get a workaround for the CYGWIN=tty case, and I had some success, but I don't think it is the right track. I can only get it to work when loading the test app through a gdb loaded in another gdb. Here what I think it is happening in the CYGWIN="" case: When using a console, and the user types ctrl-c, gdb first sees the CTRL_C event, and then, the inferior sees it, which generates a DBG_CONTROL_C exception that gdb translates into a SIGINT. If I set CYGWIN=tty in a cmd.exe based session, neither gdb nor the inferior see the CTRL_C event, but, the inferior gdb does see a SIGINT signal, which normally just quits (you see the "Quit" in gdb's console). When there is a console, the signal is *not* seen by gdb, only the CTRL_C event. So, I've copied the SIGINT handler and the terminal_ours/terminal_inferior logic found gdb/remote.c into win32-nat.c, and when the user types ctrl-c, I have a the inferior gdb send a send CTRL_C event to the inferior test app using GenerateConsoleCtrlEvent. The same gdb sees a DBG_CONTROL_C exception, as if there was a console to begin with - the test app is stopped. Now, if I try doing the same, but with only one gdb process involved, the SIGINT handler that is called is always the one from the inferior process. I guess something makes the first debuggee be the one that catches signals. To be clear, in either: - gdb (1) -> gdb (2) -> testapp (3) or - gdb (1) -> testapp (2) It is (2) that gets the signal. Anyway, it is not really my itch, so I'll leave it as that. If someone wants the patch, just let me know. Probably, having cygwin signals catchable in gdb would be time better spent, although that wouldn't solve the MinGW/'gcc -mno-cygwin' side of the problem. I wonder why it never went into cygwin1.dll. Chris, was it lack of time, or is there any major stumbling block? Cheers, Pedro Alves -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: missing definition of __STRING macro in standard cygwin headers
Brian Dessent wrote: Pedro Alves wrote: It wouldn't work. #define __STRING #x != #define __STRING(x) #x I am just quoting what the OP said, which was: What the web link basically says that cygwin doesn't have #define __STRING #x defined in any of the standard header files which means some source code I have no idea what this code actually does with the define, having never looked at it. Ah, sorry. I had seen it in the link the OP posted, and didn't realize he had posted it wrong. Cheers, Pedro Alves -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: missing definition of __STRING macro in standard cygwin headers
Brian Dessent wrote:
Eric Blake wrote:
Not to mention the fact that it's incredibly silly to rely on libc
headers to define something as trivial as the stringify operator which
is a standard part of the C language. Does it also require
__COMMENTBEGIN to be defined as /*? __BRACEBEGIN as {? Why not just
use #x in the code in the first place?
Because the stringify operator only works inside a #define?
By the way, I don't see why you can't just build this package like:
./configure CPPFLAGS="-D__STRING=#x" ..rest of configure options..
It wouldn't work.
#define __STRING #x != #define __STRING(x) #x
But I do agree with Eric.
Anyway, if chosen to change the FAAC side of the fence, instead of:
#ifdef __CYGWIN__
#define __STRING ...
#endif
It would be perhaps better to:
#ifndef __STRING
#define __STRING ...
#endif
Cheers,
Pedro Alves
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: GDB Ctrl-C Interrupt Fails WORKAROUND
Christopher Faylor escreveu: On Thu, Mar 01, 2007 at 12:15:12AM +, Pedro Alves wrote: Is there a reason DebugBreakProcess can't be used from inside gdb if sending a ctrl-c with GenerateConsoleCtrlEvent (CTRL_C_EVENT, pid) doesn't work? I suppose that it could be used for that but it might be tricky figuring out when it was required and when it wasn't. You wouldn't want to interrupt the process twice if it already saw the CTRL-C. Although, maybe if you used this you could tell the inferior process not to process CTRL-C at all via some CreateProcess setting. What about doing it the other way around? Use DebugBreakProcess if available, and fallback to GenerateConsoleCtrlEvent? Is there anything internal to Cygwin that uses it? We could teach gdb that the next BreakPoint inside kernel32 (, or whatever dll DebugBreakProcess breaks in,) is mapped to SIGINT, remap the event, and switch to the main thread, so the user doesn't see we stopped inside kernel32. Cheers, Pedro Alves -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: GDB Ctrl-C Interrupt Fails WORKAROUND
Christopher Layne escreveu: On Thu, Jun 15, 2006 at 11:04:56AM -0400, Christopher Faylor wrote: I'm happy for you that CTRL-C works for you. It does not work for me. I'm almost never running gdb from a genuine DOS command prompt. Sometimes via ssh, sometimes via a terminal emulator. CTRL-C doesn't work in those. Also, if you have "tty" in your CYGWIN variable it doesn't work even >from a DOS command prompt. Which is exactly what I theorized above. So, characterizing CTRL-C as not working in gdb is rather an overstatement without more details. Now you know that you can use a standard console window for debugging and all will be well. Lacking the ability to interrupt a running program severely limits gdb's usefulness. Fortunately there's a workaround available. Yep. Use a console window. Is there a reason DebugBreakProcess can't be used from inside gdb if sending a ctrl-c with GenerateConsoleCtrlEvent (CTRL_C_EVENT, pid) doesn't work? Where in the cygwin source tree would the best place be to look for where SIGINT handling is being done at the tty/pty level so that I can remove this pointless limitation from my builds? See gdb/win32-nat.c:win32_stop and also: http://sourceware.org/ml/gdb-patches/2007-02/msg00294.html Look for win32_send_signal in the patch. Note that DebugBreakProcess only exists on XP or Windows 2003 server onwards. For WinNT < XP, it should be possible to simulate it with CreateRemoteThread with entry point set to DebugBreak or something similar. The worst case would be that a dll would have to be injected to load a function that does the DebugBreak in the debuggee's address space. Cheers, Pedro Alves -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: /dev/null timing and clock skew problems
Tim Prince escreveu: [EMAIL PROTECTED] wrote: I see this a lot on regular files. I just got this: make: Warning: File `Makefile' has modification time 0.42 s in the future If you are accessing files on another machine, and you aren't using any means for keeping the date clocks synchronized, this is to be expected. No, but I'm on FAT32 on this machine. Problem is described here: http://www.delorie.com/djgpp/v2faq/faq22_18.html According to that same page, DJGPP has a local hack^Wpatch to suppress that warning: "DJGPP ports of GNU Make v3.77 and later allow for up to 3 seconds of positive difference between the file timestamp and the system clock (that is, the file is allowed to be up to 3 seconds into the future), before the above warning is printed. So upgrading to the latest version of Make should eliminate such bogus warnings and leave you only with messages due to real clock skews." Cheers, Pedro Alves -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: /dev/null timing and clock skew problems
Corinna Vinschen escreveu: On Feb 25 23:04, Aaron Gray wrote: I am doing make based builds on Cygwin and am getting following warning messages multiple times in stdout :- make[2]: Warning: File `/dev/null' has modification time 0.0096 s in the future make[2]: warning: Clock skew detected. Your build may be incomplete. I am using Windows XP. Anyone know what is going on and how to correct it ? /dev/null's timestamps are faked since /dev/null is just another name for the Windows NUL device (or rather, NT's \Device\Null device). The timestamps you get from stat() are just the current system time, converted into a file time. This can result in conversion inaccuracy, apparently. Nothing we can do against for the current release. Remove the check against /dev/null or convert it to a check against some other random file. I'm wondering what this is supposed to do anyway. In the long run, maybe it would be better in Cygwin to set the timestamp for devices to epoch. You are saying this should only happen on devices? I see this a lot on regular files. I just got this: make: Warning: File `Makefile' has modification time 0.42 s in the future Cheers, Pedro Alves -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: patch -e from stdin broken?
Hi Igor, Igor Peshansky wrote: On Wed, 21 Feb 2007, Pedro Alves wrote: (Here is the original message I tried to send earlier, sorry for the mess.) Hi guys, While looking at why 'quilt annotate' is broken in Cygwin, I found something fishy on 'patch' in ed mode. Looks like reading the patch from stdin is broken. Reading the patch from a file with -i works ok. Here is how to reproduce: $ touch a.txt $ cat << EOF > b.txt a new line EOF $ diff -e a.txt b.txt > ab.diff $ cat ab.diff 0a a new line . $ patch -e a.txt < ab.diff $ /cygdrive/c/DOCUME~1/pt104167/LOCALS~1/Temp/poL0ERTu: No such file or directory Looks like your $TMP is set to something Cygwin doesn't like... Try setting it to, say, /tmp, and see if that makes patch -e happier... Thanks for the hints. Sorry I didn't say earlier, but I had already tried that. Cygwin does understand that path, just checked (notice the /cygdrive/c/ prefix). Actually patch honors $TMPDIR first, so I had tried setting it to /tmp, and the same thing happens: export TMPDIR=/tmp patch -e a.txt < ab.diff /tmp/posrjz1q: No such file or directory (yes, /tmp does exist) ( Just found out another thing: export TMPDIR=/ patch -e a.txt < ab.diff #looks like it is hanging, but about 20 seconds later: patch: Can't create file //ppMxHRaO : No such host or network path The double slash should have been filtered before trying to open the file. Humm, easy to solve on patch side, but setting TMPDIR=/ breaks a lot of stuff, even gcc and make, so I guess it is one of those "don't do it" - FAQ thingies, that I missed somewhere. ) [snip] That 'No such file' error message comes from ed, or so it seems. It looks like something is going wrong with the pipe to ed (patch/pch.c:do_ed_script), but I can't see what. The filename passed to it is correct, but somehow, when the pipe is fflushed ed barks. If I put a _cexit before the pipe is flushed, ed doesn't complain. I also tested it on kubuntu 6.06, and on Solaris 10 with gnu patch, gnu diff and Sun ed, and it worked correctly, so it does look like a Cygwin specific problem. You could also try playing with the "binmode" setting in the Cygwin environment variable, which controls line endings in pipes. I don't have any textmode mounts. (end original message) As Corinna found out, not specifying the file to patch, but doing it interactively works ok. That should make it easier to debug. $ patch -e < ab.diff can't find file to patch at input line 1 Perhaps you used the wrong -p or --strip option? File to patch: a.txt $ cat a.txt a new line $ $ patch -e a.txt < ab.diff /cygdrive/c/DOCUME~1/ADMINI~1/DEFINI~1/Temp/poh0o0Rq: No such file or directory Hmm, you also forgot to mention the directory where a.txt resides... Try first doing this on a binary mount in some directory under Cygwin root (e.g., /tmp). If that works, look into directories and environment variable settings. Doesn't work anywhere: ~, /tmp, /cygdrive/d, etc. Did it work for you, when you followed the recipe I sent? If you didn't try, could you, please? >mount d:\cygwin\bin on /usr/bin type system (binmode) d:\cygwin\lib on /usr/lib type system (binmode) d:\cygwin on / type system (binmode) d:\MinGW on /mingw type system (binmode) c: on /cygdrive/c type system (binmode,noumount) d: on /cygdrive/d type system (binmode,noumount) e: on /cygdrive/e type system (binmode,noumount) f: on /cygdrive/f type system (binmode,noumount) l: on /cygdrive/l type system (binmode,noumount) m: on /cygdrive/m type system (binmode,noumount) x: on /cygdrive/x type system (binmode,noumount) >set | grep CYG CYGWIN=ntsec CYGWIN_ROOT='\cygwin' Cheers, Pedro Alves -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: patch -e from stdin broken?
Corinna Vinschen wrote: On Feb 21 15:35, [EMAIL PROTECTED] wrote: Hi guys, While looking at why 'quilt annotate' is broken in Cygwin, I found something fishy on 'patch' in ed mode. Looks like reading the patch from stdin is broken. Reading the patch from a file with -i works ok. Here is how to reproduce: $ touch a.txt $ cat << EOF > b.txt a new line EOF $ diff -e a.txt b.txt > ab.diff $ cat ab.diff 0a a new line The diff file also contains a third line with just a single dot. If I feed this to patch from stdin, everything's fine: $ patch < ab.diff can't find file to patch at input line 1 Perhaps you used the wrong -p or --strip option? File to patch: a.txt $ cat a.txt a new line $ Where's the problem exactly? (Here is the original message I tried to send earlier, sorry for the mess.) Hi guys, While looking at why 'quilt annotate' is broken in Cygwin, I found something fishy on 'patch' in ed mode. Looks like reading the patch from stdin is broken. Reading the patch from a file with -i works ok. Here is how to reproduce: $ touch a.txt $ cat << EOF > b.txt > a new line > EOF $ diff -e a.txt b.txt > ab.diff $ cat ab.diff 0a a new line . $ patch -e a.txt < ab.diff $ /cygdrive/c/DOCUME~1/pt104167/LOCALS~1/Temp/poL0ERTu: No such file or directory #(a.txt should have the same contents as b.txt at this point) $ cat a.txt $ cat ab.diff | patch -e a.txt $ /cygdrive/c/DOCUME~1/pt104167/LOCALS~1/Temp/po5so3lD: No such file or directory #(still wrong contents) $ cat a.txt $ patch -e a.txt -i ab.diff #(ok now.) $ cat a.txt a new line That 'No such file' error message comes from ed, or so it seems. It looks like something is going wrong with the pipe to ed (patch/pch.c:do_ed_script), but I can't see what. The filename passed to it is correct, but somehow, when the pipe is fflushed ed barks. If I put a _cexit before the pipe is flushed, ed doesn't complain. I also tested it on kubuntu 6.06, and on Solaris 10 with gnu patch, gnu diff and Sun ed, and it worked correctly, so it does look like a Cygwin specific problem. Cygwin Package Information Package VersionStatus cygwin 1.5.24-2 OK patch2.5.8-9OK diffutils2.8.7-1OK ed 0.2-1 OK (end original message) As Corinna found out, not specifying the file to patch, but doing it interactively works ok. That should make it easier to debug. $ patch -e < ab.diff can't find file to patch at input line 1 Perhaps you used the wrong -p or --strip option? File to patch: a.txt $ cat a.txt a new line $ $ patch -e a.txt < ab.diff /cygdrive/c/DOCUME~1/ADMINI~1/DEFINI~1/Temp/poh0o0Rq: No such file or directory Cheers, Pedro Alves -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
