From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: Linux Mercedes <linuxmercedes@gmail.com>,
duane@duaneellis.com, gdb@sourceware.org
Subject: Re: gdb cannot find "../sysdeps/unix/syscall-template.S"
Date: Thu, 14 Jan 2016 22:23:00 -0000 [thread overview]
Message-ID: <20160114222340.GA4824@host1.jankratochvil.net> (raw)
In-Reply-To: <20160114215549.GW4894@vapier.lan> <20160114144731.5c1bb9f86d671edec44bb378f25c04cc.7a526e7354.wbe@email03.secureserver.net> <CANq-9DgxnU2sobP5QAkP=2SfxpwSiOhjLE9Eeyqu9yxMcNBBdA@mail.gmail.com>
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
next prev parent reply other threads:[~2016-01-14 22:23 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-14 21:07 Linux Mercedes
2016-01-14 21:10 ` Jan Kratochvil
2016-01-14 22:11 ` Linux Mercedes
2016-01-14 22:23 ` Jan Kratochvil [this message]
2016-01-15 0:02 ` Mike Frysinger
2016-01-15 8:05 ` Jan Kratochvil
2016-01-14 22:25 ` Jan Kratochvil
2016-01-14 21:55 ` Mike Frysinger
2016-01-14 21:47 ` duane
2016-01-14 22:22 ` Linux Mercedes
2016-01-15 9:34 ` Andreas Schwab
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160114222340.GA4824@host1.jankratochvil.net \
--to=jan.kratochvil@redhat.com \
--cc=duane@duaneellis.com \
--cc=gdb@sourceware.org \
--cc=linuxmercedes@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox