I use the command make rpm-pkg to build debuginfo rpm for kernel(4.19.1), but it didn't work.so I tried to remove #%debug_package{null} in the scripts/package/mkspec and add find_debuginfo.sh xxxx to enable debug module，but after I run the command make rpm-pkg again, I got the debuginfo rpm but it seems abnormal。 the size of the rpm is around 600k which is obviously not correct.
also i found all the 3.10.x version of kernel has the --with=debuginfo parameter to enable the debug module, which is also not work in 4.19.1 version. so i would like to know whether there is any other approach that build the debuginfo rpm.
Related
If you have an answer for this, or further information, I'd welcome it. I'm following advice from here, to offer some unsolicited help by posting this question then an answer I've already found for it.
I have a bare-metal ARM board for which I'm building a cross-toolchain, from sources for GNU binutils, gcc and gdb, and for SourceWare's Newlib. I got those four working and cross-built a DoNothing.c into an ELF file - but I couldn't disassemble it with this:
$ arm-none-eabi-objdump -S DoNothing.elf
The error was:
$ arm-none-eabi-objdump: error while loading shared libraries: libdebuginfod.so.1: cannot open shared object file: No such file or directory
I'll follow up with a solution.
The error was correct - my system didn't have libdebuginfod.so.1 installed - but I have another cross-binutils, installed from binary for a different target, and its objdump -S works fine on the same host. Why would one build of objdump complain about missing that shared library, when clearly not all builds of objdump need it?
First I tried rebuilding cross binutils, specifying --without-debuginfod as a configure option. No change, which seems odd: surely that should build tools that not only don't use debuginfod but which don't depend on it in any way. (If someone can answer that, or point out what I've misunderstood, it may help people.)
Next I figured debuginfod was inescapable (for my cross-tools built from source at least), so I'd install it to get rid of the error. It's a component of the elfutils package, but installing the latest elfutils available for my Ubuntu 20.04 system didn't bring libdebuginfod.so.1 with it.
I found a later one, for Arch Linux, whose package contents suggested it would - but its package format doesn't match Ubuntu's and installing it was going to involve a lot of work. Instead I opted to build it from the Arch Linux source package. However, running ./configure on that gave a couple of infuriatingly similar errors:
configure: checking libdebuginfod dependencies, --disable-libdebuginfod or --enable-libdebuginfo=dummy to skip
...
configure: error: dependencies not found, use --disable-libdebuginfod to disable or --enable-libdebuginfod=dummy to build a (bootstrap) dummy library.
No combination of those suggestions would allow configure for elfutils-0.182 to run to completion.
The problem of course was my own lack of understanding. The solution came from the Linux From Scratch project: what worked was to issue configure with both of the suggested options, like this:
$ ./configure --prefix=/usr \
--disable-debuginfod \
--enable-libdebuginfod=dummy \
--libdir=/lib
That gave a clean configure; make worked first time, as did make check and then sudo make install which of course installed libdebuginfod.so.1 as required. I then had an arm-none-eabi-objdump which disassembles cross-compiled ELF files without complaining.
I'm trying to get libc on OpenWrt as a package, but I can't seem to find it in any of the repositories. I am only able to find the .ipk here.
How do I get it on my configuration as I'm compiling it instead of using opkg?
I am not sure that I correctly understand your question.
If you are compiling the Openwrt, the .ipk should be under <buildroot/bin>. If you would like to just download it, please select the right architecture, for example using ar71xx use the link below: ar71xx - 15.05.1
On the other hand I cant imagine a system without libc installed, please type the following:
opkg list-installed | grep libc
Download the OpenWrt SDK.
Update and install the packages.
cd ~/OpenWrt-SDK-15...
./scripts/feeds update -a
./scripts/feeds install -a
Compile the libc package
make package/libc/compile -j1 V=s
Find it in bin/packages/...
If it fails find the libc package for OpenWrt and copy to /feeds/packages/libs. Update the package by typing ./scripts/feeds/update -i && ./scripts/feeds/install libc and go to the step 4 again.
I am building my own kernel with following options set.
CONFIG_FRAME_POINTER=y
CONFIG_DEBUG_INFO=y
So I assume that the generated vmlinux file will have all the required debuginfo.
I installed that kernel in a machine and put the vmlinux file under /boot/.
However, when I tried to do a perf annotate it does not show the source code along side the assembly code. It only shows the assembly code and c function names not the entire source code(I have tried toggling "s" during annotate).
Here are my perf commands.
#perf record -g -a -e cycles:k sleep 5
#perf report -f -g -s symbol
#perf annotate -f -s <kernel function name> > annotate_<kernel_function>.txt
What am I missing here ? Do I need to install debuginfo packages separately ?
Regards,
Atish
The binrpm-pkg target to build kernel rpm does not generate debuginfo because it disabled generation of debuginfo packages, you can try do this, open scripts/package/mkspec in your kernel source tree, and search for a line echo "%define debug_package %{nil}", comment or remove this line, and try to build again.
The reason is that this line explicitly tell rpmbuild that skip debuginfo packages.
See the link:
https://github.com/torvalds/linux/blob/9256d5a308c95a50c6e85d682492ae1f86a70f9b/scripts/package/mkspec#L45
I build Fedora Linux kernel (rpmbuild -bb --target=`uname -m` kernel.spec) according to this guide, and now I have among others:
kernel-debug-debuginfo-3.18.6-100.myself.fc20.x86_64.rpm (~360MB)
kernel-debuginfo-3.18.6-100.myself.fc20.x86_64.rpm (~360MB)
kernel-debuginfo-common-x86_64-3.18.6-100.myself.fc20.x86_64.rpm (~51MB)
kernel-debug-3.18.6-100.myself.fc20.x86_64.rpm (~67MB)
kernel-debug-devel-3.18.6-100.pae_sw_tal.fc20.x86_64.rpm (~10MB)
some others...
What's the difference between them and which one should I install if I want a development (debug-able build) version?
Basically you can find following information on rpmfind.net
just put kernel-debug-debuginfo in the search and it will tell you what it is.
Similarly for other packages.
for e.g.
kernel-debug-debuginfo-3.18.6-100.myself.fc20.x86_64.rpm
This package provides debug information for package kernel-debug. This is required to use SystemTap with kernel-debug-3.18.6-100.myself.fc20.x86_64.rpm
And I think you need kernel-debug-3.18.6-100.myself.fc20.x86_64.rpm (~67MB)
look at the options of rpmbuild for creating less files. Options like --without devel --without debuginfo
I'm trying to install gcc4.9 on a SUSE system without an internet connection. I compiled gcc on an Ubuntu machine and installed it into a prefix, then copied the prefix folder to the SUSE machine. When I tried to run it gcc complained about not finding GLIBC_2_14, so I downloaded an rpm for libc6 online and included it into the prefix folders. my LD_LIBRARY_PATH includes prefix/lib and prefix/lib64. When I try to run any program now (ls, cp, cat, etc) I get the error error while loading shared libraries: /home/***/prefix/lib64/libc.so.6: unexpected reloc type 0x25.
Is there any way I can fix this so that I can get gcc4.9 up and running on this system?
As an alternative, is it possible to build gcc staticaly so that I don't have to worry about linking at all when I transfer it between computers?
my LD_LIBRARY_PATH includes prefix/lib and prefix/lib64
See this answer for explanation of why this can't work.
Is there any way I can fix this so that I can get gcc4.9 up and running on this system?
Your best bet is to install whatever GCC package comes with the SuSE system, then use that GCC to configure and install gcc-4.9 on it.
If for some reason you can't do that, this answer has some of the ways in which you can build gcc-4.9 on a newer system and have it still work on an older one.
is it possible to build gcc staticaly so that I don't have to worry about linking at all when I transfer it between computers?
Contrary to popular belief, fully-static binaries are generally less portable then dynamic ones on Linux.