From: Alan W. I. <ir...@be...> - 2014-01-20 20:36:03
|
I have used mingw-get install msys-core-dbg=1.0.17-1 to get access to strace.exe. bash.exe-3.1$ which strace /z/home/wine/newstart/MinGW-4.7.2/msys/1.0/bin/strace.exe However when I try it on some command, the command executes without issues but there is no additional output from strace. bash.exe-3.1$ strace /z/home/wine/newstart/MinGW-4.7.2/bin/gcc.exe --version gcc.exe (GCC) 4.7.2 Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Does anybody know how to get the MSYS version of strace to actually produce diagnostic output for the above (or any other) command? My guess is I will have to rename some MSYS dll's, but before trying that I thought I should ask here first for advice from someone who is experienced with running the MSYS version of strace as delivered by the above msys-core-dbg install. To give the larger story about why I need access to a working strace, for several years now I have had some success building and testing PLplot and its many dependencies using MinGW/MSYS on Wine. The current versions I am using are MinGW-4.7.2, the corresponding MSYS provided by the automatic installer (although I downgraded to msys-core-1.0.17 because of bug http://sourceforge.net/p/mingw/bugs/1950), and Wine-1.6.1. However, Wine is very slow for builds (sometimes up to a factor of 30 compared to the corresponding Linux result) because of a severe startup latency (typically 0.3 seconds which does not sound like much until you multiply that by tens of thousands of commands) for each of the many commands that are typically used to build and test a medium-sized piece of software like PLplot. So up to now I have kept my tests limited to the PLplot standard build-tree tests. All is well for that case for our C library and examples, and C++, Fortran 95, Python, Lua, Tcl, and Ada bindings and examples. However, when I recently attempted a very similar test for our installed examples, the Ada examples produced no results at all and a return code of 3. Since those same Ada examples worked fine in the build tree, I assume there is some screwup in the way that the Ada examples were built in the install tree or else some screwup in the environment that Ada executables need to run properly for the install-tree case. So strace might be able to find what the problem is in an instant, but only if it actually produces diagnostic output. :-) Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Keith M. <kei...@us...> - 2014-01-20 22:32:54
|
On 20/01/14 20:35, Alan W. Irwin wrote: > I have used > > mingw-get install msys-core-dbg=1.0.17-1 > > to get access to strace.exe. > > bash.exe-3.1$ which strace > /z/home/wine/newstart/MinGW-4.7.2/msys/1.0/bin/strace.exe > > However when I try it on some command, the command executes without > issues but there is no additional output from strace. > > bash.exe-3.1$ strace /z/home/wine/newstart/MinGW-4.7.2/bin/gcc.exe > --version > gcc.exe (GCC) 4.7.2 > . . . I may be wrong, but I suspect that MSYS' strace will only trace MSYS programs -- i.e. those which are linked with msys-1.0.dll. This MinGW GCC is not such a program; it is a native Windows application. -- Regards, Keith. |
From: Alan W. I. <ir...@be...> - 2014-01-20 23:35:38
|
On 2014-01-20 22:32-0000 Keith Marshall wrote: > On 20/01/14 20:35, Alan W. Irwin wrote: >> I have used >> >> mingw-get install msys-core-dbg=1.0.17-1 >> >> to get access to strace.exe. >> >> bash.exe-3.1$ which strace >> /z/home/wine/newstart/MinGW-4.7.2/msys/1.0/bin/strace.exe >> >> However when I try it on some command, the command executes without >> issues but there is no additional output from strace. >> >> bash.exe-3.1$ strace /z/home/wine/newstart/MinGW-4.7.2/bin/gcc.exe >> --version >> gcc.exe (GCC) 4.7.2 >> . . . > > I may be wrong, but I suspect that MSYS' strace will only trace MSYS > programs -- i.e. those which are linked with msys-1.0.dll. This MinGW > GCC is not such a program; it is a native Windows application. Hi Keith: Thanks for your quick reply. That possible explanation might be correct, but there is at least something else going on because the problem still exists for such executables. For example, bash.exe fits your criterion, i.e, msys-1.0.dll is mentioned in objdump -x output for bash.exe. However, for that executable also, there is no additional output from strace. bash.exe-3.1$ strace bash --version GNU bash, version 3.1.17(1)-release (i686-pc-msys) Copyright (C) 2005 Free Software Foundation, Inc. There appears to be a discussion of a similar problem back in 2004 (!) at https://sourceforge.net/mailarchive/forum.php?thread_name=404CA5D6.3060708%40users.sourceforge.net&forum_name=mingw-msys The guy finally got strace to actually produce output, and here was his comment about that: "I can't run strace from a shell running the debugging dll. I need to run strace from the official dll and execute a command in a directory with my debugging DLL. Not sure why that happens, but I have it working now." For the above test MinGW-4.7.2/msys/1.0/bin included strace.exe, bash.exe and msys-1.0-debug.dll, msys-1.0.dll, and msys-1.0.dll.dbg. I assume msys-1.0.dll is the "official dll", but which of the other two (which I presume got installed as part of msys-core-dbg=1.0.17-1) is the "debugging dll"? In any case, from the quote above it appeared to me what I should do was to _move_ both msys-1.0-debug.dll and msys-1.0.dll.dbg to a non-system location, and also _copy_ bash.exe there. Then that non-system location follows the above conditions (no debugging dll where strace.exe is located, but that debugging dll is located where the program to be straced is located. Alas, that did not work: bash.exe-3.1$ strace ./bash --version GNU bash, version 3.1.17(1)-release (i686-pc-msys) Copyright (C) 2005 Free Software Foundation, Inc. Note, the ./ before bash which executes the copy in the same location as msys-1.0-debug.dll and msys-1.0.dll.dbg. Anybody have any other ideas about how to get the MSYS version of strace to produce diagnostic output? Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2014-01-20 23:51:08
|
On 2014-01-20 15:35-0800 Alan W. Irwin wrote: > In any case, from the quote above it appeared to me what I should do > was to _move_ both msys-1.0-debug.dll and msys-1.0.dll.dbg to a > non-system location, and also _copy_ bash.exe there. Then that > non-system location follows the above conditions (no debugging dll > where strace.exe is located, but that debugging dll is located where > the program to be straced is located. Alas, that did not work: > > bash.exe-3.1$ strace ./bash --version > GNU bash, version 3.1.17(1)-release (i686-pc-msys) > Copyright (C) 2005 Free Software Foundation, Inc. > > Note, the ./ before bash which executes the copy in > the same location as msys-1.0-debug.dll and msys-1.0.dll.dbg. P.S. For the above experiment I forgot to rename one of those appropriately so the bash copy would still be using the system version of msys-1.0.dll. For that local location where a copy of bash.exe exists, if I try cp msys-1.0.dll.dbg msys-1.0.dll then the following (Wine?) error is generated by strace ./bash --version err:module:attach_process_dlls "msys-1.0.dll" failed to initialize, aborting err:module:LdrInitializeThunk Main exe initialization for L"Z:\\home\\wine\\newstart\\build_script\\build_dir-1.6.1\\epa_build\\Source\\comprehensive_test_disposeable\\shared\\install_build_tree\\ada\\bash.exe" failed, status c0000005 I _think_ (but that needs confirmation) this implies msys-1.0.dll.dbg is not what I should be using for msys-1.0.dll. If I try the other alternative, i.e., cp msys-1.0-debug.dll msys-1.0.dll then the result is bash.exe-3.1$ strace ./bash --version GNU bash, version 3.1.17(1)-release (i686-pc-msys) Copyright (C) 2005 Free Software Foundation, Inc. i.e., bash.exe found the local copy of msys-1.0.dll (which was copied from msys-1.0-debug.dll) and was able to load it without issues, but the original problem (no additional output from strace) remains under these circumstances. Are there any other suggestions? For example, are there any other obvious experiments I should be trying? Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |