wstring support in GCC 4.1.2 in Cygwin 1.5.25-11

View: New views
20 Messages — Rating Filter:   Alert me  
< Prev | 1 - 2 - 3 | Next >

Re: wstring support in GCC 4.1.2 (OS independent)

by Brian Dessent :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Linda Walsh wrote:

> So maybe the problem is
> not that cygwin doesn't support unicode, but that the gcc
> libs & compile utils don't support the standard linux
> equivalents?

I can't parse this.

>         Whether or not cygwin (or the linux kernel) supports
> "wchar" is not entirely relevant to what the application libraries
> on top of the kernel support -- at least going by the example
> on an x86_64 linux.  It's still the case that the 64-bit
> linux kernel doesn't support wchars any more than cygwin, yet
> the compiler suite does.

Comparing Cygwin to the linux kernel is nonsense.  They serve totally
different purposes -- Cygwin is a user-mode library.  If you want to
make a comparison, compare Cygwin to glibc as they are both libcs.

And again, the compiler suite cannot implement wstring without
underlying libc wide character IO support which does not exist in newlib
and therefore does not exist in Cygwin.  Remember that gcc is divorced
from the target libc because a libc is way too OS-dependent.  gcc relies
on the platform to implement its own libc, and everything gcc implements
builds on top of an existing libc.  If the libc doesn't have the
necessary support there's nothing that libstdc++ can do about it but
disable wstring.

Brian

--
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: wstring support in GCC 4.1.2 in Cygwin 1.5.25-11

by Linda Walsh :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Eric Blake wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> According to Linda Walsh on 5/22/2008 1:14 PM:
> |     Linux doesn't support double-wide characters in its
> | system calls -- it's all in 'glibc'.
> |
> |     Cygwin doesn't need to support unicode anymore than
> | the linux kernel does.  It's whoever built the gcc/glib
> | packages that needs to supply that application-level (not
> | system-level) datatype.
>
> Please get your terms straight.  glib is something MUCH different than
> glibc.  glib is ported to cygwin, glibc is not.  glib is a graphics
> library, glibc is an implementation of libc.  Cygwin uses newlib as its
> implementation of libc.  And that's why cygwin doesn't support wstring -
> because newlib does not have very complete wide character support.
---
        Where did 'newlib' come from?  I "thought", that newlib had
originally been designed as a 'bootstrapping' library in order to get
some minimal and widely used set of gnu-library functions up and running
so other gnu utils could also get "up & running".

        Wasn't it planned to bring in the full glibc at one point? --
and sorry for my terminology -- I'm often a lazy typist -- my typing
isn't what it used to be -- due to nerve impingements...I usually do
ok, but it depends on how much I've pushed, how tired or taxed I am...
I knew the correct name of glibc -- as put in quotes in the first
sentence...was latter on in 'backrefs', I got more lazy...sigh
l



--
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: wstring support in GCC 4.1.2 in Cygwin 1.5.25-11

by Christopher Faylor-8 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Fri, May 23, 2008 at 11:40:35AM -0700, Linda Walsh wrote:

> Eric Blake wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> According to Linda Walsh on 5/22/2008 1:14 PM:
>> |     Linux doesn't support double-wide characters in its
>> | system calls -- it's all in 'glibc'.
>> |
>> |     Cygwin doesn't need to support unicode anymore than
>> | the linux kernel does.  It's whoever built the gcc/glib
>> | packages that needs to supply that application-level (not
>> | system-level) datatype.
>> Please get your terms straight.  glib is something MUCH different than
>> glibc.  glib is ported to cygwin, glibc is not.  glib is a graphics
>> library, glibc is an implementation of libc.  Cygwin uses newlib as its
>> implementation of libc.  And that's why cygwin doesn't support wstring -
>> because newlib does not have very complete wide character support.
>
>Where did 'newlib' come from?  I "thought", that newlib had originally
>been designed as a 'bootstrapping' library in order to get some minimal
>and widely used set of gnu-library functions up and running so other
>gnu utils could also get "up & running".

Either check out the newlib web site at http://sourceware.org/newlib or
ask about newlib in the newlib mailing list.

cgf

--
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: fate/resolution/location of things like "sys/sockio.h"

by Mike Marchywka-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message




Thanks but now another issue. To review, I'm trying to build nmap and had some problems with
the generated configuration. I decided to compile everything as cygwin c++ and remove the fancy
linking( "ar cru" all the .o files into "junkbin.a" , fixing extern C, no "no-cygwin",  and related problems etc).
I ended up with a link command and cygcheck as shown below but I'm more
interested in getting a tool to diagnose the problem. Windoze would give some info
if you click on it but now just says it didn't initialize, since it doesn't get to "main" gdb just
gives up. Thanks.



$ g++  nmapjunk.a libdnet-stripped/src/junkbin.a liblua/junkbin.a  -Lnbase -lnbase -Lnsock/src -lnsock -Llibpcap -lpcap  -liphlpapi -lws2_32 -lpcre -L. -lPacket

Info: resolving _optind by linking to __imp__optind (auto-import)
Info: resolving _optarg by linking to __imp__optarg (auto-import)
Info: resolving _pcre_free by linking to __imp__pcre_free (auto-import)


$ cygcheck -v ./a.exe |  grep -v "already done" | uniq | unix2dos>



Warning: .\a.exe hides e:\new\temp\nmap\src3\nmap-4.62\a.exe
.\a.exe - os=4.0 img=1.0 sys=4.0
  C:\WINNT\cygwin1.dll - os=4.0 img=1.0 sys=4.0
    "cygwin1.dll" v0.0 ts=2007/1/31 4:58
    C:\WINNT\system32\ADVAPI32.DLL - os=5.0 img=5.0 sys=4.0
      "ADVAPI32.dll" v0.0 ts=2005/4/11 17:31
      C:\WINNT\system32\KERNEL32.dll - os=5.0 img=5.0 sys=4.0
        "KERNEL32.dll" v0.0 ts=2006/6/21 1:26
        C:\WINNT\system32\ntdll.dll - os=5.0 img=5.0 sys=4.0
          "ntdll.dll" v0.0 ts=2004/12/2 21:40
      C:\WINNT\system32\RPCRT4.dll - os=5.0 img=5.0 sys=4.10
        "RPCRT4.dll" v0.0 ts=2006/4/13 0:31
        C:\WINNT\system32\ADVAPI32.dll (recursive)
