i am using gcc 4.4.3 on ubuntu 10.4 32bit machine.
i use 'gdb' to debug my code. Since few days i am seeing that whenever i debug code gdb steps into the c library functions used in the code also(like printf,fgets etc). This shows a long list of calls from one function to other.see the attached screen shot.
Previously gdb was working fine just stepping over my own code.
Maybe i am being novice !! But it is sometimes really irritating when gdb shows me numerous lines which i am not interested in the present context.
If someone can guide me as in how to turn off/on this feature and what can be cause of it being switched on on its own(i don't remember doing anything).
Many thanks.
i used to do that previously also but then it never went into any of the lib functions
You (or someone) have installed libc6-dbg package. Before that, GDB couldn't step into libc functions, because they didn't have any debug info. Now they do, and it can.
Either get out of the habit of typing step when you want next, or un-install libc6-dbg.
Related
Recently I upgraded up to Ubuntu 16.04.1 Xenial (from 14.04 Trusty) the build-host where I've compiled different linux kernels so far for my own project. Ubuntu 16.04.1 implies using a new updated environment for building binaries. These tools include a new gcc-5.4, libc6 (for userspace applications), etc. Also a new Ubuntu supplies (or suggests) a new kernel-package containing a new make-kpkg script and pulling different dependencies like build-essential, binutils, etc. with it
Ok, my task is to compile a linux kernel v3.10.12 (or v3.19) and run it within a VirtualBox machine (architecture x86_64, system Ubuntu 16.04.1). I used to be able to compile kernel-v3.10.12 and kernel-v3.19 in Ubuntu 14.04 Trusty deployed on the build server with the compiler gcc-4.8 and launch the kernels under the VirtualBox machine I mentioned above, but now something goes wrong while starting a kernel compiled
For example, let's consider v3.10.12 being compiled and run
For building the kernel I utilize 'make-kpkg' script provided by Ubuntu aptitude's package 'kernel-package'. I build the kernel for x86_64 using gcc-4.8 as I have always been doing
Once 'make-kpkg' has compiled the kernel and gathered linux-headers it starts packing them into deb-packages what makes me able to execute 'dpkg -i' on them in the system and install them in a 'debian' way
Okey, supposing I did it. Then I am going to reboot the system
When I choose my compiled kernel in the grub menu, it writes in the screen "Loading linux kernel... Loading initial ramdisk", then the inscription disappears, the screen goes black and I see only a cursor in the form of underscore "_" sign in the top-left side of the screen. That's all. Nothing is going to happen further. The booting process seems to have stuck
I tried swapping make-kpkg for an old one (from Trusty), swapping compiler gcc-4.8.5 for gcc-4.9, gcc-4.7, even gcc-5.2 having made a couple of supplementations inside the directory include/linux/ for the support of gcc-5.2, but nothing has come off, the result still persists being the same
I tried the same actions (on the same Ubuntu 16.04.1 and tool-chain) with new kernels 4. series* (for example, 4.6) meaning building the kernels, packing them into *.deb packages and installing into the VirtualBox machine and rebooting the system, and everything goes correctly, I see debug messages in the screen like I have always seen. I tried to use gcc-4.7, gcc-4.8, gcc-4.9, gcc-5.4 and everything works, I am able to load the linux-kernel-v4.6 appropriately and completely. But when I build 3.10.12 (or 3.19) kernels I cannot boot them properly and cannot have figured out why it has been happening
Actually, what I have found out is that the deal is in the kernel but not in initrd because I managed to substitute the 'broken' kernel by a working one having left 'initrd' built together with the 'broken' kernel and the debug logging started appearing and the kernel was loading until a rootfs came out to be mounted, at that moment the kernel didn't manage to load it and left in initramfs mode
Has someone faced the same issue I am observing? Actually I am almost exhausted having been struggling with this trouble for days
Maybe someone has any recipes or suggestion how to get rid of the problem?
I even put the 'panic' function code exactly in the first line of the function "asmlinkage void __init start_kernel(void)" but nothing happened, still the same black screen
Can the problem be related to a new glibc being used by gcc compiling my kernel? Personally, I am not prone to think so but in the world of linux everything can happen. On the other hand maybe toolchain (ld, as) somehow has affected? I am kindly asking to provide me a help.
I am nearly assured that someone before me has already encountered such an issue, I would have been searching for a topic alike but didn't find anything resembling
Thank you in advance
Short Answer
It's a glibc kernel version mismatch, if you need this you could create the glibc package such that it supports the kernel version that you need, by using the --enable-kernel flag at configuration time.
Long Answer
It's highly likely that your glibc was compiled in such a way that it only works down to a certain version of linux. This is done with the help of the --enable-kernel flag at the configuration stage. Any version older than the one specified in --enable-kernel will be rejected by glibc as a consequence no program will ever be loaded, like the init program presumably systemd's init.
This is from the configuration help of glibc
--enable-kernel=version
This option is currently only
useful on GNU/Linux systems. The version parameter should have the form X.Y.Z and describes the smallest version of the Linux kernel the generated library is expected to support. The higher the version number is, the less compatibility code is added, and the faster the code gets.
Finally I succeeded in this problem
Actually what I have done is to have compiled an old gcc-4.8.5 with an old glibc-2.19 on the host-system where I build the old-versioned kernels.
Glibc-2.19 was compiled with an option --enable-kernel=3.10.12 and with headers of an old-versioned linux-3.10.12. The compiler has turned out to be like a 'cross-compiler' with usage of glibc-2.19. So, I built an old kernel with the version 3.10.12 with this 'cross-compiler', which uses glibc-2.19, and everything has started working in a proper way
Thanks for the help and directing me to a right way to solve the problem, but I am obliged to notice that the deal was in host-system's glibc used but not in target-system glibc used as I had been assumedly said (but maybe I misunderstood #iharob)
I need to debug a C program that includes posix threads, socket programming (udp client, server). I use ubuntu 12.04 and as IDE/SDK, Qt Creator 2.4.1 and Netbeans IDE 7.1.2. I know they use gdb for debugging.
When I start to debug my program, the program stops running after 5 min or so and neither Qt Creator or Netbeans output any error or warning, although I use debugging feature and my program suppose to listen for a UDP port.
I use printf for all line of my code, and I can see that my program works as it suppose to and listen the UDP port and waits. I can not figure the problem out why it stops without any reason and since IDEs that I am using do not show any debug error, warning, I can not think any reason.
I wonder if anyone can suggest me a debug program that monitors all/some variables and threads during the run time. Thank you.
An old, but reliable tool is ddd, which is basically the gdb GUI wrapper. Although, I usually do debugging directly with Emacs, ddd is the tool that you'll be able to run on almost all *nix platforms.
gdb isn't too comfortable but always available.
To do runtime analysis of different types, especially checking memory access, Valgrind (see here for docs) might be the tool of choice.
Update: I'm referring to *IX systems. For Windows gbd also works in the cygwin enviroment. Nativly there is VC Express, which is free and includes IDE and debugger.
I'm not quite sure what debugger is used for your kind of application. The only debugger I know about on Linux is gdb. It along with printf statements is all I need.
gdb is simple, though not "too comfortable" as #alk said, but seems to be ubiquitous.
There is also Eclipse, and that's quite a nice development and debugging platform, too.
I am using c in eclipse to write a program. I need to use GDB to debug it step by step. However on a longjmp command (when i try to save the context of a stack) GDB crashes inside eclipse (because there is a breakpoint there?) Is there any way around this? I have scoured the internets for the past six hours and cannot seem to be able to find a solution. Here is the line of code where it is crashing
if(setjmp(p->jbContext) == 0)
longjmp(context_buf,1);
I would be very very grateful to anyone that can help.
Thanks!
EDIT: After further searching I found this webpage but have no clue as to how to use it.
http://www.delorie.com/gnu/docs/gdb/gdb_271.html
Assistance would be appreciated!
If it is really gdb which crashes, you could consider (after reporting the bug to them) install a newer version of it. Latest GDB is version 7.3.1 -you can compile it from its source code if needed. If you are brave and the bug persists with the latest version, try to find the bug and propose a patch.
My experience with gdb crashes (which are rare) is that getting and building the newest version helps a lot. Many Linux distributions don't ship a very recent GDB.
Of course, you might need to upgrade your GCC compiler also: the debugging information that is generated has also improved.
I was trying to compile the Linux kernel.
I am getting the following error:-
"No rule to make target arch/x86/kernel/entry_32.o', needed byarch/x86/kernel/built-in.o'."
Before this I configured the kernel(didn't do anything extra except the default options).
configured the kernel using "make gconfig". The config was generated. I am using x86 32 bit machine (Fedora 9) kernel version 2.6.30.
Finally I used :-
"make bzImage"
to compile.
Tried to search the net for a solution but without success.
How to fix these errors??
Kindly help.
Thanks,
Sourabh
You need to call make before make bzImage.
make clean or make mrproper would perhaps help too depending how much you screwed up already.
I agree with the previous answer, you should take a look at how to compile a kernel, the fedora way (here). Not sure this is still up-to-date, but leveraging the provided tools is a good idea sometimes.
Maybe you didn't actually configure the kernel. Did you use any of "make config", "make menuconfig", "make xconfig"?
Are you running an x86 distribution or an x86_64 one? In the latter case, you need the x86 32 bits compilation environment too.
Advice : this is a poorly asked question. You didn't give any relevant information : Linux distribution and architecture, kernel version you want to compile, the commands you tried and the messages you got.
I have learned C and I would like to start to improve open source software. I would like to hack away one irritating bug in GTK+. To see the bug I need to use Gedit.
How can I download the sources of GTK+ and gedit and compile both of them so that I can see where the bug is? And I have never used any debugger in Linux so is there somewhere a tutorial for that?
You can get information about downloading and compiling of gedit here:
http://projects.gnome.org/gedit/developers.html
My Debugger of choice is GDB:
http://www.gnu.org/software/gdb/
GDB is a console application that may be hard to handle for a beginner. Try an IDE like Eclipse that provides a GUI to GDB.
Almost all Linux debuggers are front-ends for or adaptations of the gdb debugger. You should therefore learn how to use this first, preferably by starting on
small programs of your own construction, not giant FOSS codebases. The gdb manual,
available from here is actually a pretty good tutorial.
The information on building and installing GTK+ should be here:
http://www.gtk.org/development.html
The sources should be here:
http://www.gtk.org/download-linux.html
You can check out gdb:
http://www.gnu.org/software/gdb/ That's a pretty standard linux debugger. I would spend time with it on something simple first, or get an IDE that uses it. Learning gdb can be worth the time though.
gdb is a dinosaur which should long since have been made extinct. Debugging is one area where (gasp!) Windows beats Unix. Having got that off my chest, I advise you to start with the Data Display Debugger (DDD) graphical front end to gdb. Yes, the GUI is quaint, but you will be far more productive, quicker, than if you start with gdb.
Also don't overlook valgrind for finding and diagnosing memory errors. The KDE project actually mandates use of valgrind; I'm not sure about Gnome.
It is possible that you won't see the bug if you download the latest gedit and gtk+ sources. It might be fixed in the latest sources or the latest sources might be different enough to not trigger your bug.
What Linux distribution are you running?
First of all I'd suggest consulting your distribution's bug database to see if someone has filed a similar bug. If you don't find anything, I'd suggest using your distribution's tools to obtain the source that corresponds to the binary that you have installed on your sytem (e.g. apt-get source libgtk-2.0 on Debian or Ubuntu).
Also, your distribution might also make a debug package available (e.g. libgtk2.0-0-dbg on Debian) which will let you run a debugger on the binary that you already have without requiring the source. While this is no substitute for having the sources, it can be useful for running valgrind or making sense out of a core file.