I'm rebuilding a flash loader utility for a TI chip and am facing a minor issue that's affecting my workflow. I'm using a 64-bit Win7 PC and rebuilding the utility using make on cygwin bash shell. make and cygwin version numbers below.
$ make -v
GNU Make 3.82.90
Built for i686-pc-cygwin
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
$ uname -a
CYGWIN_NT-6.1-WOW64 DEEDAA 1.7.15(0.260/5/3) 2012-05-09 10:25 i686 Cygwin
One step in the build process calls a previously generated utility (windows executable) to generate the bin file that is required for the TI processor.
../../AISUtils//HexAIS_OMAP-L138.exe -ini ../sft_hexais.ini -o ../sft_C6748_SPI_MEM.bin ../sft_C6748_SPI_MEM.out
After this command is called there is no progress seen on the cygwin command line. However, execution of the command does complete, generating the files specified in this step and proceeds with the steps that follow in the makefile. It's just that I can never regain control of this window. I always need to kill the window, start another instance of cygwin.
If I try to kill the cygwin window immediately I get the message below.
mintty
Processes are running in session
Close anyway?
If I wait a while (the time to complete the steps that follow), then I can kill the window without this message popping up.
The same command on the windows command line is executed without any stalls and I do regain my command line.
c:\ti\boot_tools\OMAP-L138_FlashAndBootUtils_2_40\OMAP-L138\GNU\AISUtils>HexAIS_OMAP-L138.exe -ini ..\sft\sft_hexais.ini
-o ..\sft\sft_C6748_SPI_MEM.bin ..\sft\sft_C6748_SPI_MEM.out
-----------------------------------------------------
TI AIS Hex File Generator for OMAP-L138
(C) 2012, Texas Instruments, Inc.
Ver. 1.27
-----------------------------------------------------
Begining the AIS file generation.
AIS file being generated for bootmode: UART.
Parsing the input object file, ..\sft\sft_C6748_SPI_MEM.out.
AIS file generation was successful.
Wrote 15464 bytes to file ..\sft\sft_C6748_SPI_MEM.bin.
Conversion is complete.
It seems to me that something about the way the command is constructed is pushing commands on to another shell or forcing it to run in the background. Any thoughts on what may be going on or steps I can try to debug the issue?
file format of the executable that stalls
$ file AISUtils/HexAIS_OMAP-L138.exe
AISUtils/HexAIS_OMAP-L138.exe: PE32 executable (console) Intel 80386 Mono/.Net assembly, for MS Windows
Link to TI wiki that explains the build process. The link provides general instructions on rebuilding the utility and is very unlikely to provide any specific information related to my question. I'm only including it in case someone needed more background about the tools or the process.
http://processors.wiki.ti.com/index.php/Rebuilding_the_Flash_and_Boot_Utils_Package
Thanks.
Running Windows console applications inside a Cygwin (MinTTY) terminal is usually a terrible idea.
Try running inside a Windows (cmd) console or using cygstart to launch in a new window (in a Makefile, -w would probably be useful too).
Related
I have a project consisting of a few libraries which is cross platform and runs and debugs just fine if all the source code is in one Visual Studio 2019 project. However, having the libraries in separate projects and I cannot debug from within the IDE at all. However, the executable will run perfectly ok from the command line in my WSL installation and on other Linux boxes. I have tried various things such as setting my LD_LIBRARY_PATH as one of the projects is a shared dynamic library, but nothing so far seems to work. Anyone have any ideas on this ? Thanks
Update: if I manually copy the dynamic library e.g.
cp libWSI.so /usr/lib/x86_64-linux-gnu/libWSI.so
debugging works. But this is not ideal.
The output I get from the Debugger is this:
=thread-group-added,id="i1"
GNU gdb (Ubuntu 8.1-0ubuntu3.1) 8.1.0.20180409-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.
For help, type "help".
Type "apropos word" to search for commands related to "word".
=cmd-param-changed,param="pagination",value="off"
Stopped due to shared library event (no libraries added or removed)
Loaded '/lib64/ld-linux-x86-64.so.2'. Symbols loaded.
[Inferior 1 (process 1438) exited with code 0177]
The thread 'WSITests.out' (0x59e) has exited with code 0 (0x0).
The program '' has exited with code 177 (0xb1).
My debugger won`t start even with the libs in the same folder when using dynamic linking. I have found a workaround here: https://github.com/Microsoft/VSLinux/issues/257
You have to make a script, let`s say "debug.sh", where you add the paths to your lib folders and run the debugger with --interpreter=mi argument. I suspect this gdb argument does the magic in this case.
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/mnt/c/Users/mircea.goga/source/repos/TestCoreCLRLinux/Out/
/usr/bin/gdb --interpreter=mi
In Visual Studio, set the path to this file to "Remote GDB Path" in "Debugging" section.
image
gdbserver localhost:2159 test_app.exe
Whenever I type this kind of command
I got this kind of message:
glob could not process pattern '(null)'.
Also, it doesn't matter which kind of terminal/CLI I use on my Windows machine -
the result is always the same.
I would like to debug my PDCurses/NCurses app via CLion.
Every time when it encounters the initscr() function CLion says to me that:
Redirection is not supported.
So the only workaround seems to be the usage of GDB Remote Debug.
But due to the problem described above I am not sure if my settings are correct.
$ gdbserver --version
GNU gdbserver (GDB) 8.1
Copyright (C) 2018 Free Software Foundation, Inc.
gdbserver is free software, covered by the GNU General Public License.
This gdbserver was configured as "x86_64-w64-mingw32"
I'm trying to develop code under 64-bit Cygwin, and I'm having trouble getting a core dump file that I can use under GDB. The code is compiled using GCC 7.3.0, and I've just updated my Cygwin bits. ulimit -c is unlimited.
I've got my $CYGWIN variable set to point to dumper, and that appears to be being launched on crashes. I get a pop-up, and the message
*** starting debugger for pid 5288, tid 9464
*** continuing pid 5288 from debugger call (1)
Aborted (core dumped)
and a core file (basic.exe.core) is created in the current dir.
When I try to run (the stock Cygwin) GDB on this
gdb tests/basic.exe --core=basic.exe.core
I get the normal version intro, Reading symbols..., and then a warning
warning: core file may not match specified executable file.
and GDB crashes (and dumps its own core file). The crashing program was launched from the Cygwin bash command line (as ./tests/basic.exe).
It's been a long time since I've tried to develop under Windows or Cygwin, so it's quite possible that I'm doing something stupid. Or, alternatively, it may be that GCC 7.3.0 is doing something wrong or that I configured it poorly when I built it.
Any help will be appreciated.
I am trying to install the google protocol buffer in windows, the instructions first as me this:
cd' to the directory containing the package's source code and type
'./configure' to configure the package for your system. If you're
using 'csh' on an old version of System V, you might need to type
'sh ./configure' instead to prevent 'csh' from trying to execute
`configure' itself.
Running `configure' takes awhile. While running, it prints some
messages telling which features it is checking for.
When I do the './configure' command it tries to open the file label configure in the directory and if I use 'sh ./configure' it doesn't recognise sh as a term. Any ideas?
The instructions you're looking at are for Unix. On Windows, usually you'll want to follow the Windows installation instructions:
https://github.com/google/protobuf#c-installation---windows
As an exception, you'll want to follow the Unix instructions if you plan to use MinGW or Cygwin as your compiler (rather than Visual Studio). In these cases, you'll want to use the MSYS shell (for MinGW) or the Cygwin shell to run the commands in the instructions, not the regular Windows command prompt.
I'm not good at English, and I'm sorry about that.
Now, There is a question about when I debug samba with GDB.
# gdb /usr/local/samba/sbin/smbd
GNU gdb Red Hat Linux (5.2.1-4)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
(gdb) r
Starting program: /usr/local/samba/sbin/smbd
Program exited normally.
(gdb) info program
The program being debugged is not being run.
So, How should I debug samba with GDB?
ps: Version of Samba 3.0.5 I install samba from source code.
you may use sudo ./smbd -i to start smbd and see what's wrong with it.
in my case:
smbd try to find smb.conf in /usr/local/samba/etc/smb.conf and there isn't one, so exit.
i copy /etc/samba/smb.conf to the disired path , then everything ok.
hope this can help you.
Download samba source code from http://www.samba.org and compile it (without source code, it will be impossible to do symbolic debugging).
Stop or kill any other samba instances.
Start samba under gdb:
gdb <path/to/compiled/smbd>
Specify smbd parameters:
set args -i -M single
Parameters -i -M single force smbd to start as single process, do not daemonize and print all messages and errors to stdout/stderr.
Now, you can set breakpoints and trace your source code as you normally would with any other program.
Note: instead of using gdb, you might find more convenient to use gdb-tui (gdb text user interface), or use other debuggers like ddd.