I built the latest glibc and now i'm having some trouble with functions in coreutils like ls or cat or anything else like vim.
My error is
-bash-4.0$ cat
cat: error while loading shared libraries: __vdso_time: invalid mode for dlopen(): Invalid argument
and I built, glibc without errors with the following configure
../glibc/configure --prefix=/home/ex/uid377/glibbuilt
On older versions, like 2.14, running the utilities results in a segmentation fault.
-bash-4.0$ ./pwd
./pwd: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by ./pwd)
-bash-4.0$ LD_LIBRARY_PATH=/home/ex/uid377/glibc/lib/:${LD_LIBRARY_PATH}
-bash-4.0$ ./pwd
Segmentation fault (core dumped)
Edit
Kernel Version
-bash-4.0$ uname -r
2.6.32.26-175.fc12.x86_64
Having multiple versions of glibc on a single system is possible, but slightly tricky, as explained in this answer. In particular, this:
LD_LIBRARY_PATH=/home/ex/uid377/glibc/lib/:${LD_LIBRARY_PATH}
is expected to crash, because your ld-linux-x86-64.so.2 will not match your libc.so.6
cat: error while loading shared libraries: __vdso_time: invalid mode for dlopen(): ...
It's not clear how you built this cat, but it's most likely the exact same problem: you are picking some libraries from /lib64, and some from /home/ex/uid377/glibc/lib. Don't do that. You must link all the programs that will use /home/ex/uid377/glibc/lib/libc.so.6 with -Wl,--dynamic-linker=/home/ex/uid377/glibc/lib/ld-linux-x86-64.so.2.
You can trace which libraries are currently being loaded by running:
env LD_DEBUG=files,libs ./cat
Related
I am having trouble getting the debugger to work properly when setting up clang on my Windows 10 machine. Compilation seems to work OK, at least for the simple "hello, world" program I tried. However, when I try to run the lldb or gdb debuggers on this test program (or any other program I tried), it does not recognize function names.
Here's my C program code:
#include <stdio.h>
int main(void) {
puts("Hello, world!");
return 0;
}
Nothing too spectacular here, I know. I'm compiling with the following command:
> clang -g -O0 hello.c -o hello.exe
I then try to run the debugger:
> lldb hello
(lldb) target create "hello"
Current executable set to 'hello' (x86_64).
(lldb) b main
Breakpoint 1: no locations (pending).
WARNING: Unable to resolve breakpoint to any actual locations.
(lldb) r
Process 12156 launched: 'C:\Users\********\Projects\clang-test\hello.exe' (x86_64)
Process 12156 exited with status = 0 (0x00000000)
(lldb)
Apparently the symbol "main" was not recognized, and the program did not halt at the start of the "main" function but ran to completion (in a different console window, hence no program output here).
How do I get debugging symbols to work? In a different stackoverflow answer I found that adding compiler options "-g -O0" should do the trick, but as you can see that does not solve the problem for me. I also found a different stackoverflow answer about how to set up debugging if the code is not in the same directory as the executable, but that is not relevant to my case: the current working directory is the same as the directory with the code and executable in them.
Some version information:
> clang --version
clang version 9.0.0 (tags/RELEASE_900/final)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files\LLVM\bin
> lldb --version
lldb version 9.0.0
The "-g -O0" options you provided should indeed let the debugger know all the symbols it needs from the executable.
Therefore, I suspect the problem is elsewhere, perhaps with your terminal, or your version/implementation of LLDB.
Are you using the windows cmd.exe commandline ? or something else, like Powershell ?
I've never managed to get debuggers working properly in those environments, but it was much easier with Cygwin, which is a bash shell for windows (it creates a "simulated" linux environment within its install folder, so you have all the /usr,/bin,/etc folders a bash shell needs)
This way you can actually use gdb the way you would on a UNIX system.
If the above method sounds like more of a hassle than a time-gain, then yeah I would recommend another debugger altogether, like the Visual Studio debugger.
In fact, maybe a memory-analysis tool like Dr.Memory can give you what you need
I use gdb (ddd) to debug my C/C++ projects.
Whenever an assert fails, I can debug the program as normal and backtrace to the assert which failed, but first I get an annoying popup
I assume raise.c defines assert, but ddd is looking within my home directory instead of /usr/... or something like that.
I may or may not have the debugging packages installed (I'm on Ubuntu), but the main question is: why is gdb looking within $HOME for this source?
Since the glibc debuginfo package libc6-dbg is installed on your system, gdb will look in /usr/lib/debug/lib/x86_64-linux-gnu/libc-2.23.so to map instruction addresses into source file names and line numbers.
The section of that file that contains the info for __GI_raise has the following attributes that indicate where the source code might be found (on Ubuntu 16.04):
<0><688bd>: Abbrev Number: 1 (DW_TAG_compile_unit)
<688c3> DW_AT_name : (indirect string, offset: 0x9137): ../sysdeps/unix/sysv/linux/raise.c
<688c7> DW_AT_comp_dir : (indirect string, offset: 0x9010): /build/glibc-Cl5G7W/glibc-2.23/signal
Ubuntu doesn't ship source code in the base distribution, so your system doesn't have any glibc source in /build/glibc-Cl5G7W/glibc-2.23, so gdb looks (unsuccessfully) for raise.c in a few other directories according to its rules Specifying Source Directories and eventually gives up, with the error message
54 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
Then, ddd calls SourceView::full_path("../sysdeps/unix/sysv/linux/raise.c") to canonicalize the pathname, taking your working directory into account, and displays the error dialog box in your question.
See GDB complaining about missing raise.c for how to install glibc source on Ubuntu.
I'm trying to count the syscalls in my Go program on OS X Yosemite. I've tried using dtruss and dtrace, but both cause my program to crash with the following error, followed by a stack trace:
fatal error: runtime: bsdthread_register error
The two commands I've used are:
sudo dtruss "./my_program my_arg"
sudo dtrace -c "powerset 2" -n 'syscall:::entry { #num[probefunc] = count(); }'
Things I've Tried
The main takeaway from my Google-foo has been to unset DYLD_INSERT_LIBRARIES, which I have done numerous times to no avail.
./my_program is a binary that I created with go install. I've written an equivalent C program and both of the above commands work fine with that.
If you want to use dtrace on macOS, you will need to use the external linker to build your program
-ldflags -linkmode=external
I am trying to modify the dynamic linker provided in the libc6(2.15-0ubuntu20.2) on a 64 bit Ubuntu machine.
So currently my code is using the same version of the glibc library. (I have downloaded the source code for the same and working on it). My question is that is it possible to modify and build only the linker source code which is present in glibc\elf\ directory without building the entire glibc library.
And if it is possible how can I make my test program to switch using the new version of dynamic linker that I have build myself instead of using the default unmodified linker.
Any pointers or suggestions are highly appreciated.
(If any more information is needed please let me know)
EDIT::
#constantius
I followed the steps in the post linked by you to build ld.so.
But I am getting following error on the make and I checked ld.so is not there in the elf.
The error is::
/var/services/homes/abhi/test/ld/eglibc-build/elf/librtld.os: In function `generic_getcwd':
/var/services/homes/abhi/test/ld/eglibc-2.15/elf/../sysdeps/posix/getcwd.c:356: undefined reference to `__closedir'
/var/services/homes/abhi/test/ld/eglibc-2.15/elf/../sysdeps/posix/getcwd.c:368: undefined reference to `__fdopendir'
/var/services/homes/abhi/test/ld/eglibc-2.15/elf/../sysdeps/posix/getcwd.c:384: undefined reference to `__readdir'
/var/services/homes/abhi/test/ld/eglibc-2.15/elf/../sysdeps/posix/getcwd.c:397: undefined reference to `rewinddir'
/var/services/homes/abhi/test/ld/eglibc-2.15/elf/../sysdeps/posix/getcwd.c:528: undefined reference to `__closedir'
/var/services/homes/abhi/test/ld/eglibc-2.15/elf/../sysdeps/posix/getcwd.c:490: undefined reference to `__closedir'
collect2: error: ld returned 1 exit status
make[2]: *** [/var/services/homes/abhi/test/ld/eglibc-build/elf/ld.so] Error 1
make[2]: Leaving directory `/var/services/homes/abhi/test/ld/eglibc-2.15/elf'
make[1]: *** [elf/subdir_lib] Error 2
make[1]: Leaving directory `/var/services/homes/abhi/test/ld/eglibc-2.15'
make: *** [all] Error 2
NOTE With the same infrastructure I can build and install the full GLIBC so I dont think there is an error with the infrastructure.
-- I guess the error is some where related to editing Makeconfig to all-subdirs = csu elf gmon io misc posix setjmp signal stdlib string time.
--Any suggestions on this..
SOLVED
Need to add dirent in the all-subdirs list in addition to what we edited before
Thanks
Citing this page. In case you don't get something, comment please — I'll try to explain.
Building
To compile Glibc (ld.so cannot be compiled independently) download and unpack Glibc source tarball.
1 Make sure the version of Glibc you downloaded is the same as the system's current one.
2 Make sure the environmental variable LD_RUN_PATH is not set.
3 Read the INSTALL and make sure all necessary tool chains (Make, Binutils, etc) are up-to-date.
4 Make sure the file system you are doing the compilation is case sensitive, or you will see weird errors like
/scratch/elf/librtld.os: In function `process_envvars':
/tmp/glibc-2.x.y/elf/rtld.c:2718: undefined reference to `__open'
...
5 ld.so should be compiled with the optimization flag on (-O2 is the default). Failing to do so will end up with weird errors (see Question 1.23 in FAQ)
6 Suppose Glibc is unpacked at
/tmp/glibc-2.x.y/
Then edit /tmp/glibc-2.x.y/Makefile.in: Un-comment the line
# PARALLELMFLAGS = -j 4
and change 4 to an appropriate number.
7 Since we are only interested in ld.so and not the whole Glibc, we only want to build the essential source files needed by ld.so. To do so, edit /tmp/glibc-2.x.y/Makeconfig: Find the line started with
all-subdirs = csu assert ctype locale intl catgets math setjmp signal \
...
and change it to
all-subdirs = csu elf gmon io misc posix setjmp signal stdlib string time
8 Find a scratch directory, say /scratch. Then
$ cd /scratch
$ /tmp/glibc-2.x.y/configure --prefix=/scratch --disable-profile
$ gmake
Since we are not building the entire Glibc, when the gmake stops (probably with some errors), check if /scratch/elf/ld.so exists or not.
ld.so is a static binary, which means it has its own implementation of standard C routines (e.g. memcpy, strcmp, etc) It has its own printf-like routine called _dl_debug_printf.
Testing
You can run the ld-linux.so directly. It will complain that this is probably not what you want (but you want exactly this) and offer you list of options with which you can run it. See also man ld-linux.so for debugging flags, i.e. there's LD_DEBUG environment variable you can define to see ld-linux.so debugging output.
While I'm not clear on whether the build system for glibc makes doing this easy, there's no fundamental reason why you can't build and use the glibc dynamic linker without building libc.so. I would peruse the top-level Makefile for ways to make this work.
As for testing it, there are two methods:
Explicitly invoke the dynamic linker to run a program, as in:
./ld-linux.so.2 a.out args ...
When linking your program, specify an alternate dynamic linker pathname (which will get stored in its PT_INTERP program header) by passing this option to the compiler driver:
-Wl,-dynamic-linker,/path/to/alternate/ld-linux.so.2
I have compiled my own glibc, which produced libc.so. I loaded the libc.so file in gdb by doing gdb -q ./libc.so. However, when I try to find the location of a function by doing list function_name, I get the error message, No line number known for function_name. Note that I use the -g flag for compiling glibc. How can I solve this problem?
Can you even debug a .so by itself? What I would try is to do is gdb executable_using_my_libc. Then this should load glibc and so on.