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

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