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: Still have problem with missing files (warnings)


> 7 )) What I want to conclude is that GDB didn't send the SIGCONT to my program. The function that communicate with GDB is
> 
> extern "C" void init_local(void) {
> ? std::cerr << "Entered init_local\n";
> ? print_copyright();
> ? if (getenv("WAITFORSIGCONT")) {
> ??? std::cerr << "Waiting for SIGCONT..." << std::endl;
> ??? std::cerr << "Attach gdb with the following command and 'c' from the gdb prompt:" << std::endl;
> ??? std::cerr << "? gdb - " << getpid() << std::endl;
> ??? raise(SIGSTOP);
> ? }
> ? DBG_(Dev, ( << "Initializing Flexus." ));
> ? Flexus::Simic::PrepareFlexus();
> ? DBG_(Iface, ( << "Flexus Initialized." ));
> }

You are doing a strange thing here.  SIGSTOP and SIGCONT are bizarre
signals, used mostly for shell "job control", and they don't act much
like normal signals.  Don't use signals at all for this.

If you really want the program to sit somewhere and wait for you to
attach to it with GDB, don't raise SIGSTOP.  Replace that line with a
call to a function that just loops forever, like this:

void wait_for_gdb() {
  for (;;) ;
}

Then after you attach with GDB, just force the function to return,
rather than continuing the endless loop:

  (gdb) return

Or make execution go to the next useful line with:

  (gdb) jump lineno  [the line of the function you want it to resume at]

Or, you could have the program loop until a variable changes:

void wait_for_gdb ()
{ volatile int waiting = 1; while (waiting) ; }

Then after attaching, just do:

  (gdb) set waiting = 0
  (gdb) c

But why are you bothering with such things?  You are setting an
environment variable and then invoking the program and then having
special code in the program to print out how to attach gdb and then
manually attaching GDB and then manually breaking out of the wait.
All complicated and error-prone.  I know it's what the manual
suggests, but have you considered just running the program under gdb
in the first place?

  $ gdb programname
  ...
  (gdb) b init_local     [or anywhere else that you want it to stop]
  (gdb) run [include command line arguments if any]

Then you don't need any of this wait-and-attach crud, which seems to
be wasting large amounts of your time and not letting you actually 
debug your problems.

If there are long complicated command-line arguments that your
"./run" script is making, the script can pass them to GDB this way:

  $ gdb programname --args arg1 arg2 arg3 arg4 etc

Then a subsequent "run" command with no arguments will just use the
arguments from the GDB command line.

	John

PS: You said:
> 4 )) At this point I will enter "continue" in the GDB prompt. However shortly after that, GDB reports a crash with the following backtrace

This is not a crash.  This is the program stopping with a signal.  You
can resume from this stop, if you want to, e.g. with the "c" command.
It's probably stopping because your program raised that signal.
Again, I recommend getting rid of the signal crap.  Then your program
won't stop from signals it sends itself.

PPS: Your stack trace from the signal shows that not only does GDB not
know where your source files are, but you also seem to be compiling
the code with optimization, which makes debugging not work very well.
Recompile every file without -O and with -g, and GDB will work much
better.  If it still can't find your source files, use the GDB "dir"
command to add the directory names where your source files are.


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