Re: Accessing Wiggler from Linux GDB

[Kai Ruottu <karuottu at freenet dot hut dot fi>]

Hans - Dulimarta wrote:
> 
> I downloaded gdb-ppc-eabi_mw-i.exe and tried it.
> 
> The first time I ran it, it complained 'itcl30.dll not found'. After
> setting some environment variables this problem went away but the code
> seemed to hang. Do I have to setup MINGW32 related files on my directory?

 If you have nothing else using the tcl/tk DLLs, there shouldn't be much troubles.

 But if you have any Cygwin-release stuff using them, there will be problems...

 One cannot mix the Cygwin-DLLs and the Mingw32 DLLs. The problem case is the
'tix4180.dll', which one would expect to be 'cygtix4180.dll', when the 'cygtcl80.dll',
'cygtk80.dll', 'cygtclpip80.dll' and 'cygtclreg80.dll' all have the 'cyg' prefix.
Where to put the 'tix4180.dll' for Cygwin-binaries and where to put the 'tix4180.dll'
for Mingw32 (or BCC/MSVC) binaries is really a problem.... The default for the search
directory seems however to be the directory where the application will be started.

 There was no 'ictcl30.dll' in the Cygwin b20.1 release. If some Cygwin-based pre-built
Insight exists, I would expect it using a DLL with the name 'cygitcl30.dll'. Or then
using all DLLs with the base names... I haven't checked the Mumit Khan's 'native' Cygwin-
Insight and how the DLL-names are defined in it. But I would expect him having 'unified'
the naming and they all are with or without the 'cyg'-prefix...

 If all the DLLs are compiled for Cygwin, there is no problems using both Mingw32 and
Cygwin binaries with them. And if all the DLLs are compiled for Mingw32, there are no
problems using both Mingw32 and Cygwin binaries with them. But mixing them is not at
all possible.

 Mixing DLLs which were built with Borland C++ 4.52 or 5.x or with MSVC++ with the Mingw32
built ones should however be possible. And mixing Cygwin-built DLLs with any BCC- or MSVC-
built tcl/tk-DLLs should be expected to fail.

 These thoughts come only from my experiences. I was really (positively) suprised after finding
any Cygwin binaries, which after a pure accident were built to use the base-named-DLLs, to work
ok with the Mingw32-built DLLs (they all were built for Mingw32, none for Cygwin). The arm-elf
target Insight now in my webpage is Cygwin-hosted, because there is no Mingw32 support for the
needed ARM Angel/RDI-protocol yet. But it should work ok with the provided Mingw32-built DLLs.

 If someone can prove me being wrong and there is some compatability between the Cygwin-built
DLLs and the 'native' MSVC, BCC or Mingw32 built DLLs, e.g. using a MSVC++-built 'tix4180.dll'
instead of the Cygwin-built one, or that any application which was built using MSVC++ or BCC++
and uses the 'tix4180.dll', will work with the Cygwin-built 'tix4180.dll', I would like to hear
about that... Then there could be some sanity in the original idea of leaving the 'cyg' away
from the Cygwin-release 'tix4180.dll'...

 I asked these compatability things and the idea in leaving the 'cyg' away from the Tix4.1
DLL, when it cannot be replaced with any BCC, MSVC or Mingw32-based DLL or vice versa, and did
this in the Insight maillist. But haven't got yet any answer...

 There is nothing wrong with the Cygwin-built tcl/tk-DLLs being unreplaceable with any other
DLLs with the same name and them being not able to replace anything with the same name. So using
the 'cyg'-prefix in them all would have been the best solution... No problems with any earlier
or later third-party DLLs then...

> Also, how can I get debugging output out of gdb-ppc-eabi_*.exe in order to
> trace where the program hanged?
 
 Unfortunately it wasn't built with '-g'. If the 'heterogeneous-DLLs'-problem has been solved,
replacing any Cygwin-based DLLs with the native BCC, MSVC or Mingw32-built ones, it shouldn't
hang before even having started...

 When I have a need to debug the Mingw32-hosted Insights, I use a Cygwin-hosted/targeted Insight,
which uses only DLLs with the 'cyg'-prefix in their names. If both the GDB used for debugging and
the GDB which is under debugging both would use the same DLLs, I cannot say what would happen when
the GDB-to-debug crashes when using any of the common DLLs...

 Ok, I could provide this Cygwin-hosted/targeted Insight which uses only the 'cyg'-prefixed DLLs,
if the Mumit-provided Insight now mixes the DLL-names and needs things like 'tix4180.dll',
'itcl30.dll'
and 'itk30.dll' and not their equivalents with the 'cyg'-prefix.

 The instructions/patches for building Mingw32-hosted DLLs from tcl/tk-8.0.x-sources have been in
Mumits place for a long time. If someone wants to build the DLLs with the debug info in them and
build some Mingw32-hosted Insights (under Linux, of course...), I could consider putting the
instructions for this available. Nobody hasn't yet been interested in these 'Cygwin-free' or 'Cygwin
and Mingw32-GUIs in the same system'-compatibility' issues with Insights (but me...). Ok, perhaps
providing the Mingw32-based DLLs with the same 'cyg'-prefix for those who had it in the
Cygwin-release (because the sources for them had extensions from Cygnus, not because the DLLs were
produced with
Cygwin) could have been the solution (but perhaps the Tix4.1 and Itcl3.0 had too)... But I
had the wrong idea about that Cygwin-built DLLs cannot be used with any Mingw32 executables, later
the
mixing of them proved to be the only problem.

 BTW, with Mingw32 (only a little extended) it can be possible to build also Win3.1x/Win32s-hosted
Insights, although it can be a little frustrating to see Insight taking 5 minutes to load in a
386/40 with 8 M memory and WfW3.11 (I know, I tried)... And there are still some weird problems with
the source window (the biggest being the fact that there isn't any source to be seen in the window
when started....) All other windows (Console, Target Selection, Registers, Memory, Stack, etc.) seem
to work ok.

Cheers, Kai


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com