I noticed this by accident after we introduced the new feature where
the debugger prints the assembly of the next line each time we stop.
Basically, I loaded the wrong core file and got:

        (gdb) core core
        warning: core file may not match specified executable file.
        Core was generated by `./crash'.
        Program terminated with signal 6, Aborted.
        #0  0x00007f8befcc8307 in ?? ()
 !!!->  0x00007f8befcc8307:     (gdb)

As you can see, GDB tried to print the instruction at the address
where the core file says the program stopped, but instead printed
nothing. This has two consequences:

  1. The user does not really know what the problem was;
  2. A testsuite driver that relies on seeing the prompt being placed
     at the beginning of the line would wait indefinitely for the prompt
     to come back.

I propose to change the behavior to print the error message:

        (gdb) core core
        warning: core file may not match specified executable file.
        Core was generated by `./crash'.
        Program terminated with signal 6, Aborted.
        #0  0x00007f8befcc8307 in ?? ()
        0x00007f8befcc8307:     Cannot access memory at address 0x7f8befcc8307
        (gdb) 

2009-04-16  Joel Brobecker  <brobecker@adacore.com>

        * stack.c (do_gdb_disassembly): Print the exception message if an
        error was thrown while trying to perform the disassembly.

Tested on x86_64-linux. Any objections?

(FWIW: I did not realize that GDB would now print the current assembly
 instruction by default when the change came in. I don't think that's
 a useful default based on my own usage, but no big deal)

-- 
Joel