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

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

[Linux Mercedes]

Hi,

I have an issue that appears when I'm running gdb from inside ddd. I
will load and run a program and let it sit a few minutes (waiting on
stdin input, if that matters). After it has sat a little bit, I will
get an error dialog that says "../sysdeps/unix/syscall-template.S No
such file or directory". gdb will then repeatedly output the
following:

file: "../sysdeps/unix/syscall-template.S", line number: 1
(gdb)  file: "../sysdeps/unix/syscall-template.S", line number: 1
(gdb)  file: "../sysdeps/unix/syscall-template.S", line number: 1
(gdb)  file: "../sysdeps/unix/syscall-template.S", line number: 1
(gdb)  file: "../sysdeps/unix/syscall-template.S", line number: 1
(gdb)  file: "../sysdeps/unix/syscall-template.S", line number: 1
(gdb)  file: "../sysdeps/unix/syscall-template.S", line number: 1
(gdb)  file: "../sysdeps/unix/syscall-template.S", line number: 1
(gdb)  file: "../sysdeps/unix/syscall-template.S", line number: 1
(gdb)  file: "../sysdeps/unix/syscall-template.S", line number: 1
(gdb) Continuing.
Continuing.
Continuing.
Continuing.
Continuing.
Continuing.
Continuing.
Continuing.
Continuing.
Continuing.
Continuing.

Inspection via strace shows that it is repeatedly attempting to open()
the mentioned file.

I am running Ubuntu 14.04, gdb 7.7.1, ddd 3.3.12. I figured I would
ask you folks rather than the ddd folks since this seems like a gdb
issue.

Do you have any idea why gdb expects that file to exist?

Thanks!

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

[Jan Kratochvil]

On Thu, 14 Jan 2016 22:06:38 +0100, Linux Mercedes wrote:
> file: "../sysdeps/unix/syscall-template.S", line number: 1

It may be more clear if you type:

(gdb) set filename-display absolute 

Then there are various substitution commands in GDB how to point it to the
right directory.


Jan

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

[Linux Mercedes]

> (gdb) set filename-display absolute

Well, now it's looking for a file in
/build/buildd/eglibc-2.19/io/../sysdeps/unix/syscall-template.S
(replace io with misc, posix, resource, and a handful of others).

> Then there are various substitution commands in GDB how to point it to the
> right directory.

Is there a way to just not have GDB try to debug that, or to suppress
this error? As Mike Frysinger points out, that source isn't going to
be particularly helpful to look at anyway.

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

[Jan Kratochvil]

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

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

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 2961 bytes --]

On 14 Jan 2016 23:23, Jan Kratochvil wrote:
> 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.

why ?  i'm talking about this one specific file which is literally generated
assembly code for a syscall trampoline.  let's look at one example: msgctl
on x86_64.

$ ar x /usr/lib64/libc.a msgctl.o
$ objdump -dr msgctl.o

msgctl.o:     file format elf64-x86-64


Disassembly of section .text:

0000000000000000 <__msgctl>:
   0:	b8 47 00 00 00       	mov    $0x47,%eax
   5:	0f 05                	syscall 
   7:	48 3d 01 f0 ff ff    	cmp    $0xfffffffffffff001,%rax
   d:	0f 83 00 00 00 00    	jae    13 <__msgctl+0x13>
			f: R_X86_64_PC32	__syscall_error-0x4
  13:	c3                   	retq   

what exactly do you expect the syscall-template.S to provide that is useful ?
here's the file in case you were wondering:
...
#if SYSCALL_CANCELLABLE
# include <sysdep-cancel.h>
#else
# include <sysdep.h>
#endif

/* This indirection is needed so that SYMBOL gets macro-expanded.  */
#define syscall_hidden_def(SYMBOL)		hidden_def (SYMBOL)

