I am using vim + conquegdb for several years now and I am happy with it, however now on mac I want to use lldb.
Is it possible to use conquegdb with lldb? I tried setting the exe path to lldb, but it wont launch lldb afterwards (probably some parameter mismatch).
I also found vim-lldb however I can't for the life of me get this to work/launch a debugger (and I fail to find any real useful help, and :Lhelp doesnt get me anywhere).
From a cursory glance at the sources, it looks like conquegdb works by sending gdb command line commands, and parsing their output. That's not going to work with lldb, both the commands and their output are different.
Related
I'm trying to use LLDB to debug a program on OSX and control-C is not working to stop the program. It seems to be in an infinite loop and I want to see where it is; hence I can't just use breakpoints. This used to work for me -- I used to be able to control-C to send SIGINT and LLDB respected it and stopped the program on this computer with this same toolchain. I see the ^C in the terminal but it's being ignored. I also tried to send the signal to the lldb process in two other ways:
via the Activity Monitor's send signal to process feature
via pkill -SIGINT lldb
However, that didn't work either. control-z DOES work to stop lldb, on the other hand but that's not what I need (which is to be able to inspect program state).
I tried this both with the built-in Terminal app as well as iTerm2 - but I'm seeing the same behavior on both.
Version info
lldb --version
lldb-1000.11.38.2
Swift-4.2
I think this is the version of lldb installed with XCode. It's possible that an upgraded XCode (which I don't use directly) broke this.
Update: I'll add that variable names are not auto-completing for me in lldb either -- I'm pretty sure this also used to work. For example, if I type p and then start typing a variable name, it doesn't tab-complete. I'm adding this update in case it may be related.
See comment above -- it seems that this was a bug with lldb version 1000.11.38.2 when using a command script that contained run in it. Upgrading and/or not using a command script with run allows the program to be interrupted.
I'm using Cygwin and any time I use an Activator command (e.g., activator run or activator "eclipse with-source=true"), any text thereafter is invisible. It's being typed, because if I hit enter, the command will be executed, but I cannot see it.
I've done some searching of this issue, and I'm not the only one to experience it, as I've learned I can blindly type stty sane and I'll get my text visible again, but that's a bit onerous.
Other tips suggest commenting out a certain line in <activator>\minimal\activator, but looking through that file, I see many lines for detecting if the terminal being used is Cygwin and then specific handling for that, so I'm not sure what to edit nor why it isn't already handling the fact that I'm using Cygwin.
Any help would be appreciated, thanks!
For some reasons I had to uninstall/reinstall homebrew on my MacBook Pro (OS X 10.9).
I wanted to reinstall swi-prolog via homebrew (like I did the first time). The installation process worked without any visible issue, but now every time in want to run swi-prolog in my terminal this message appears: "Abort trap: 6"
I have no clue of what that means. There is a lot of things about this message on the internet but I can't relate them with my issue.
Could you help me?
For some reason it seems that the symbolic link doesn't work correctly. In my version of swi-prolog I had to type the full path to get it to run correctly, for example:
/usr/local/Cellar/swi-prolog/6.4.1/bin/swipl
Remember to keep in mind that your version number could be different than what I have listed above.
This became extremely tedious however to remember when having to type it every time I wanted to use Prolog, so I was able to add it as an alias with this command:
alias prolog='/usr/local/Cellar/swi-prolog/6.4.1/bin/swipl'
From that point on in the current terminal session, I was able to open it by just typing:
prolog
This way is obviously much easier, however you need to remember to change the alias if the version also changes.
The command "prolog" can of course be exchanged with any command you wish to use.
Keep in mind, if you want this command to be more permanent (as in after you close the terminal window), you will need to also add the above alias command to the ~/.bash_profile file so it runs on startup.
Hope this helps!
if i am not mistaken, swi-prolog required x11 to run but now in mac 10.9, there were no x11 anymore instead of xQuartz.
i am not sure if this is the real problem now.
I'm working on writing an OS and I'm running into problems trying to debug my code. I'm using GDB to connect to Bochs' GDB stub to "remotely" debug my kernel. Connecting works fine, as does loading debugging symbols from the kernel file. I set a breakpoint for the kmain function, which is successfully located, and the debugger breaks correctly (inside my kernel). However, I can't "step" or "next" through my code, nor can GDB apparently determine which line of code is the current line.
When I try to "step", I get the following message: "Cannot find bounds of current function". This is the only error message I get at any point.
My code is being compiled in GCC with the -g flag (I've tried other types of debugging information using GCC options; none have worked.) I have tried looking through the GDB manual , as well as searching for the answer, and I'm totally stumped. Any help would be amazing.
Thanks!
Well, I got debugging working, but I had to switch emulators. I was able to get GDB working with Qemu, even though I also had problems doing that. To get GDB to connect to the Qemu gdbserver, I had to pass the following option to Qemu: "-gdb tcp::1234,ipv4". Took me forever to figure that out... Debugging works perfectly now!
Googling throws up "This is because when you attached to gdbserver, the process under
debug has not completed the C start-up code" http://www.cygwin.com/ml/gdb/2005-03/msg00237.html... http://www.bravegnu.org/gnu-eprog/c-startup.html describes the process for when you are coding for embedded devices, maybe this will help?
If you find the answer please post here as I'd like to know what the solution to the problem is too.
I don't know why but bochs with gdb-stub enabled seems to be picky with the config options. On some system following options will break it:
--enable-x86-64, --enable-vmx
I'm working on a GUI for Windows XP. Everything works great, except when I run an external command through backticks, %x(), IO.popen, etc, I get a DOS window that pops up for a split second. I know this doesn't happen when I've developed on OS X and Linux. Any ideas on how to get rid of it? (Or at least hide it?)
I'm using rubyw 1.8.6 (the "GUI version" of Ruby for Windows) and GTK2 for the interface.
You can use the Win32API module, and call the windows api CreateProcess Function. It ain't pretty.
As mentioned in a comment, I never found a solution to this. In this particular circumstance, the information I needed was actually already stored on the filesystem (so I just read it in as a file). This wasn't immediately obvious before, and isn't likely to come up in all circumstances.
If anyone finds a "true" solution, I would be interested in hearing about it.