In the past (10.11 to 10.14), to debug a System Pref Pane, you could make a copy of System Preferences and self-sign it, then use this copy as the debug target. This method bypassed the System Integrity Protection restrictions.
With Catalina, all third party prefPanes are now loaded in a system process called "legacyLoader". This is located at:
/System/Library/Frameworks/PreferencePanes.framework/Versions/A/XPCServices/legacyLoader.xpc/Contents/MacOS/legacyLoader
Self-signing a copy of legacyLoader is no longer possible. Although you can obviously still make a copy and self-sign it, there is no way to force System Preferences to use the modified self-signed copy as it will always launch the built-in, Apple-signed legacyLoader.
The only way I can see on 10.15 to debug a prefPane is to disable SIP system-wide. Not a great solution.
Does anyone know a way to debug something in legacyLoader without disabling SIP?
I have tried creating my own host application to load the prefPane during development but I have run into a few bugs that only show up when running in System Preferences (legacyLoader) that do not show up when running in my own host.
I really need a way to debug these in the real environment without the inherent security risks of disabling SIP.
Related
I want to setup the following environment: I've got a STM32H753I-EVAL2 eval board, connected on a Windows PC. Until now I was developping and debugging locally on this PC with STM32CubeIDE. For several reasons my code source is on a Linux server (Samba mounting) so it takes forever to build a project. Hence I want to develop on the linux server from my Windows machine.
Compiling is working fine (and is way faster) but the issue is about debugging. I know it is possible to debug remotely, the Debug Configuration window from Eclipse (I'm using OpenOcd) allows to connect to a remote GDB server. What I don't know is how to start a GDB server on the Windows machine that will connect to the STM32 board ?
Sorry for the "answer to myself" but I think it might be useful for others (and even to me when I have forgotten in a few weeks ;) ).
Here is how to do.
on host side (on the machine where the eval board is physically plugged in) you have to manually launch the GDB server application that comes with STM32CubeIDE installation. See STMicro application note UM2576 for details. The default command line is:
ST-LINK_gdbserver.exe -d -v -cp "C:\ST\STM32CubeIDE_1.0.0.19w12patch\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_1.0.0.201903011553\tools\bin"
Now you've done the hardest. On server/remote side you have to setup the Debug Configuration to use OpenOcd with option "Connect to remote GDB server" and simply enter IP address and port number (which is not 3333 by default but 61234, but it can be modified).
This setup is working fine, even if I encoutered some instabilities during debugging once in a while.
I see two (maybe three) options
Use an alternate GDB server (see below)
Run the GDB server from STMCubeIDE in isolation (see OP's answer for Windows, this answer for Linux)
GDB Serial (not really an option right now but I'll share my experience so far)
I have used the second option to succesfully debug my target using arbitary GDBs such as gdb-multiarch command line and in the (non STMCube-ified) Eclipse CDT
Alternative GDB Servers
You could try STLink open source. I did. The problem is, your device might not be supported properly. I built 1.6.1 from Github to enable support for STM32G03x device. While moving to this version enabled it to detect the device, and I can use st-flash to program the device, the debugger is unusable (try and alter a register, it alters the wrong one, try and single step a program, it crashes immediately).
Do try it though .. it's easy and quick to install (or build), so it's worth checking if your device will work correctly with it.
Openocd is another option, but seems not to support SWD connection. I tried a build that allegedly had a patch for this but no luck.
If you can get one of these open source alternatives to work, they have another advantage, you may be able run them on something like a Raspberry PI, which means you don't have to get a PC physically close to your target.
Run the GDB server from STMCubeIDE in isolation
For Windows, see the OP's answer. For Linux, I do this alter the pathnames to suit your installation
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/user/apps/st/stm32cubeide_1.5.1/plugins/com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.linux64_1.5.0.202011040924/tools/bin/native/linux_x64/ /home/user/apps/st/stm32cubeide_1.5.1/plugins/com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.linux64_1.5.0.202011040924/tools/bin/ST-LINK_gdbserver -p 61234 -l 1 -d -s -cp /home/user/apps/st/stm32cubeide_1.5.1/plugins/com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.linux64_1.5.0.202011040924/tools/bin -m 0 -k
How did I get to this? Firstly launched a debugging session from STMCubeIDE, then ran
ps aux | grep gdbserver
Then we can see how Eclipse (STMCube) is launching the gdbserver and work from there.
If you find it complains about a .so file, locate that file from the STMCube installation and ensure the path to the directory containing it is in LD_LIBRARY_PATH (as per my example)
You can also launch the program with --help to show more options.
If add -e (persistent) you can disconnect and reconnect a GDB client without resetting the target (it will reset on initial invocation of the gdb server though, even without -k).
GDB Serial
This is where the target implements the GDB server end of the protocol. The GDB stub usually runs in an exception handler. This would usually be your breakpoint handler but you can also make it the default handler for unhandled exceptions, or, for example, the ctrl-c interrupt.
I have done a lot of Googling about this recently and basically when people ask about it on forums they usually get responses along the lines of "Here be dragons" or "Why don't you use JTAG?"
So the drivers for this, you might like to know, are in the GDB sources git://sourceware.org/git/binutils-gdb.git under gdb/stubs. The documentation is here. There isn't a stub implementation there for arm. Which is sad really, I used to use GDB remote serial regularly where I worked, and some of those targets were indeed ARM. The operating system was ecos.
So could ecos GDB stubs be ported to bare metal? Having giving it a good coat of looking at, I believe yes they could. The stubs are based on the ones from the GDB sources but they are heavily polluted with Ecos and Redboot build macros and copyright (the ogiringals were written by HP and released without copyright). We don't know what bugs the Ecos stubs may contain (I fixed at least one back in the day and I don't recall whether I submitted a patch). We don't know if they really support the latests architectures properly. And, we don't know if, after that, they simply use up too much memory - my STM32 has 8K of SRAM and I already see buffers that have a default size of 2K (not saying that's necessary but you see how work needs to be done here..)
So this third option, I will revisit this one day but for now, for me, it's a nope.
I have to create and configure an eclipse (Mars 2) for a C project. The project is on a SVN repository, and can only be compiled on a specific linux redhat server that has the appropriate toolchain.
What I need is an IDE that would allow me to commit my changes to the repository and that would automagically synchronize them on the Linux server. I tried a few things but none of them worked. I must (to my great regret) avoid the need of a terminal while using that IDE, but of course not while configuring it.
Firstly, I used the Remote System Explorer feature in eclipse. I connected succefully to the server, created a "Remote Project" that I could open in the C/C++ perspective. However, the whole thing is impossible to use, as it has no indexation, I had to create "User Actions" in order to compile (which is on my point of vue pretty anti-ergonomic) and the SVN plugin does not detect the project as an SVN copy. Furthermore, in the C/C++ perspective, there is a 2s gap between the moment I type something, and the moment it appears on my screen.
I also tryed to mount a network filesystem on my local machine, with sshfs, and if it works far better, I still experience lags. Also, I had to write a Makefile and call my compiler via "ssh $(USER)#$(HOST) build.ksh". (one of the point of the projetc is to write a real Makefile...). But SVN is working.
I also tried to run eclipse on the host machine, with X forwarding, and if it works perfectly, there is still lags...
Finally, I tried an sftp synchronisation, but it seems I can't use my SVN plugin features and the sftp together.
I am out of solutions, and pretty frustrated as I feel that this kind of things should be pretty easy. I mean, all I want is that eclipse automatically copy my files on my remote home directory... Thanks for your help...
To me this sounds like a perfect use-case for a continuus integration (CI) system. Generally speaking, this CI system pulls the code from your repository (for example in regular intervals) and then executes the build chain, collects artifacts, informs you about the state of your build, etc.
Although it originated from the Java world, I have successfully used Jenkins for continuus integration of C-projects on a Linux server, but there are others, like TeamCity or GitLab CI (the latter would require you to switch to Git, but it's a really neat system with a YAML configuration for CI).
Of course CI systems have a learning curve - you don't something like a free meal - but it may really be worth the effort.
Would it be possible to execute QtCreator as a nornal user but run and debug an application as root?
That would be useful i.e. while developing applications based on WiringPi, which facilitates the access to GPIO but requires root to effectively enable access to the hardware.
To be more clear in my intentions, I would like that when I hit Ctrl+R in QtCretor, then it runs the app as root. And the same idea for debugging, when I hit F5 it starts debugging mode as root. All that while QtCreator is running by a normal user.
WiringPi does not need root access. You need to set properties to the relevant device nodes properly, that's all. Make sure you have /dev/gpiomem available for use by WiringPi, writable by the user. It's available on 4.1 and newer kernels IIRC.
Your question is a case of an X-Y problem. Yes, root access sidesteps the problem of wrong device node properties, but it's not a proper solution at all. Don't run your application as root.
I solved today the same issue with wiringPi following this comment: https://askubuntu.com/a/711130
In my case it was:
Tools-> Options-> Environment replaced the default string with "/usr/bin/xterm -e sudo" in terminal option.
Also, do not forget to go to Projects > Build & Run > Run and check the box Run in terminal.
The short answer is no. Even if you could start the application to run as root from within a non-root QtCreator context, you would not be able to connect to the running process and debug it.
You are better off just running QtCreator as root.
If you need to develop a "user mode" interface to the GPIO pins, you can try
this tutorial: LED Driver
It shows a way to create nodes within the /sys tree that can give you usermode access to the GPIO.
Creating a ATL COM DLL in Vs2015 for a VB6 consumer is going badly because the "fault tolerant heap shim" is being applied to VB6, which I am running from the vs2015 debug command.
I have found many posts about disabling FTH in Windows 7, and indeed I have applied them all, including deleting the DLL in \Windows\AppPatch, as well as disabing FTH in the registry AND running the rundll script that is cited.
Still, this damn thing is making it impossible for me to debug the dll, because the FTH makes it run like a dog under VB6 in debug mode.
I even added "vb6.exe" and "full_path_to_vb6.exe" in the exclusions list in the registry -- to no avail.
I desperation, and needing to get some work done today, I have renamed vb6.exe to myvb7.exe (!) and this gets rid of the FTH alert in the VS debugger. But why can't I disable FTH for vb6.exe?
In fact, why does it even get enabled at all when a debugger is attached? It's driven me mad today.
Anyone?
There wasn't too much help forthcoming on this. For future reference, if the application (in this case VB6) is set to run in compatibility mode (either from a right click on the shortcut you use to launch it, or from a property set on the target exe itself) then nothing you do will release the shim!
Solution: don't run vb6 in compatibility mode under Windows 10!
My Qt Windows desktop application crashes on first QNetworkAccessManager->get call. I get following error in the log.
Auto configuration failed
16100:error:02001015:system library:fopen:Is a directory:.\crypto\bio\bss_file.c:122:fopen('d:/openssl/ssl/openssl.cnf','rb')
16100:error:2006D002:BIO routines:BIO_new_file:system lib:.\crypto\bio\bss_file.c:127:
16100:error:0E078002:configuration file routines:DEF_LOAD:system lib:.\crypto\conf\conf_def.c:199:
It is something related to OpenSSL configuration, but I actually don't use (and don't need) SSL in my application. I know that OpenSSL library is loaded together with QNetworkAccessManager, but is there any way to disable it?
I can fix this problem by reinstalling openssl libraries like it is stated here, but this is not a good solution since I cannot force my customers to reinstall openssl on their systems because of my application. So I am looking for a better solution.
I already tried adding DEFINES += QT_NO_SSL into my project file but with no luck. Interesting here is that this is only happening after I deploy my application, it works smoothly from Qt Creator.
Important thing here is that I can manually manipulate crashing (on deploy systems) by modifying OPENSSL_CONF environment variable. If it does not exist or if it is set correctly, app won't crash, otherwise (env. variable is set to incorrect folder) app crashes.
Any ideas?