I would like to follow the answer in this question:
Permanently Change Disassembly Flavor in GDB
but it refers to a GDB file named .gdbinit. What is the equivalent file when using GDB through cygwin?
gdb help output tells you where it's looking at startup:
$ gdb --help | tail
Set GDB's data-directory to DIR.
At startup, GDB reads the following init files and executes their commands:
* user-specific init file: /home/davidw/.gdbinit
* local init file (see also 'set auto-load local-gdbinit'): ./.gdbinit
For more information, type "help" from within GDB, or consult the
GDB manual (available as on-line info or a printed manual).
Report bugs to "<http://www.gnu.org/software/gdb/bugs/>".
You can also get a little more information from within gdb with the command
show autoload.
See also the online manual here.
Not really relevant to this question, but the reason I spent time looking into this was that, with cygwin, my .gdbinit seemd to be getting ignored. It turned out to be the command in my .gdbinit that was being ignored.
Related
I installed Haskell on my MacOS system using ghcup installer. It worked because if I type ghci I am dropped into this interactive shell. However I got this message in the terminal after doing the install:
In order to run ghc and cabal, you need to adjust your PATH variable.
You may want to source '/Users/user1/.ghcup/env' in your shell
configuration to do so (e.g. ~/.bashrc).
Detected bash shell on your system...
If you want ghcup to automatically add the required PATH variable to "/Users/user1/.bashrc"
answer with YES, otherwise with NO and press ENTER.
YES
grep: /Users/user1/.bashrc: No such file or directory
My shell is bash 3.2 But as you can see, when I typed YES it says there is no such file. How do I find my shell configuration file, or resolve this? I'd like to complete the setup correctly here.
And I have to be honest about my level of knowledge here, I don't truly understand what this is asking exactly. Is the PATH variable 'env'?
On macOS, .bashrc does not exist by default. ghcup will create this file, so the command you ran will have worked correctly. However, one of ghcup's subcommands expected to find the file before it was created, and therefore reported that error message. You can safely ignore this.
I have Vim on Windows server 2012, and when I start it from the start menu everything works fine. However, when I start it from the command line it take 5 seconds and uses 700MB memory. Even when its not opening a file. There is something weird going on, and I was wondering if there are any ways to debug it/figure out what is causing this? Thanks, Eric.
EDIT:
Here is the result of vim --startuptime outputfile (abbreviated):
times in msec
clock self+sourced self: sourced script
clock elapsed: other lines
000.000 000.000: --- VIM STARTING ---
...
016.000 016.000: parsing arguments
016.000 000.000: expanding arguments
4794.000 4778.000: shell init
4794.000 000.000: Termcap init
...
4825.000 000.000: setting raw mode
8768.000 3943.000: start termcap
8768.000 000.000: clearing screen
8783.000 000.000: --- VIM STARTED ---
You could use Sysinternals' Process Explorer to check if any of the processes are starting child processes or if there is any difference in the environmental variables.
Also, Sysinternals' Procmon would allow you to check what registry entries, files, etc does any application use (filter by command name includes vim), but probably you will find the differences just with Process Explorer.
Sysinternals was a company that created some nice apps for Windows and Microsoft bought it some years ago. You can access the last version of any of their apps on http://live.sysinternals.com
Excerpt from Vim FAQ 2.5:
2.5. I have a "xyz" (some) problem with Vim. How do I determine it is a
problem with my setup or with Vim? / Have I found a bug in Vim?
First, you need to find out, whether the error is in the actual runtime
files or any plugin that is distributed with Vim or whether it is a
simple side effect of any configuration option from your .vimrc or
.gvimrc. So first, start vim like this:
vim -u NONE -U NONE -N -i NONE
this starts Vim in nocompatible mode (-N), without reading your viminfo
file (-i NONE), without reading any configuration file (-u NONE for not
reading .vimrc file and -U NONE for not reading a .gvimrc file) or even
plugin.
In this invocation, try to reproduce your problem. If the error
persists, the chance is good you've found a bug in Vim (see also
Question 2.6. faq-2.6)
If the error does not occur when starting Vim this way, then the problem
is either related to some plugin of yours or some setting in one of your
local setup files. You need to find out, what triggers the error, you
try starting Vim this way:
vim -u NONE -U NONE -N
If the error occurs, the problem is your .viminfo file. Simply delete
the viminfo file then. If the error does not occur, try:
vim -u ~/.vimrc --noplugin -N -i NONE
This will simply use your .vimrc as configuration file, but not load any
plugins. If the error occurs this time, the error is possibly caused by
some configuration option inside your .vimrc file. Depending on the
length of your vimrc file, it can be quite hard to trace the origin
within that file.
The best way is to add :finish command in the middle of your .vimrc.
Then restart again using the same command line. If the error still
occurs, the bug must be caused because of a setting in the first half of
your .vimrc. If it doesn't happen, the problematic setting must be in
the second half of your .vimrc. So move the :finish command to the
middle of that half, of which you know that triggers the error and move
your way along, until you find the problematic option.
It also mentions how to create a log file:
You can also use the -V command line argument to get more debug
information to analyze the problem:
$ vim -V2logfile
You can increase the value passed to the -V argument to get more debug
information. By also specifying a logfile name, this makes sure, the
debug messages don't appear on the screen and won't disturb you when
trying to reproduce the problem.
Before I debug or execute a program on my system at work, I have to source a file that contains numerous paths and settings that are specific to each project. Is there a way I can do this from gdb? I tried putting it into a .gdbinit file in the working directory, but that doesn't seem to be working. I tried to see if the environmental variable was set by typing
(gdb) shell echo $MY_VAR
and it was blank. Any ideas?
Basically to set the environment variable in the command prompt, you can use the set environment varname [=value]. More information is present here. Since you have noted down there are huge number of paths to be set, you can add them to a file like myGdbSrc and then load them explicitly using source [-s] [-v] filename. You can find details on loading a file here.
I have tried both of them and it works.
HTH.
PS: I have tried it on GNU GDB 6.6 version on SUSE Linux. However, it must work across all version since it seems to be basic command.
How about writing a wrapper script which sources your settings before loading gdb?
E.g. some trivial example:
#!/bin/sh
source my-script-which-sets-up-the-environment
gdb $*
This can of course also add arguments to the gdb invocation to setup paths, load a gdb script, etc.
I was trying to use gdb on a program earlier on a Linux 64-bit machine, and I ran gdb bomb (that's the program name), and within gdb, I simply typed in ran. It came back with the error /bin/bash: /home/imicrothinking/ics11302016004/lab2/bomb: No such file or directory During startup program exited with code 127.
I've dug around the net for a bit, and suggestions I've heard so far led to no concrete solutions, here's what I'm sure of so far:
I'm logged on as a root level user.
I haven't gone to the wrong directory.
The executable file definitely exists.
I'd welcome all suggestions.
maybe gdb cann't find your shell. so set the env var SHELL to your shell.
eg: export SHELL=/bin/bash
ref : http://www.linuxquestions.org/questions/linux-software-2/gdb-giving-wierd-error-169299/
So I wrote buggy code that occasionally crash ... and creates a stackdump file.
Using addr2line I can figure out how the program got to the crash point by decoding the addresses from the stackdump one by one. Is there an alternative tool that can ease the debug using stack dumps?
Is there a way to to load this information in Insight/Gdb?
You can instruct Cygwin to start your gdb debugger just in time when an fault occurs.
To achieve this, add error_start=action to the Cygwin environment variable:
export CYGWIN="$CYGWIN error_start=gdb -nw %1 %2"
Else you can have Cygwin generate a real core dump.
export CYGWIN="$CYGWIN error_start=dumper -d %1 %2"
Firstly, make sure you build with source debugging enabled (the using -g option):
gcc -g -o myfile myfile.c
Then Load the dump into gdb after the crash (or insight, or ddd)
gdb myfile core