From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 43713 invoked by alias); 14 Jan 2016 22:23:48 -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 43566 invoked by uid 89); 14 Jan 2016 22:23:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.4 required=5.0 tests=BAYES_00,FAKE_REPLY_C,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=sk:duaned, duaneduaneelliscom, reaction, duane@duaneellis.com X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 14 Jan 2016 22:23:45 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 35086C09FA98; Thu, 14 Jan 2016 22:23:44 +0000 (UTC) Received: from host1.jankratochvil.net (ovpn-116-93.ams2.redhat.com [10.36.116.93]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u0EMNeQN002838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 14 Jan 2016 17:23:43 -0500 Date: Thu, 14 Jan 2016 22:23:00 -0000 From: Jan Kratochvil To: Linux Mercedes , duane@duaneellis.com, gdb@sourceware.org Subject: Re: gdb cannot find "../sysdeps/unix/syscall-template.S" Message-ID: <20160114222340.GA4824@host1.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160114215549.GW4894@vapier.lan> <20160114144731.5c1bb9f86d671edec44bb378f25c04cc.7a526e7354.wbe@email03.secureserver.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-IsSubscribed: yes X-SW-Source: 2016-01/txt/msg00020.txt.bz2 On Thu, 14 Jan 2016 23:11:02 +0100, Linux Mercedes wrote: > As Mike Frysinger points out, that source isn't going to > be particularly helpful to look at anyway. + On Thu, 14 Jan 2016 22:47:31 +0100, duane@duaneellis.com wrote: > The distribution you are using (ie: I'm using Ubuntu) should *NOT* compile > these files for GLIBC with debug records turned on + On Thu, 14 Jan 2016 22:55:49 +0100, Mike Frysinger wrote: > that is a generated file from glibc, and having its source isn't really useful. I am very surprised by this reaction. Missing/broken debug info is a longterm problem of Ubuntu/Debian and they even recently try to fix it by new automatic *-dbgsym packages: https://wiki.debian.org/DebugPackage For example initstate_r(..., struct random_data *buf); according to a man page "initializes the state in the object pointed to by buf". So I do: struct random_data buf; initstate_r(..., &buf); and I get a crash inside initstate_r(). One has to memset(&buf, 0, sizeof(buf)); first but no doc says that. With sources for glibc/initstate_r() it is obvious from the point of crashcrash. It happens (for me) very often. More commonly one passes wrong parameters to a library function which thus crashes. But it may not be immediately obvious why the parameters were invalid while when one sees the crashing function implementation code it makes it more clear. Jan