Warning: .\cygpcre-0.dll hides e:\new\temp\nmap\src3\nmap-4.62\cygpcre-0.dll
Warning: .\cygpcre-0.dll hides C:\MiscPrograms\cygwin\cyg\bin\cygpcre-0.dll
  .\cygpcre-0.dll - os=4.0 img=1.0 sys=4.0
    "cygpcre-0.dll" v0.0 ts=2007/6/26 23:49
  C:\WINNT\system32\IPHLPAPI.DLL - os=5.0 img=5.0 sys=4.10
    "iphlpapi.dll" v0.0 ts=2006/5/19 3:59
    C:\WINNT\system32\MSVCRT.dll - os=4.0 img=0.0 sys=4.0
      "MSVCRT.dll" v0.0 ts=2003/3/11 4:10
    C:\WINNT\system32\USER32.dll - os=5.0 img=5.0 sys=4.0
      "USER32.dll" v0.0 ts=2005/4/11 17:31
      C:\WINNT\system32\GDI32.dll - os=5.0 img=5.0 sys=4.10
        "GDI32.dll" v0.0 ts=2005/12/29 7:28
        C:\WINNT\system32\USER32.dll (recursive)
    C:\WINNT\system32\WS2_32.dll - os=5.0 img=5.0 sys=4.10
      "WS2_32.dll" v0.0 ts=2002/8/16 4:58
      C:\WINNT\system32\WS2HELP.DLL - os=5.0 img=5.0 sys=4.0
        "WS2HELP.dll" v0.0 ts=1999/9/25 1:17
    C:\WINNT\system32\ICMP.dll - os=5.0 img=5.0 sys=4.0
      "ICMP.dll" v0.0 ts=1999/9/25 1:19
    C:\WINNT\system32\MPRAPI.dll - os=5.0 img=5.0 sys=4.10
      "MPRAPI.dll" v0.0 ts=1999/11/12 18:24
      C:\WINNT\system32\SAMLIB.DLL - os=5.0 img=5.0 sys=4.0
        "SAMLIB.dll" v0.0 ts=2005/4/1 20:23
      C:\WINNT\system32\NETAPI32.DLL - os=5.0 img=5.0 sys=4.0
        "NETAPI32.dll" v0.0 ts=2006/8/17 7:46
        C:\WINNT\system32\Secur32.dll - os=5.0 img=5.0 sys=4.0
          "Secur32.dll" v0.0 ts=2003/3/26 16:37
        C:\WINNT\system32\NTDSAPI.dll - os=5.0 img=5.0 sys=4.10
          "NTDSAPI.dll" v0.0 ts=2003/2/18 11:59
          C:\WINNT\system32\DNSAPI.DLL - os=5.0 img=5.0 sys=4.0
            "DNSAPI.dll" v0.0 ts=2006/6/27 3:30
            C:\WINNT\system32\WSOCK32.dll - os=5.0 img=5.0 sys=4.10
              "WSOCK32.dll" v0.0 ts=2002/9/5 16:55
          C:\WINNT\system32\WLDAP32.DLL - os=5.0 img=5.0 sys=4.0
            "WLDAP32.dll" v0.0 ts=2005/4/1 20:23
          C:\WINNT\system32\NETAPI32.DLL (recursive)
        C:\WINNT\system32\NETRAP.dll - os=5.0 img=5.0 sys=4.10
          "NETRAP.dll" v0.0 ts=1999/9/25 1:03
      C:\WINNT\system32\OLE32.DLL - os=5.0 img=5.0 sys=4.0
        "ole32.dll" v0.0 ts=2005/7/5 13:08
      C:\WINNT\system32\OLEAUT32.DLL - os=4.0 img=0.0 sys=4.0
        "OLEAUT32.dll" v0.0 ts=2002/12/12 16:28
      C:\WINNT\system32\ACTIVEDS.DLL - os=5.0 img=5.0 sys=4.0
        "ACTIVEDS.dll" v0.0 ts=2002/8/16 6:26
        C:\WINNT\system32\ADSLDPC.DLL - os=5.0 img=5.0 sys=4.0
          "adsldpc.dll" v0.0 ts=2005/4/1 20:23
      C:\WINNT\system32\RTUTILS.DLL - os=5.0 img=5.0 sys=4.10
        "rtutils.dll" v0.0 ts=1999/10/30 18:31
      C:\WINNT\system32\SETUPAPI.DLL - os=5.0 img=5.0 sys=4.0
        "SETUPAPI.dll" v0.0 ts=2002/12/5 17:13
        C:\WINNT\system32\USERENV.DLL - os=5.0 img=5.0 sys=4.0
          "USERENV.dll" v0.0 ts=2005/4/1 20:23
    C:\WINNT\system32\RASAPI32.dll - os=5.0 img=5.0 sys=4.0
      "RASAPI32.dll" v0.0 ts=2005/4/1 20:23
      C:\WINNT\system32\rasman.dll - os=5.0 img=5.0 sys=4.0
        "rasman.dll" v0.0 ts=2005/4/1 20:23
      C:\WINNT\system32\TAPI32.dll - os=5.0 img=5.0 sys=4.0
        "TAPI32.dll" v0.0 ts=2003/2/14 18:16
        C:\WINNT\system32\COMCTL32.DLL - os=5.0 img=5.0 sys=4.0
          "COMCTL32.dll" v0.0 ts=2006/8/25 11:12
        C:\WINNT\system32\SHLWAPI.DLL - os=5.1 img=5.1 sys=4.0
          "SHLWAPI.dll" v0.0 ts=2006/10/23 12:53
    C:\WINNT\system32\DHCPCSVC.DLL - os=5.0 img=5.0 sys=4.0
      "DHCPCSVC.DLL" v0.0 ts=2006/4/13 6:07
      C:\WINNT\system32\iphlpapi.dll (recursive)
