This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gdb cannot find "../sysdeps/unix/syscall-template.S"


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]