#define T_PSEUDO(SYMBOL, NAME, N)		PSEUDO (SYMBOL, NAME, N)
#define T_PSEUDO_NOERRNO(SYMBOL, NAME, N)	PSEUDO_NOERRNO (SYMBOL, NAME, N)
#define T_PSEUDO_ERRVAL(SYMBOL, NAME, N)	PSEUDO_ERRVAL (SYMBOL, NAME, N)
#define T_PSEUDO_END(SYMBOL)			PSEUDO_END (SYMBOL)
#define T_PSEUDO_END_NOERRNO(SYMBOL)		PSEUDO_END_NOERRNO (SYMBOL)
#define T_PSEUDO_END_ERRVAL(SYMBOL)		PSEUDO_END_ERRVAL (SYMBOL)

#if SYSCALL_NOERRNO

/* This kind of system call stub never returns an error.
   We return the return value register to the caller unexamined.  */

T_PSEUDO_NOERRNO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
	ret_NOERRNO
T_PSEUDO_END_NOERRNO (SYSCALL_SYMBOL)

#elif SYSCALL_ERRVAL

/* This kind of system call stub returns the errno code as its return
   value, or zero for success.  We may massage the kernel's return value
   to meet that ABI, but we never set errno here.  */

T_PSEUDO_ERRVAL (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
	ret_ERRVAL
T_PSEUDO_END_ERRVAL (SYSCALL_SYMBOL)

#else

/* This is a "normal" system call stub: if there is an error,
   it returns -1 and sets errno.  */

T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
	ret
T_PSEUDO_END (SYSCALL_SYMBOL)

#endif

syscall_hidden_def (SYSCALL_SYMBOL)
...

if anything, using disassemble on the function directly is way more useful
and readable.
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Jan Kratochvil]

On Fri, 15 Jan 2016 01:02:43 +0100, Mike Frysinger wrote:
> what exactly do you expect the syscall-template.S to provide that is useful ?

I agree this one function/file is the same without debug info.
I was advocating debug info for system libraries in general.


Jan

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

[Jan Kratochvil]

On Thu, 14 Jan 2016 23:11:02 +0100, Linux Mercedes wrote:
> Well, now it's looking for a file in
> /build/buildd/eglibc-2.19/io/../sysdeps/unix/syscall-template.S

Yes, Ubuntu/Debian has broken debug info.  Fedora/RHEL is using
	/usr/lib/rpm/debugedit
to redirect the source references to their proper /usr/src/debug/** location.


Jan

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

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 601 bytes --]

On 14 Jan 2016 15:06, Linux Mercedes wrote:
> I have an issue that appears when I'm running gdb from inside ddd. I
> will load and run a program and let it sit a few minutes (waiting on
> stdin input, if that matters). After it has sat a little bit, I will
> get an error dialog that says "../sysdeps/unix/syscall-template.S No
> such file or directory".

not answering your question directly, but that is a generated file from
glibc, and having its source isn't really useful.  it'd be the same as
looking at the disassembly directly.  you'll see it used for many low
level functions in glibc.
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[duane]

[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.

====

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.

====

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.

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

[Linux Mercedes]

> Why does this happen?

Neat! That makes sense; thanks for explaining the details.

> 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).

> 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.

Aha! Turns out I somehow had the libc6-dbg package installed. Removing
it fixes the 'No such file or directory' issue.

It still prints 'Continuing.', but I'll have to sit down with the DDD
manual and see what it's doing to fix that.

Thanks!

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

[Andreas Schwab]

Mike Frysinger <vapier@gentoo.org> writes:

> On 14 Jan 2016 15:06, Linux Mercedes wrote:
>> I have an issue that appears when I'm running gdb from inside ddd. I
>> will load and run a program and let it sit a few minutes (waiting on
>> stdin input, if that matters). After it has sat a little bit, I will
>> get an error dialog that says "../sysdeps/unix/syscall-template.S No
>> such file or directory".
>
> not answering your question directly, but that is a generated file from
> glibc, 

Except that it isn't.  You just need to install the matching
glibc-debugsource package.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."