When remote debugging using gdbserver, I'd like to get gdb to load some shared libraries of the programm being debugging from the local sysroot, but also allow download feature from gdbserver to load others, which are not present in the sysroot.
It seems that gdb can use only one method to find libraries, local files or remote download, and not both.
Example, if I set sysroot to target:/ to use remote files, everything will be downloaded:
(gdb) set sysroot target:/
(gdb) run
Starting program:
Reading /root/a.out from remote target...
warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
Reading /root/a.out from remote target...
Reading symbols from target:/root/a.out...
Reading /lib/ld-linux-armhf.so.3 from remote target...
Unfortunately, the system libraries on the remote system do not have debug symbols. It's an embedded system with limited flash space. Debugging symbols increase the total file system size a great deal and simply don't fit.
However, I have a local sysroot tree of all the system libraries and this does include debugging symbols. But if I set sysroot to this tree, gdb will no longer consider remote downloads.
(gdb) set sysroot /bsp/sysroot
(gdb) run
Starting program:
Reading symbols from /bsp/sysroot/root/a.out...
warning: Could not load shared library symbols for /lib/libm.so.6.
In this example, libm.so.6 is not present in the sysroot, but could have been downloaded from the target. But there seems to be now way to add target:/ back to the search path. Putting it in solib-search-path has no effect.
This situation arises from the use of a board support package (BSP) in embedded systems development. The BSP contains many libraries, which are stripped on the target, as they wouldn't fit otherwise, but have unstripped copies for the host. Users of the BSP build their own software it, but this software isn't part of the BSP and isn't present in the BSP's sysroot. It is however on the target system.
There seems no way to tell gdb to first try to find libraries locally, but then fall back to remote download if they are not found.
GDB does not support multiple sysroots, but there are some work-arounds.
One way to fix the issue is by patching GDB to actually support multiple sysroots. Function solib_find_1 in gdb/solib.c (link to source code) handles the library lookup. Currently, it checks the sysroot (and if that starts with target:, uses the libraries from the target). Otherwise it takes the basename (i.e. takes the file name from the given absolute path) and looks up the libraries in solib-search-path.
To get the desired behavior, the solib_find_1 function should instead fall back to a different directory, e.g. this patch: https://gitlab.com/gbenson/binutils-gdb/commit/0ebe17076406a85a35eb0c4f362850ed9efb843e
A simpler approach without patching GDB: Copy the target libraries to the host. Variants include:
Directly inside the local sysroot. This is quick and simple.
With symlinks inside the local sysroot to the location of the target libraries.
Use a filesystem that merges multiple locations, such as OverlayFS.
Use a bind mount to mount the directories or files over the sysroot.
If you don't want to copy files: Establish an automatic local mirror of libraries from the target (e.g. with sshfs), and use the approaches from the previous point to fall back to the target when needed.
If you don't have the ability to alter the filesystem, then you can put a proxy between your GDB client and the GDB server:
Use set sysroot target:
Create a proxy for GDB's File-I/O Remote Protocol, and let it transparently forward every message, except for requests for target files. If the files of interest are available locally, reply with that. Otherwise forward the message as-is.
Attach the debugger using target remote :[your_proxy_port] instead of target remote :[actual_gdbserver_port], to let your proxy connect to the gdbserver on your behalf.
I found that a combination of the "Copy the target libraries to the host" variants was the most effective, as it has minimal requirements (I only need a way to copy/receive files from the target once):
I copied the system libraries from the target to a local directory. I actually copied all of them so I didn't have to find out which one I really needed.
I recreated the directory structure on the target of the application and added a symlink to the build output directory of my project. The use of symlinks efforts to get the setup working without recurring maintenance.
The content of the sysroot didn't actually have to be identical to the target's remote files: The target had stripped libraries without debugging symbols, while I used the non-stripped libraries in the sysroot.
Cannot find tftp command in shell.efi app from Tianocore.
When type tftp, got 'tftp' is not recognized as an internal or external command, operable program, or batch file. Help also doesn't know about it.
I looked at sources and found it is implemented in DynamicCommand directory. Maybe command must be loaded or activated somehow before using?
Edit: well, the only way i found to get tftp client working on Tianocore shell is building ShellPkg from sources. There is DynamicCommand/TftpDynamicCommand subdirectory contains tftp application. It will produce tftp.efi on package building finished. "Manual" can be found here. Still dont understand how to make shell with built-in tftp command and why Tianocore maintainers do not include procompiled tftp.efi in ShellBinPkg for example.
How to Run OVMF article contain information on how to get pre-built OVMF images:
Pre-built images are available at https://www.kraxel.org/repos/
These images are automatically built and track the latest OVMF code in the EDK II tree.
Some of these builds include a seabios CSM and can boot non-UEFI “legacy” operating systems. Note: seabios is GPLv3 licensed)
If your OS doesn’t work with RPM repositories, then you can manually download and decompress the RPM files under jenkins/edk2
You can find the latest OVMF RPM packages at kraxel repository. They contain the latest firmware and UefiShell.iso to boot. You will find tftp command you need and other cool stuff there.
I updated my cygwin using the setup-x86_64.exe tool (version 2.873) on Windows 7.
I needed to install some additional packages (mostly zip/unzip etc).
Since then, I am getting the following errors when I try to run the Cygwin Terminal (the shortcut points to C:\cygwin64\bin\mintty.exe -i /Cygwin-Terminal.ico -):
Error: could not fork child process: Resource temporarily unavailable.
DLL rebasing may be required. See 'rebaseall / rebase --help'.
I searched online how to run the rebaseall command they advise in the message. Essentially the recommendation was to start cygwin/bin/dash.exe and run:
bin/rebaseall
I did that a few times, I also used the -v comment, and no errors come back. Still I can't start cygwin.
I also tried running cygwin-x/XWin-server nothing happens.
I looked at the setup logs in cygwin/var/log/setup.log I can't see any error.
I tried to run the setup program a few more times reinstalling some of the packages I already had, that didn't help neither.
Any ideas how can I get that to work?
Here is the fix.
Go to you Windows Defender Security Center settings
Click on App & Browser Control
At the bottom click on the "Exploit Protection Settings" link
Go to "Program Settings" and click on the "Add program to
customize" -> "Choose exact file path"
Navigate to "C:\Program Files\Git\usr\bin\sh.exe" and add it
Override and turn off the following: Mandatory ASLR, Randomize memory allocations (Bottom-up ASLR)
Click "Apply" and now everything should work fine.
Also add these other binaries from the same folder: expr.exe, uname.exe, grep.exe, rm.exe
Good luck,
Gabriel
One of my colleagues has similar errors when openening the terminal from SourceTree (Mingw32), and also got errors when trying to pull, rebase, etc (anything not local). He solved it by uninstalling Sourcetree, using CCleaner to clean his registries (not sure if this was required), rebooted and installed Sourcetree again.
I know this is slightly different from the problem described by the OP, but it might still be solvable by un/re-installing and cleaning of registries, and this might also help future people finding this question with the Sourcetree issue (like I did).
Edit:
Another colleague had the issue as well, and he managed to fix it merely with a restart without any un/re-installation or using CCleaner.
I've been suffering similar problems a lot recently. I've been unable to determine the cause, whether it's due to a recent Windows7 patch or an update in the latest cygwin. I'm in a tightly controlled corporate environment with only limited elevated rights, a lot of anti-malware and encrypted drives. I'm using 32-bit Cygwin at present.
Issues for me began after I installed Git and Git-Svn packages, which required Perl and upgraded various other Cygwin packages as well.
Rebasing using rebase-trigger or rebaseall did not solve the issue for me. Neither did re-installing and setup repeatedly raised errors in the post-install pahse when trying to do the rebase itself.
My first success was by downgrading Perl to the previous version, ie. down to 5.22.1.2 from 5.22.2.1. After a couple of weeks the error returned, perhaps after a compulsory windows update and reboot.
My latest success has been achieved by ignoring the dash/rebaseall script and running rebase.exe directly as follows:-
Create a file which lists all cygwin .dlls in the /bin directory except cygwin1.dll and cyglsa.dll ie.
$ cd /bin
$ ls -1 *.dll | egrep -v '(cygwin1|cyglsa).*\.dll' >rebasedlls.txt
Close all cygwin terminals, if you have any services running which use cygwin ensure that those are stopped also. Check TaskManager and kill processes if necessary.
Open a cmd.exe window (it may help to use whatever elevated rights you can muster), change to the windows path of your cygwin /bin directory (ie. the windows directory of cygpath -wa /bin).
Use rebase.exe directly to find the base address of the cygwin1.dll file:
C:\apps\cygwin\bin> rebase.exe --info cygwin1.dll
/usr/bin/cygwin1.dll base 0x61000000 size 0x00500000
Using that base address and the size as a guide I chose the next whole value up as my rebase base address, 0x62000000. No particular reason for this, just a hunch. (The rebaseall script uses 0x70000000).
Use rebase.exe to fix all the .dlls listed in the file from step (1):
C:\apps\cygwin\bin> rebase -b 0x62000000 -4 -n -v -t -T rebasedlls.txt
So far, so good, my Cygwin is back to a working state again.
From https://chromium.googlesource.com/chromium/src/+/master/docs/cygwin_dll_remapping_failure.md
Handling repeated failures of rebaseall to allow cygwin remaps
Sometimes DLLs over which cygwin has no control get mapped into cygwin
processes at locations that cygwin has chosen for its libraries.
This has been seen primarily with anti-virus DLLs. When this occurs,
cygwin must be instructed during the rebase to avoid the area of
memory where that DLL is mapped.
Background
Some background for this is available on
http://www.dont-panic.cc/capi/2007/10/29/git-svn-fails-with-fatal-error-unable-to-remap/
Because of unix fork semantics (presumably), cygwin libraries must be
mapped in the same location in both parent and child of a fork. All
cygwin libraries have hints in them as to where they should be mapped
in a processes address space; if those hints are followed, each
library will be mapped in the same location in both address spaces.
However, Windows is perfectly happy mapping a DLL anywhere in the
address space; the hint is not considered controlling. The remapping
error occurs when a cygwin process starts and one of its libraries
cannot be mapped to the location specified by its hint.
/usr/bin/rebaseall changes the DLL hints for all of the cygwin
libraries so that there are no inter-library conflicts; it does this
by choosing a contiguous but not overlapping library layout starting
at a base address and working down. This process makes sure there are
no intra-cygwin conflicts, but cannot deal with conflicts with
external DLLs that are in cygwin process address spaces
(e.g. anti-virus DLLs).
To handle this case, you need to figure out what the problematic
non-cygwin library is, where it is in the address space, and do the
rebase all so that no cygwin hints map libraries to that location.
Details
Download the ListDLLs executable from
sysinternals
Run it as administrator while some cygwin commands are running.
Scan the output for the cygwin process (identifiable by the command) and for
DLLs in that process that do not look like cygwin DLLs (like an AV). Note
the location of those libraries (there will usually only be the one).
Pick an address space location lower than its starting address.
Quit all cygwin processes.
Run a windows command shell as administrator
cd in \cygwin\bin
Run ash /usr/bin/rebaseall -b <base address> (This command can also take a
-v flag if you want to see the DLL layout.)
That should fix the problem.
Failed rebaseall
If you pick a base address that is too low, you may end up with a broken cygwin
install. You can reinstall it by running cygwin's setup.exe again, and on the
package selection page, clicking the "All" entry to Reinstall. You may have to
do this twice, as you may get errors on the first reinstall pass.
I have Administrator access to my PC. For me the solution to this was to run the Cygwin session as Administrator -- right the icon, run as administrator, as shown here:
After running as Administrator the first time, new Cygwin sessions started up without hassle.
There is a rebase utility that triggers the rebase as post-setup phase.
From dash or bash:
/usr/bin/rebase-trigger full
close all process and run again setup-x86_64.exe.
uninstall it,
and install the software for 32-bit.
I restarted 3 times, and then it was fine. wtf Windows 7
This exact same error message has various causes, not all of them related to setup-x86_64.exe, although I have seen it in that context as well. But if rebaseall didn't fix your problem, here's a suggestion that might work.
In the case I saw this morning, it turned out to have been caused by having a couple of processes that continued to run after I exited the mintty terminal emulator. My hunch is that these zombie processes prevent the console from being recycled. In my case, the two processes were determined experimentally, by reviewing a list of running processes for stray processes that are no longer needed. I found the two processes that were blocking me by reviewing the list of running tasks.
C:\WINDOWS\system32>tasklist | grep Console
CobraWinLDTP.exe 31844 Console 1 43,600 K
geckodriver.exe 52640 Console 1 32,164 K
C:\WINDOWS\system32>taskkill /F /PID 31844
SUCCESS: The process with PID 31844 has been terminated.
C:\WINDOWS\system32>taskkill /F /PID 52640
SUCCESS: The process with PID 52640 has been terminated.
I saw on some other stackoverflow questions that git is often the zombie process that causes this symptom (for some users). Unfortunately, any residual process that survives after your console session is closed can cause this problem, so you have to experiment.
Go to The Task manager
Kill 'Git for Windows' process
Reopen your git bash
It seems that all is working fine.
NOTE: In case you don't find 'Git for Windows' process and still have to face the same just kill 'Node.js: Server-side JavaScript' process instead
If you have turned Force randomization for images (Mandatory ASLR) on in Exploit protection of Windows Security, then you can turn it off by selecting Use default (Off) to address this issue.
My instance of this problem was also related to having turned on 'force randomization for images' in the Windows Security exploit protection settings.
After you change the setting back to the default off position and reset, you will have to run Git as an administrator in order to effect directory changes which apparently require elevated permission.
I wasn't able to determine a way to allow that setting to be turned on and not get this issue with Git though I played around with it for a while unsuccessfully.
Turning even optional security features off to get a single program working seems like a last resort option to me. However, this isn't just any program either.
I followed this install wget tutorial,
After I ran this
./configure --with-ssl=openssl
It ran so many checks, what exactly it did? Did it change anything in my system?
If it does, then, is it safer or more fault prove to use the package management tool like MacPort or such so that such 'configure' will not be done manually like this or does those tool do the same thing in order to make wget work?
Sorry, I am pretty noob on shell commands.
Thanks
It's part of the build process. The configure script collects information about your system and build options into a local file, nothing more.
Typically, this script is created by autoconf and is used to figure out whether the prerequisites for a build are properly installed, etc. It will collect this into a file config.save and also possibly generate a makefile and/or other build infrastructure in order for make to be able to concentrate on compiling and linking the source files.
Neither configure nor make should be expected to change anything outside of the directory tree where you run them.
Conventionally, make install will copy the final build artefacts into place so that other parts of your system can find them and use them.
See also http://www.edwardrosten.com/code/autoconf/
A prepackaged binary will already have been built on a remote system before it was packaged (though there are package managers which allow or require you to build locally; Gentoo Linux famously uses the latter approach) and is often the simplest way to get a tool if you don't have special requirements, such as building with a specific SSL version, or disabling SSL entirely, or getting a bleeding edge version before anybody has packaged it.
I have followed the instructions for debugging native code found here:
http://www.eweek.com/c/a/Linux-and-Open-Source/How-to-Set-Up-Android-Platform-Development-and-Debugging/
To do this, you have to launch gdbserver from an adb shell. I have copied gdbserver to the target filesystem, but can't make it executable (chmod gives permissions errors or 'bad mode' errors).
Do I need to root my device to start gdbserver? (How??)
Do I need to copy gdbserver manually?
Is there an easier way to do this? This is turning into a black hole of productivity. All I want to do is debug my jni code...
TIA for any help.
First of all, /sdcard is mounted with 'noexec' option. Thus, you cannot execute any executable file from /sdcard. You have to put gdbserver to an another file system, like /data/local/tmp.
Second, if you are developing it as an Android application, gdbserver requires proper permission to attach the target process for debug. There are two ways for that. Using run-as or getting root.
Please take a look at Running ndk-gdb with package not found error on motorola phone.