Warning: .\packet.dll hides e:\new\temp\nmap\src3\nmap-4.62\packet.dll
Warning: .\packet.dll hides C:\WINNT\system32\packet.dll
  .\packet.dll - os=4.0 img=0.0 sys=4.0
    "packet.dll" v0.0 ts=2005/8/2 17:08
    C:\WINNT\system32\WanPacket.dll - os=4.0 img=0.0 sys=4.0
      "WanPacket.dll" v0.0 ts=2005/8/2 17:08
      C:\WINNT\system32\NPPTools.dll - os=5.0 img=1.0 sys=4.0
        "NPPTools.dll" v0.0 ts=1999/9/25 1:28
        C:\WINNT\system32\MFC42u.DLL - os=4.0 img=6.0 sys=4.0
          "MFC42u.DLL" v0.0 ts=2002/10/29 16:36
    C:\WINNT\system32\VERSION.dll - os=5.0 img=5.0 sys=4.0
      "VERSION.dll" v0.0 ts=2002/12/10 14:41
      C:\WINNT\system32\LZ32.DLL - os=5.0 img=5.0 sys=4.10
        "LZ32.dll" v0.0 ts=2002/10/14 19:27
Warning: .\cygpcre-0.dll hides e:\new\temp\nmap\src3\nmap-4.62\cygpcre-0.dll
Warning: .\cygpcre-0.dll hides C:\MiscPrograms\cygwin\cyg\bin\cygpcre-0.dll
Warning: .\cygpcre-0.dll hides e:\new\temp\nmap\src3\nmap-4.62\cygpcre-0.dll
Warning: .\cygpcre-0.dll hides C:\MiscPrograms\cygwin\cyg\bin\cygpcre-0.dll
Warning: .\cygpcre-0.dll hides e:\new\temp\nmap\src3\nmap-4.62\cygpcre-0.dll
Warning: .\cygpcre-0.dll hides C:\MiscPrograms\cygwin\cyg\bin\cygpcre-0.dll
Warning: .\cygpcre-0.dll hides e:\new\temp\nmap\src3\nmap-4.62\cygpcre-0.dll
Warning: .\cygpcre-0.dll hides C:\MiscPrograms\cygwin\cyg\bin\cygpcre-0.dll
Warning: .\cygpcre-0.dll hides e:\new\temp\nmap\src3\nmap-4.62\cygpcre-0.dll
Warning: .\cygpcre-0.dll hides C:\MiscPrograms\cygwin\cyg\bin\cygpcre-0.dll
Warning: .\cygpcre-0.dll hides e:\new\temp\nmap\src3\nmap-4.62\cygpcre-0.dll
Warning: .\cygpcre-0.dll hides C:\MiscPrograms\cygwin\cyg\bin\cygpcre-0.dll
Warning: .\cygpcre-0.dll hides e:\new\temp\nmap\src3\nmap-4.62\cygpcre-0.dll
Warning: .\cygpcre-0.dll hides C:\MiscPrograms\cygwin\cyg\bin\cygpcre-0.dll


If it helps any, this program works just fine ( although it doesn't always seem to run the first try
after a reboot?).

$ cygcheck -v ./main.exe | grep -v "already done"
Warning: .\main.exe hides e:\new\glutp\glutp\glutp\main.exe
.\main.exe - os=4.0 img=1.0 sys=4.0
  C:\WINNT\cygwin1.dll - os=4.0 img=1.0 sys=4.0
    "cygwin1.dll" v0.0 ts=2007/1/31 4:58
    C:\WINNT\system32\ADVAPI32.DLL - os=5.0 img=5.0 sys=4.0
      "ADVAPI32.dll" v0.0 ts=2005/4/11 17:31
      C:\WINNT\system32\KERNEL32.dll - os=5.0 img=5.0 sys=4.0
        "KERNEL32.dll" v0.0 ts=2006/6/21 1:26
        C:\WINNT\system32\ntdll.dll - os=5.0 img=5.0 sys=4.0
          "ntdll.dll" v0.0 ts=2004/12/2 21:40
      C:\WINNT\system32\RPCRT4.dll - os=5.0 img=5.0 sys=4.10
        "RPCRT4.dll" v0.0 ts=2006/4/13 0:31
        C:\WINNT\system32\ADVAPI32.dll (recursive)
  C:\MiscPrograms\cygwin\cyg\bin\cygjpeg-62.dll - os=4.0 img=1.0 sys=4.0
    "cygjpeg-62.dll" v0.0 ts=2006/11/9 4:02
  C:\WINNT\system32\GLU32.DLL - os=5.0 img=5.0 sys=4.10
    "GLU32.dll" v0.0 ts=1999/9/25 0:21
    C:\WINNT\system32\MSVCRT.dll - os=4.0 img=0.0 sys=4.0
      "MSVCRT.dll" v0.0 ts=2003/3/11 4:10
    C:\WINNT\system32\OPENGL32.dll - os=5.0 img=5.0 sys=4.10
      "OPENGL32.dll" v0.0 ts=2002/10/17 16:35
      C:\WINNT\system32\GDI32.dll - os=5.0 img=5.0 sys=4.10
        "GDI32.dll" v0.0 ts=2005/12/29 7:28
        C:\WINNT\system32\USER32.dll - os=5.0 img=5.0 sys=4.0
          "USER32.dll" v0.0 ts=2005/4/11 17:31
          C:\WINNT\system32\GDI32.dll (recursive)
      C:\WINNT\system32\GLU32.dll (recursive)
      C:\WINNT\system32\DDRAW.dll - os=5.1 img=5.1 sys=4.0
        "DDRAW.dll" v0.0 ts=2004/7/9 3:32
        C:\WINNT\system32\DCIMAN32.dll - os=5.0 img=5.0 sys=4.10
          "DCIMAN32.dll" v0.0 ts=1999/11/11 21:48
Warning: C:\MiscPrograms\cygwin\cyg\bin\glut32.dll hides c:\MyDocs\scripts\glut3
2.dll
  C:\MiscPrograms\cygwin\cyg\bin\glut32.dll - os=4.0 img=3.7 sys=4.0
    "glut32.dll" v0.0 ts=2003/11/10 17:24
    C:\WINNT\system32\WINMM.dll - os=5.0 img=5.0 sys=4.0
      "WINMM.dll" v0.0 ts=1999/10/23 17:20




