From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3553 invoked by alias); 14 Jan 2016 21:47:36 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 3541 invoked by uid 89); 14 Jan 2016 21:47:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=2.4 required=5.0 tests=AWL,BAYES_05,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=Hx-spam-relays-external:sk:p3plsmt, H*RU:sk:p3plsmt, Hx-languages-length:1922, 99.9 X-HELO: p3plwbeout03-01.prod.phx3.secureserver.net Received: from p3plsmtp03-01-2.prod.phx3.secureserver.net (HELO p3plwbeout03-01.prod.phx3.secureserver.net) (72.167.218.213) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Thu, 14 Jan 2016 21:47:34 +0000 Received: from localhost ([72.167.218.132]) by p3plwbeout03-01.prod.phx3.secureserver.net with bizsmtp id 5xnZ1s0022rz53401xnZ81; Thu, 14 Jan 2016 14:47:33 -0700 X-SID: 5xnZ1s0022rz53401 Received: (qmail 27655 invoked by uid 99); 14 Jan 2016 21:47:33 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" User-Agent: Workspace Webmail 5.16.0 Message-Id: <20160114144731.5c1bb9f86d671edec44bb378f25c04cc.7a526e7354.wbe@email03.secureserver.net> From: To: "Linux Mercedes" , gdb@sourceware.org Subject: RE: gdb cannot find "../sysdeps/unix/syscall-template.S" Date: Thu, 14 Jan 2016 21:47:00 -0000 Mime-Version: 1.0 X-IsSubscribed: yes X-SW-Source: 2016-01/txt/msg00016.txt.bz2 [resend this time as plain text...] >> get an error dialog that says "../sysdeps/unix/syscall-template.S This is most likely (99.9% certainty) caused by some library code, perhaps "glibc" (the standard C library) Example (and more detail) https://sourceware.org/glibc/wiki/SyscallWrappers So your application code has hit a break point - deep within the bowels of the standard C library (aka: GLIBC) and there happens to be debug information in that file .. which GDB properly reports to DDD the filename and line number. Sort of like this: your code has: printf("hello world") . The call chain is like this: printf() calls vprintf() -> calls buffer write -> calls _iowrite() calls the standard posix write(), which is implemented via the syscall template in assembly language. DDD - (or GDB) being a source level debugger attempts to find this file and complains that the file cannot be found. Not sure which one is does this, but I agree - it is very annoying... but mostly harmless. =3D=3D=3D=3D Why does this happen? Being a _true_ software engineer, nobody wants to write these ASM wrappers... so somebody got smart and created a template - that is used for nearly *ALL* system calls to the linux kernel. [Maybe 100%, but maybe one or two are done in some manual way] Hence, the damn debugger wants this file very often. =3D=3D=3D=3D What is the true fix? The distribution you are using (ie: I'm using Ubuntu) should *NOT* compile these files for GLIBC with debug records turned on (or the should *STRIP* all debug info from the object files and/or library). If the code does *NOT* have the debug records, then GDB (and ddd) is very quite about this. Also note: Debug records might not be *IN* the object, they could be in a parallel file (next to, or similar place) and the debugger knows how to find the corresponding symbol files for each library. -Duane.