I'm trying to execute a python function after target create so I can iterate over all modules of the target, download missing symbols from the internet (based on GetUUIDString) and then override the GetSymbolFileSpec() directory and path to what I downloaded.
Unfortunately I cannot figure out how to actually get a function invoked at the right time so that the program did not execute yet, the target is created and lldb.target.modules is populated and lets me modify the symbols.
Is there some documentation on how to hook into this? I am aware that there is a theoretical way to fetch symbols on demand via a shell script however that is only implemented on macos and not other platforms.
You probably don't want to do this on target create since there's no guarantee that a target will know all the libraries that will load into it before it actually runs. And plus, you probably also want to handle libraries that are dynamically loaded as the program runs. The real place to do this is on Module add (which is where the hook for DebugSymbols happens in lldb.)
It looks like Linux and Windows don't have the notion of a call-out to some agent to pull in debug symbols. They do look in /usr/local/debug for pre-cached symbols, but there's no mechanism to have a call-out like with dsymForUUID.
If you're up for a little lldb hacking, it would be pretty straightforward to add such a callout. Just make a setting that takes the name of a program. That program would takes as input a UUID, and returns as output the file name for the debug info. Then you could have lldb run this in the same place where lldb currently calls LocateMacOSXFilesUsingDebugSymbols (in LocateSymbols.cpp).
Perhaps a simpler way to do this would be to add a target stop-hook that calls some python based command you've written that looks at the module list and fetches debug information for any new libraries that have shown up. If you want to use this for debugging running programs, you only care that the symbols get added before control returns to the user. So a stop hook would be an appropriate place to do this.
Related
After i quit GDB every user-defined function disappear. Im sure there should be some way to make it available between sessions.
GDB reads the following files before starting: ~/.config/gdb/gdbinit, ~/.gdbinit.
It is a common practice to edit e.g. ~/.gdbinit to define the user-defined function using an external editor and use source ~/.gdbinit in a GDB session to reload that file. Once the function works as you expect, just leave it in your ~/.gdbinit and it will be available in all future GDB sessions.
I am a beginner and started learning C using VS Codium in Ubuntu. So I have a file named "programm1". And every time I try to run it in terminal with "./programm1" it doesnt recognise changes I made, unless I type "make programm1"
Is it supposed to be like this? Or is there ways to make it automatic, so I dont have to save every change I make with "make programm1"?
Your binary, programm1 doesn't know how it is build. Your build system, in this case, make specifies how to build your binary. As you found that you can execute a build manually. This is how I prefer to work (and in nvim I have the plugin ale enabled for real-time feedback).
Linux has a mechanism called inodify that allows a program to be notified of file system changes. You may want to check out wrappers for the API including the packages entr, inotify-hookable and inotify-tools.
Another option is to configure your editor to run make for you when you save a file.
I have a custom board running Yocto (Jethro) and would like to run a single u-boot command, preboot. Obviously, breaking the boot sequence with space and running it manually works. How do I get it to run automatically? More specifically, where is the startup command sequence, by default?
Edit: Also, I am aware I can edit the environment at runtime. However, I am trying to build this change into the image so I can distribute it.
When you are in the uboot environment. Enter printenv, it will list the environment variables that uboot uses.
There is a variable name bootcmd. Currently, mine contain a bunch of if else command. Similarly, add your prefer function there for boot.
And after it is finished and tested. Use saveenv to store the edit
Here is a syntax for uboot.
Edit:
U-Boot allows to store commands or command sequences in a plain text file. Using the mkimage tool you can then convert this file into a script image which can be executed using U-Boot's autoscr command. U-boot Scripting Capabilities
Typically, your U-Boot recipe will build U-Boot for a single machine, in that case, I'd normally just patch the compiled in, default, U-Boot environment to do the right thing. This is achieved by
SRC_URI_machine += "file://mydefenv.patch"
Or (even better) use your own git tree. This would also have the additional benefit that your system might be able to boot up and to something useful, even if the environment would be totally corrupted.
Another possibility is to do it like Charles suggested in a comment to another answer, create an environment offline, and have U-Boot load it, see denx.de/wiki/view/DULG/UBootScripts
A third possibility, that I've also used sometimes, is to construct the environment offline (possibly using the same or a similar mechanism as in the link above), and the flash the environment to flash during the normal flash programming process. Though, most of the time I've done this on AT91's, using a tcl script similar to at91 Sam-Ba TCL script
No matter which method you chose, the bootcmd variable in U-Boot should hold your boot script.
The general answer is that bootcmd is run by default, and if there is persistent environment you can change the command and 'saveenv' so that it's kept.
It is easiest to modify the said bootcmd, which is executed anyway.
As an alternative to patching the kernel, it is possible to override the command in u-boot.
Create a file e.g. platform-top.h at the same place where you would place the patch file (it might already exist) and override the CONFIG_BOOTCOMMAND.
The result will look something like this:
/* ... */
/* replace the memory write with any other valid command */
#define CONFIG_BOOTCOMMAND "mw 0x1 0x1 && run default_bootcommand"
Don't forget to make the file known in your bbapend SRC_URI = "file://platform-top.h"
I'm trying to handle all of User Interfaces (UI) dialogs in .msi installing pakage, with EmbeddedUIHandler to do this I have created a setupui.dll which contains three methods: InitializeEmbeddedUI, ShutdownEmbeddedUI, EmbeddedUIHandler, and put it inside of MsiEmbeddedUI table (using installshield) and it worked just fine.
The problem is when setupui.dll is dependent to other external DLLs, this time windows installer won't use my dll and it uses default ui, I have added other DLL dependencies with Installshield as follow:
I'm uncertain of what Windows Installer allows here. There are, however, three things that jump out at me as things to look into:
The MsiEmbeddedUI table's Attributes column should probably have a 3 for SetupUI.dll (as it does), and 0 for the rest. Per the docs, the 2 bit is ignored if the 1 bit isn't present, but all the other files are better described as "It may be a resource used by the user interface."
The verbose log: does it indicate what's going on? Does it show a failure loading SetupUI.dll that provides a useful error code (hint: file not found probably refers to a dependency)? Does it indicate it didn't even try to load your DLL? Look for lines with EEUI, at least in the successful case.
If Windows Installer does attempt to load SetupUI.dll, how far does it get? If it gets far enough for you to run some code and, say, show a message box, what files are already extracted at that point? If the dependencies are extracted, can you ensure that its directory is on the DLL path via SetDllDirectory or AddDllDirectory? If the dependencies are not extracted, are they present at a later point so approches like delay loading could help?
For the third point, Process Monitor may help you diagnose what's going on if you can't get a message box in there, but it will probably be less clear. Alternately, using Loader Snaps and Debug View might get you a related set of information, but it may be drowned in additional noise.
I have an application that uses LoadLibrary on Windows to dynamically load plugins. However some of the plugins have other dependent DLLs, such as database client DLLs.
When you attempt to load such a DLL and one of the dependent DLLs doesn't exist you get a nasty Windows dialog:
"The program can't start because xxx.ddl is missing from your computer. Try reinstalling the program to fix this problem."
Is there any easy way to avoid this dialog? I was hoping one could use LoadLibraryEx and pass a flag that says "don't give me that annoying dialog", but it doesn't seem like it.
What I'd like is for the application to handle that error, rather than Windows handling it for me, especially as the text of the message is incorrect (the problem isn't that the program can't start, the program is running quite happily, it just can't load this plugin).
What I'd like to avoid is having to rewrite the plugins that have these external dependencies to make them themselves do a dynamic load of any dependent modules and then query for any entry points.
Anyway, any suggestions would be gratefully received.
Use SetErrorMode(). Use it with SEM_NOOPENFILEERRORBOX | SEM_FAILCRITICALERRORS before you load the DLL and with 0 right after.
From MSDN:
To enable or disable error messages displayed by the loader during DLL loads, use the SetErrorMode function.
Link here