Mike Marchywka
586 Saint James Walk
Marietta GA 30067-7165
404-788-1216 (C)<- leave message
989-348-4796 (P)<- emergency only
marchywka@...
Note: If I am asking for free stuff, I normally use for hobby/non-profit
information but may use in investment forums, public and private.
Please indicate any concerns if applicable.
Note: Hotmail is possibly blocking my mom's entire
ISP - try  me on marchywka@... if no reply
here. Thanks.


_________________________________________________________________
Give to a good cause with every e-mail. Join the i’m Initiative from Microsoft.
http://im.live.com/Messenger/IM/Join/Default.aspx?souce=EML_WL_ GoodCause

--
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: fate/resolution/location of things like "sys/sockio.h"

by Brian Dessent :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Mike Marchywka wrote:

> $ g++  nmapjunk.a libdnet-stripped/src/junkbin.a liblua/junkbin.a  -Lnbase -lnbase -Lnsock/src -lnsock -Llibpcap -lpcap  -liphlpapi -lws2_32 -lpcre -L. -lPacket

I would not expect this to work in any case.  Cygwin has no libpcap, so
you must be using the native windows winpcap, which is not a Cygwin
library (it's linked with MSVCRT.)

Brian

--
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: fate/resolution/location of things like "sys/sockio.h"

by Mike Marchywka-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


> Date: Tue, 27 May 2008 00:54:37 -0700
> From: brian@...
> Mike Marchywka wrote:
>
>> $ g++ nmapjunk.a libdnet-stripped/src/junkbin.a liblua/junkbin.a -Lnbase -lnbase -Lnsock/src -lnsock -Llibpcap -lpcap -liphlpapi -lws2_32 -lpcre -L. -lPacket
>
> I would not expect this to work in any case. Cygwin has no libpcap, so
> you must be using the native windows winpcap, which is not a Cygwin
> library (it's linked with MSVCRT.)
>

I have winpcap for an earlier install of ShowTraffic which runs fine. The nmap download
comes with its own and getting everything consistent may be a problem but I can't
come up with a diagnostic that confirms death during packet.dll load. I guess that is
why I am more interested in diagnostic tools rather than expecting to find someone who
knows offhand how to link my c++ version of nmap :)

Is there some simple way to get gdb to tell you what it was trying to do if it dies before getting
to main()? From what I could tell, you couldn't set a break point etc to diagnose the
CRT initialization stuff. As far as that goes, what tools are there for dumping object or "a" files?


Thanks.




Mike Marchywka
586 Saint James Walk
Marietta GA 30067-7165
404-788-1216 (C)<- leave message
989-348-4796 (P)<- emergency only
marchywka@...
Note: If I am asking for free stuff, I normally use for hobby/non-profit
information but may use in investment forums, public and private.
Please indicate any concerns if applicable.
Note: Hotmail is possibly blocking my mom's entire
ISP - try  me on marchywka@... if no reply
here. Thanks.


> Date: Tue, 27 May 2008 00:54:37 -0700
> From: brian@...
> To: marchywka@...
> CC: cygwin@...
> Subject: Re: fate/resolution/location of things like "sys/sockio.h"
>
> Mike Marchywka wrote:
>
>> $ g++ nmapjunk.a libdnet-stripped/src/junkbin.a liblua/junkbin.a -Lnbase -lnbase -Lnsock/src -lnsock -Llibpcap -lpcap -liphlpapi -lws2_32 -lpcre -L. -lPacket
>
> I would not expect this to work in any case. Cygwin has no libpcap, so
> you must be using the native windows winpcap, which is not a Cygwin
> library (it's linked with MSVCRT.)
>
> Brian
>
> --
> 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/
>

_________________________________________________________________
Make every e-mail and IM count. Join the i’m Initiative from Microsoft.
http://im.live.com/Messenger/IM/Join/Default.aspx?source=EML_WL_ MakeCount

--
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: fate/resolution/location of things like "sys/sockio.h"

by Mike Marchywka-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message



Also, FWIW, I took a sample program in wpdpack and compiled it WITH cygwin
( all the makefiles that came with the download did use -mno-cygwin )
and it at least loaded ( it may function properly  but I haven't checked),

$ cygcheck ./pktdump_ex.exe | sed -e 's/ /./g'
.\pktdump_ex.exe
..C:\WINNT\system32\wpcap.dll
....C:\WINNT\system32\KERNEL32.dll
......C:\WINNT\system32\ntdll.dll
....C:\WINNT\system32\WS2_32.dll
......C:\WINNT\system32\MSVCRT.DLL
......C:\WINNT\system32\ADVAPI32.DLL
........C:\WINNT\system32\RPCRT4.dll
......C:\WINNT\system32\WS2HELP.DLL
....C:\WINNT\system32\packet.dll
......C:\WINNT\system32\WanPacket.dll
........C:\WINNT\system32\NPPTools.dll
..........C:\WINNT\system32\MFC42u.DLL
............C:\WINNT\system32\GDI32.dll
..............C:\WINNT\system32\USER32.dll
..........C:\WINNT\system32\OLEAUT32.dll
............C:\WINNT\system32\ole32.dll
......C:\WINNT\system32\iphlpapi.dll
........C:\WINNT\system32\ICMP.dll
........C:\WINNT\system32\MPRAPI.dll
..........C:\WINNT\system32\SAMLIB.DLL
..........C:\WINNT\system32\NETAPI32.DLL
............C:\WINNT\system32\Secur32.dll
............C:\WINNT\system32\NTDSAPI.dll
..............C:\WINNT\system32\DNSAPI.DLL
................C:\WINNT\system32\WSOCK32.dll
..............C:\WINNT\system32\WLDAP32.DLL
............C:\WINNT\system32\NETRAP.dll
..........C:\WINNT\system32\ACTIVEDS.DLL
............C:\WINNT\system32\ADSLDPC.DLL
..........C:\WINNT\system32\RTUTILS.DLL
..........C:\WINNT\system32\SETUPAPI.DLL
............C:\WINNT\system32\USERENV.DLL
........C:\WINNT\system32\RASAPI32.dll
..........C:\WINNT\system32\rasman.dll
..........C:\WINNT\system32\TAPI32.dll
............C:\WINNT\system32\COMCTL32.DLL
............C:\WINNT\system32\SHLWAPI.DLL
........C:\WINNT\system32\DHCPCSVC.DLL
......C:\WINNT\system32\VERSION.dll
........C:\WINNT\system32\LZ32.DLL
..C:\WINNT\cygwin1.dll


$ ./pktdump_ex.exe
pktdump_ex: prints the packets of the network using WinPcap.
   Usage: pktdump_ex [-s source]




Mike Marchywka
586 Saint James Walk
Marietta GA 30067-7165
404-788-1216 (C)<- leave message
989-348-4796 (P)<- emergency only
marchywka@...
Note: If I am asking for free stuff, I normally use for hobby/non-profit
information but may use in investment forums, public and private.
Please indicate any concerns if applicable.
Note: Hotmail is possibly blocking my mom's entire
ISP - try  me on marchywka@... if no reply
here. Thanks.


> From: marchywka@...
> To: cygwin@...
> Subject: RE: fate/resolution/location of things like "sys/sockio.h"
> Date: Tue, 27 May 2008 07:03:55 -0400
>
>
>> Date: Tue, 27 May 2008 00:54:37 -0700
>> From: brian@...
>> Mike Marchywka wrote:
>>
>>> $ g++ nmapjunk.a libdnet-stripped/src/junkbin.a liblua/junkbin.a -Lnbase -lnbase -Lnsock/src -lnsock -Llibpcap -lpcap -liphlpapi -lws2_32 -lpcre -L. -lPacket
>>
>> I would not expect this to work in any case. Cygwin has no libpcap, so
>> you must be using the native windows winpcap, which is not a Cygwin
>> library (it's linked with MSVCRT.)
>>
>
> I have winpcap for an earlier install of ShowTraffic which runs fine. The nmap download
> comes with its own and getting everything consistent may be a problem but I can't
> come up with a diagnostic that confirms death during packet.dll load. I guess that is
> why I am more interested in diagnostic tools rather than expecting to find someone who
> knows offhand how to link my c++ version of nmap :)
>
> Is there some simple way to get gdb to tell you what it was trying to do if it dies before getting
> to main()? From what I could tell, you couldn't set a break point etc to diagnose the
> CRT initialization stuff. As far as that goes, what tools are there for dumping object or "a" files?
>
>
> Thanks.
>
>
>
>
> Mike Marchywka
> 586 Saint James Walk
> Marietta GA 30067-7165
> 404-788-1216 (C)<- leave message
> 989-348-4796 (P)<- emergency only
> marchywka@...
> Note: If I am asking for free stuff, I normally use for hobby/non-profit
> information but may use in investment forums, public and private.
> Please indicate any concerns if applicable.
> Note: Hotmail is possibly blocking my mom's entire
> ISP - try me on marchywka@... if no reply
> here. Thanks.
>
>
>> Date: Tue, 27 May 2008 00:54:37 -0700
>> From: brian@...
>> To: marchywka@...
>> CC: cygwin@...
>> Subject: Re: fate/resolution/location of things like "sys/sockio.h"
>>
>> Mike Marchywka wrote:
>>
>>> $ g++ nmapjunk.a libdnet-stripped/src/junkbin.a liblua/junkbin.a -Lnbase -lnbase -Lnsock/src -lnsock -Llibpcap -lpcap -liphlpapi -lws2_32 -lpcre -L. -lPacket
>>
>> I would not expect this to work in any case. Cygwin has no libpcap, so
>> you must be using the native windows winpcap, which is not a Cygwin
>> library (it's linked with MSVCRT.)
>>
>> Brian
>>
>> --
>> 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/
>>
>
> _________________________________________________________________
> Make every e-mail and IM count. Join the i’m Initiative from Microsoft.
> http://im.live.com/Messenger/IM/Join/Default.aspx?source=EML_WL_ MakeCount
>
> --
> 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/
>

_________________________________________________________________
Change the world with e-mail. Join the i’m Initiative from Microsoft.
http://im.live.com/Messenger/IM/Join/Default.aspx?source=EML_WL_ChangeWorld

--
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: fate/resolution/location of things like "sys/sockio.h"

by Brian Dessent :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Mike Marchywka wrote:

> Also, FWIW, I took a sample program in wpdpack and compiled it WITH cygwin
> ( all the makefiles that came with the download did use -mno-cygwin )
> and it at least loaded ( it may function properly  but I haven't checked),

Yes, a trivial invocation of help output usually works.  But still the
problem remains that a library that was built against MSVCRT is not
supposed to be linked against code that was built against Cygwin -- they
are two very different runtimes.  For example, try running one of those
programs and then pressing ^C to stop it and I think you will find it
segfaults or malfunctions in some other random way.  Any behavior in
that situation that does work is by luck, is my point.

But I don't see why you're trying to build a Cygwin nmap anyway.  nmap
has a native win32 port so why not just build that using MinGW?

Brian

--
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: fate/resolution/location of things like "sys/sockio.h"

by Mike Marchywka-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


> are two very different runtimes. For example, try running one of those
> programs and then pressing ^C to stop it and I think you will find it
> segfaults or malfunctions in some other random way. Any behavior in

I'd been skimming these topics, which was why I posted the glut program cygcheck as
it, and probably many programs, show msvcrt in cygcheck. I did just run the packet
capture program and hit refresh on my browser and got a bunch of nicely formated
hex data- I can't verify the data is right but any malfunction isn't due to stack corruption
or a gross build problem. It did even ctrl-C ok.

> But I don't see why you're trying to build a Cygwin nmap anyway. nmap
> has a native win32 port so why not just build that using MinGW?
>

I downloaded whatever they had and followed the instructions but that didn't work
right away. I've never used mingw and don't really see the point as I understand it is
limited and I've gotten used to cygwin. So, it seemed the easier thing to do was make everything
cygwin ( if it can be made to work). This was only supposed to be an example program as I wanted
to lift their ICMP code and write some LAN exploration utilities, their pre-built
binaries are fine for packet scans right now but it may be nice to modifiy a few things soon.


Thanks.



Mike Marchywka
586 Saint James Walk
Marietta GA 30067-7165
404-788-1216 (C)<- leave message
989-348-4796 (P)<- emergency only
marchywka@...
Note: If I am asking for free stuff, I normally use for hobby/non-profit
information but may use in investment forums, public and private.
Please indicate any concerns if applicable.
Note: Hotmail is possibly blocking my mom's entire
ISP - try  me on marchywka@... if no reply
here. Thanks.


> Date: Tue, 27 May 2008 07:03:32 -0700
> From: brian@...
> To: marchywka@...
> CC: cygwin@...
> Subject: Re: fate/resolution/location of things like "sys/sockio.h"
>
> Mike Marchywka wrote:
>
>> Also, FWIW, I took a sample program in wpdpack and compiled it WITH cygwin
>> ( all the makefiles that came with the download did use -mno-cygwin )
>> and it at least loaded ( it may function properly but I haven't checked),
>
> Yes, a trivial invocation of help output usually works. But still the
> problem remains that a library that was built against MSVCRT is not
> supposed to be linked against code that was built against Cygwin -- they
> are two very different runtimes. For example, try running one of those
> programs and then pressing ^C to stop it and I think you will find it
> segfaults or malfunctions in some other random way. Any behavior in
> that situation that does work is by luck, is my point.
>
> But I don't see why you're trying to build a Cygwin nmap anyway. nmap
> has a native win32 port so why not just build that using MinGW?
>
> Brian
>
> --
> 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/
>

_________________________________________________________________
E-mail for the greater good. Join the i’m Initiative from Microsoft.
http://im.live.com/Messenger/IM/Join/Default.aspx?source=EML_WL_ GreaterGood

--
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: fate/resolution/location of things like "sys/sockio.h"

by Phil Betts-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Mike Marchywka wrote on Tuesday, May 27, 2008 2:53 PM::

> $ cygcheck ./pktdump_ex.exe | sed -e 's/ /./g'
[snip]
> ..C:\WINNT\cygwin1.dll
       ^^^^^

This is asking for trouble.  Although it's probably nothing to do
with the current topic, chances are that it's out of date and likely
to be the cause of all sorts of spurious errors.

The only cygwin1.dll on your system should be in /bin (aka /usr/bin)


Phil

--
One of the following statements is true:
This email has not been scanned by Ascribe PLC using Microsoft Antigen
for Exchange.
This email has been scanned by Ascribe PLC using Microsoft Antigen for Exchange.

--
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: fate/resolution/location of things like "sys/sockio.h"

by Mike Marchywka-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message



>> ..C:\WINNT\cygwin1.dll
> ^^^^^
>
> This is asking for trouble. Although it's probably nothing to do


I didn't put it there, I thought that was normal as there are plenty of cyg* dll's there.
At some point my install did get messed, which could be a part of the problem.
However, everything else appears to work and AFAIK the dll's are consistent.
Now that I think about it, I have had a problem with cdrw since a recent update
but that was a fairly overt problem and I thought that it was just built against an earlier cygwin1.dll
so it didn't seem like a mystery ( still runs from DOS window if the wrong cygwin1.dll hasn't been
previously loaded).

Of more interest is probably the relationship between cygwin and MSVCRT as
things that mysteriously work sometimes may be worth examining. I guess they could
just avoid each other but it would be nice to know what the potential problems are.





Mike Marchywka
586 Saint James Walk
Marietta GA 30067-7165
404-788-1216 (C)<- leave message
989-348-4796 (P)<- emergency only
marchywka@...
Note: If I am asking for free stuff, I normally use for hobby/non-profit
information but may use in investment forums, public and private.
Please indicate any concerns if applicable.
Note: Hotmail is possibly blocking my mom's entire
ISP - try  me on marchywka@... if no reply
here. Thanks.


> Subject: RE: fate/resolution/location of things like "sys/sockio.h"
> Date: Tue, 27 May 2008 17:44:49 +0100
> From: Phil.Betts@...
> To: cygwin@...
>
> Mike Marchywka wrote on Tuesday, May 27, 2008 2:53 PM::
>
>> $ cygcheck ./pktdump_ex.exe | sed -e 's/ /./g'
> [snip]
>> ..C:\WINNT\cygwin1.dll
> ^^^^^
>
> This is asking for trouble. Although it's probably nothing to do
> with the current topic, chances are that it's out of date and likely
> to be the cause of all sorts of spurious errors.
>
> The only cygwin1.dll on your system should be in /bin (aka /usr/bin)
>
>
> Phil
>
> --
> One of the following statements is true:
> This email has not been scanned by Ascribe PLC using Microsoft Antigen
> for Exchange.
> This email has been scanned by Ascribe PLC using Microsoft Antigen for Exchange.
>
> --
> 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/
>

_________________________________________________________________
Give to a good cause with every e-mail. Join the i’m Initiative from Microsoft.
http://im.live.com/Messenger/IM/Join/Default.aspx?souce=EML_WL_ GoodCause

--
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: fate/resolution/location of things like "sys/sockio.h"

by Dave Korn :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Mike Marchywka wrote on 27 May 2008 18:12:

>>> ..C:\WINNT\cygwin1.dll
>> ^^^^^
>>
>> This is asking for trouble. Although it's probably nothing to do
>
>
> I didn't put it there, I thought that was normal as there are plenty of
> cyg* dll's there.

  Well, it's "normal for a 3PP".  Which is abnormal by everyone else's
standards...


    cheers,
      DaveK
--
Can't think of a witty .sigline today....


--
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/


MS or cygwin dll debug tools/ was "sys/sockio.h" etc.

by Mike Marchywka-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


Regarding recent comments on dll problems and understanding cygwin1.dll versus msvcrt,
I was curious to know if anyone has used these ( free? ) MS tools or has comments on competing
products?

http://msdn.microsoft.com/en-us/library/cc267862.aspx
http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx

I thought I may be able to download a few pieces like some of the sysinternals products
but AFAIK you now need to download 17MB and hope the msi doesn't do anything
funny. It may be worth it but if there is a better alternative I'd like to try that first.
Apparently gdb didn't let you do anything until getting to main() which is after the initial
process loads but some of the pages for the above tools suggest you can examine loading.

Also, fwiw, that glut program I cited earlier as an example of something that seems
to work but that invokes msvcrt and cygwin1, is available here,

http://www.spottext.com/marchywka/distroform.cfm?src=cygwindll

but I will warn you that there is nothing ready for distribution and the pages are a bit confusing.
I collected a bunch of works-in-progress and started to make them available as part of
other work I was doing. I finally did determine that the streaming data viewer and
molecule viewer uses for the glut program were in fact useful to me and tried to
document some of the features but I'm not sure I will ever document or clean anything
up to the point of being coherent. The glut program does not always seem to start up reliably
on first invokation after a reboot and does have odd response to ctrl-C but otherwise seems
fine ( I assumed this was an issue with opengl,  not cygwin).


Thanks.




> From: marchywka@...
> To: cygwin@...
> Subject: RE: fate/resolution/location of things like "sys/sockio.h"
> Date: Tue, 27 May 2008 07:03:55 -0400
>
>
>> Date: Tue, 27 May 2008 00:54:37 -0700
>> From: brian@...
>> Mike Marchywka wrote:
>>
>>> $ g++ nmapjunk.a libdnet-stripped/src/junkbin.a liblua/junkbin.a -Lnbase -lnbase -Lnsock/src -lnsock -Llibpcap -lpcap -liphlpapi -lws2_32 -lpcre -L. -lPacket
>>
>> I would not expect this to work in any case. Cygwin has no libpcap, so
>> you must be using the native windows winpcap, which is not a Cygwin
>> library (it's linked with MSVCRT.)
>>
>
> I have winpcap for an earlier install of ShowTraffic which runs fine. The nmap download
> comes with its own and getting everything consistent may be a problem but I can't
> come up with a diagnostic that confirms death during packet.dll load. I guess that is
> why I am more interested in diagnostic tools rather than expecting to find someone who
> knows offhand how to link my c++ version of nmap :)
>
> Is there some simple way to get gdb to tell you what it was trying to do if it dies before getting
> to main()? From what I could tell, you couldn't set a break point etc to diagnose the
> CRT initialization stuff. As far as that goes, what tools are there for dumping object or "a" files?
>
>
> Thanks.
>
>
>
>
> Mike Marchywka
> 586 Saint James Walk
> Marietta GA 30067-7165
> 404-788-1216 (C)<- leave message
> 989-348-4796 (P)<- emergency only
> marchywka@...
> Note: If I am asking for free stuff, I normally use for hobby/non-profit
> information but may use in investment forums, public and private.
> Please indicate any concerns if applicable.
> Note: Hotmail is possibly blocking my mom's entire
> ISP - try me on marchywka@... if no reply
> here. Thanks.
>
>
>> Date: Tue, 27 May 2008 00:54:37 -0700
>> From: brian@...
>> To: marchywka@...
>> CC: cygwin@...
>> Subject: Re: fate/resolution/location of things like "sys/sockio.h"
>>
>> Mike Marchywka wrote:
>>
>>> $ g++ nmapjunk.a libdnet-stripped/src/junkbin.a liblua/junkbin.a -Lnbase -lnbase -Lnsock/src -lnsock -Llibpcap -lpcap -liphlpapi -lws2_32 -lpcre -L. -lPacket
>>
>> I would not expect this to work in any case. Cygwin has no libpcap, so
>> you must be using the native windows winpcap, which is not a Cygwin
>> library (it's linked with MSVCRT.)
>>
>> Brian
>>
>> --
>> 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/
>>
>
> _________________________________________________________________
> Make every e-mail and IM count. Join the i’m Initiative from Microsoft.
> http://im.live.com/Messenger/IM/Join/Default.aspx?source=EML_WL_ MakeCount
>
> --
> 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/
>

_________________________________________________________________
Make every e-mail and IM count. Join the i’m Initiative from Microsoft.
http://im.live.com/Messenger/IM/Join/Default.aspx?source=EML_WL_ MakeCount

--
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: MS or cygwin dll debug tools/ was "sys/sockio.h" etc.

by Greg Chicares-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 2008-05-28 14:15Z, Mike Marchywka wrote:
>
> I was curious to know if anyone has used these ( free? ) MS tools

Probably not free as in freedom; I haven't used them.

> Apparently gdb didn't let you do anything until getting to main() which is after the initial
> process loads but some of the pages for the above tools suggest you can examine loading.

Using cygwin's gdb on a MinGW app, I can set this breakpoint
  b '__mingw_CRTStartup'
on the function that invokes main(), and then examine variables
before main() is invoked. For a Cygwin app, I guess you'd break
on 'mainCRTStartup'. Does that breakpoint happen early enough to
meet your needs?

--
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: MS or cygwin dll debug tools/ was "sys/sockio.h" etc.

by Brian Dessent :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Greg Chicares wrote:

> Using cygwin's gdb on a MinGW app, I can set this breakpoint
>   b '__mingw_CRTStartup'
> on the function that invokes main(), and then examine variables
> before main() is invoked. For a Cygwin app, I guess you'd break
> on 'mainCRTStartup'. Does that breakpoint happen early enough to
> meet your needs?

You can also do "info target" to display the entry point and then set a
breakpoint on it as e.g. "b *0x401000" if you want to start at the very
first instruction of the binary.  There is no such "can't debug before
main" restriction.

Brian

--
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: MS or cygwin dll debug tools/ was "sys/sockio.h" etc.

by Spiro Trikaliotis-12 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hello,

* On Wed, May 28, 2008 at 10:15:05AM -0400 Mike Marchywka wrote:
>
> Regarding recent comments on dll problems and understanding cygwin1.dll versus msvcrt,
> I was curious to know if anyone has used these ( free? ) MS tools or has comments on competing
> products?
>
> http://msdn.microsoft.com/en-us/library/cc267862.aspx
> http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx

These a free in the sense that you do not have to pay to use them.
Additionally, you can get in contact with users and even some of the
developers on the Usenet (news:microsoft.public.windbg).

I use WinDBG rather frequently, and I like it very much. However, I must
tell you that I mainly use it for kernel-mode debugging. The Symbol
Server allows you to put the debugging symbols on a server. You can even
have a history of them; that is, for ever version of the executables you
give to customers (or to others), you put the symbols on the server.

If you get a crash dump afterwards from someone, WinDBG automatically
determines the right symbols. If you have also set up the source server,
it even gets the right sources out of your source control system. This
is very handy.

Note, however, that this mechanism relies on .PDB files for the
debugging information (I think the old-style .SYM work, also, but I have
not tested it). I never tried to use this with Cygwin or Mingw, however.

Regards,
Spiro.

--
Spiro R. Trikaliotis                              http://opencbm.sf.net/
http://www.trikaliotis.net/                     http://www.viceteam.org/

--
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: MS or cygwin dll debug tools/ was "sys/sockio.h" etc.

by Mike Marchywka-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


> first instruction of the binary. There is no such "can't debug before
> main" restriction.
>

I think what bothered me is I just tried to step it to get minimum initial
increment and that bombed- so I just assumed it wouldn't be early enough.
In any case, it looked like I needed to instrument the loading process,

(gdb) info functions CRT
All functions matching regular expression "CRT":

Non-debugging symbols:
0x00401000  WinMainCRTStartup
0x00401000  mainCRTStartup
(gdb) info target
Symbols from "/cygdrive/e/new/temp/nmap/src3/nmap-4.62/a.exe".
Local exec file:
        `/cygdrive/e/new/temp/nmap/src3/nmap-4.62/a.exe', file type pei-i386.
        Entry point: 0x401000
        0x00401000 - 0x004e9608 is .text
        0x004ea000 - 0x004ebaa0 is .data
        0x004ec000 - 0x00509c24 is .rdata
        0x0050a000 - 0x00519b50 is .bss
        0x0051a000 - 0x0051bfa8 is .idata
(gdb) b *0x0401000
Breakpoint 1 at 0x401000
(gdb) run
Starting program: /cygdrive/e/new/temp/nmap/src3/nmap-4.62/a.exe

Program received signal SIGSEGV, Segmentation fault.

Program received signal SIGSEGV, Segmentation fault.

Program received signal SIGSEGV, Segmentation fault.

Program exited with code 0200.
You can't do that without a process to debug.
(gdb)

> Date: Wed, 28 May 2008 08:36:33 -0700
> From: brian@...
> To: gchicares@...
> CC: cygwin@...
> Subject: Re: MS or cygwin dll debug tools/ was "sys/sockio.h" etc.
>
> Greg Chicares wrote:
>
>> Using cygwin's gdb on a MinGW app, I can set this breakpoint
>> b '__mingw_CRTStartup'
>> on the function that invokes main(), and then examine variables
>> before main() is invoked. For a Cygwin app, I guess you'd break
>> on 'mainCRTStartup'. Does that breakpoint happen early enough to
>> meet your needs?
>
> You can also do "info target" to display the entry point and then set a
> breakpoint on it as e.g. "b *0x401000" if you want to start at the very
> first instruction of the binary. There is no such "can't debug before
> main" restriction.
>
> Brian
>
> --
> 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/
>

_________________________________________________________________
Give to a good cause with every e-mail. Join the i’m Initiative from Microsoft.
http://im.live.com/Messenger/IM/Join/Default.aspx?souce=EML_WL_ GoodCause

--
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: MS or cygwin dll debug tools/ was "sys/sockio.h" etc.

by Brian Dessent :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Mike Marchywka wrote:

> (gdb) b *0x0401000
> Breakpoint 1 at 0x401000
> (gdb) run
> Starting program: /cygdrive/e/new/temp/nmap/src3/nmap-4.62/a.exe
>
> Program received signal SIGSEGV, Segmentation fault.
>
> Program received signal SIGSEGV, Segmentation fault.
>
> Program received signal SIGSEGV, Segmentation fault.
>
> Program exited with code 0200.
> You can't do that without a process to debug.
> (gdb)

The fact that it never actually begins execution therefore implies that
it encounters a fault by the OS loader during process initialization,
such as the "const data in .rdata needing relocation due to
auto-imports" situation.  I bet that if you invoke it via strace or from
a native command prompt (not bash) you will see a dialog box explaining
the fault since the "SetErrorMode (SEM_FAILCRITICALERRORS)" stuff won't
be active.

Brian

--
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: MS or cygwin dll debug tools/ was "sys/sockio.h" etc.

by Christopher Faylor-8 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Wed, May 28, 2008 at 12:47:44PM -0700, Brian Dessent wrote:

>Mike Marchywka wrote:
>
>> (gdb) b *0x0401000
>> Breakpoint 1 at 0x401000
>> (gdb) run
>> Starting program: /cygdrive/e/new/temp/nmap/src3/nmap-4.62/a.exe
>>
>> Program received signal SIGSEGV, Segmentation fault.
>>
>> Program received signal SIGSEGV, Segmentation fault.
>>
>> Program received signal SIGSEGV, Segmentation fault.
>>
>> Program exited with code 0200.
>> You can't do that without a process to debug.
>> (gdb)
>
>The fact that it never actually begins execution therefore implies that
>it encounters a fault by the OS loader during process initialization,
>such as the "const data in .rdata needing relocation due to
>auto-imports" situation.  I bet that if you invoke it via strace or
>from a native command prompt (not bash) you will see a dialog box
>explaining the fault since the "SetErrorMode (SEM_FAILCRITICALERRORS)"
>stuff won't be active.

Aren't we still talking about using msvcrt and cygwin1 in the same
application where something like a SIGSEGV prior to initialization would
be the expected consequences of mixing the two dlls?

I'd think it likely that either msvcrt or cygwin1.dll to become confused
during dll initialization if one or the other was present.

cgf

--
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: MS or cygwin dll debug tools/ was "sys/sockio.h" etc.

by Brian Dessent :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Christopher Faylor wrote:

> Aren't we still talking about using msvcrt and cygwin1 in the same
> application where something like a SIGSEGV prior to initialization would
> be the expected consequences of mixing the two dlls?

Right, that too I suppose.  You'd have to set breakpoints at the DllMain
of each of those.  Or use a startup-profiler like dependency walker.

Brian

--
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/

< Prev | 1 - 2 - 3 | Next >