Pedro Alves b58a68fe57 Fix "info break" + "catch catch" + -static-{libstdc++,libgcc}
If you debug current GDB, set a "catch catch/throw/rethrow"
catchpoint, and then do "info breakpoints", the top GDB hits an
internal error:

 (top-gdb) catch catch
 Catchpoint 1 (catch)
 (top-gdb) info breakpoints
 Num     Type           Disp Enb Address            What
 1       breakpoint     keep y   src/gdb/breakpoint.c:6040: internal-error: void print_one_breakpoint_location(breakpoint*, bp_location*, int, bp_location**, int): Assertion `b->loc == NULL || b->loc->next == NULL' failed.
 A problem internal to GDB has been detected,
 further debugging may prove unreliable.
 Quit this debugging session? (y or n)

The assertion in question is asserting that a breakpoint with a
print_one method only has one location, and it fails because this
catchpoint ends up with two locations.

Internally, "catch catch" sets a breakpoint at __cxa_begin_catch.  If
we do that manually, we see the locations:

  (top-gdb) b -qualified __cxa_begin_catch
  Breakpoint 2 at 0xb122b0 (2 locations)
  (top-gdb) info breakpoints
  Num     Type           Disp Enb Address            What
  2       breakpoint     keep y   <MULTIPLE>
  2.1                         y   0x0000000000b122b0 <__cxa_begin_catch>
  2.2                         y   0x00007ffff2f4ddb0 in __cxxabiv1::__cxa_begin_catch(void*) at ../../../../libstdc++-v3/libsupc++/eh_catch.cc:41

Note that I had used -qualified.  It seems strange that we get a
location for a namespaced symbol, but that happens because the minimal
symbol for that address is indeed called __cxa_begin_catch.

The real issue is that gdb is linked with
-static-libgcc/-static-libstdc++.  And then, it _also_ ends up with
shared libstc++ loaded:

  (top-gdb) info sharedlibrary stdc++
  From                To                  Syms Read   Shared Object Library
  0x00007ffff2f4b380  0x00007ffff2ffc018  Yes         /lib64/libstdc++.so.6

Location 2.2 is set within libstdc++.so.6's range:

  (top-gdb) p 0x00007ffff2f4b380 <= 0x00007ffff2f4ddb0 && 0x00007ffff2f4ddb0 < 0x00007ffff2ffc018
  $1 = true

So due to -static-lib*, we end up with _two_ copies of the
__cxa_begin_catch code:

  (top-gdb) disassemble 0x0000000000b122b0
  Dump of assembler code for function __cxa_begin_catch:
     0x0000000000b122b0 <+0>:     push   %rbx
     0x0000000000b122b1 <+1>:     mov    %rdi,%rbx
     0x0000000000b122b4 <+4>:     callq  0xb11a80 <__cxa_get_globals>
     0x0000000000b122b9 <+9>:     movabs $0xb8b1aabcbcd4d500,%rdx
  ...

  (top-gdb) disassemble 0x00007ffff2f4ddb0
  Dump of assembler code for function __cxxabiv1::__cxa_begin_catch(void*):
     0x00007ffff2f4ddb0 <+0>:     push   %rbx
     0x00007ffff2f4ddb1 <+1>:     mov    %rdi,%rbx
     0x00007ffff2f4ddb4 <+4>:     callq  0x7ffff2f4a090 <__cxa_get_globals@plt>
     0x00007ffff2f4ddb9 <+9>:     movabs $0xb8b1aabcbcd4d500,%rdx
  ...

I think we end up with libstdc++.so.6 loaded because
libsource-highlight.so depends on it.

Irrespective of whether it's a good idea to use
-static-libgcc/-static-libstdc++, GDB should not crash.  Since there
are two copies of the code, it seems right to have more than one
location.  So the fix is just to remove the assertion.

A testcase is included, which mimics the scenerio described above,
with binary linked with -static-lib{stdc++,gcc} and a shared library
that is linked normally, along with other combinations for good
measure.

gdb/ChangeLog:
2019-07-09  Pedro Alves  <palves@redhat.com>

	PR c++/15468
	* breakpoint.c (print_one_breakpoint_location): Remove
	single-location assert.

gdb/testsuite/ChangeLog:
2019-07-09  Pedro Alves  <palves@redhat.com>

	PR c++/15468
	* gdb.cp/except-multi-location-lib.cc: New.
	* gdb.cp/except-multi-location-main.cc: New.
	* gdb.cp/except-multi-location.exp: New.
2019-07-09 19:26:15 +01:00
2019-07-09 00:00:12 +00:00
2019-06-28 10:17:08 +09:30
2019-06-21 13:23:59 +01:00
2019-06-28 10:18:03 +09:30
2019-07-08 15:24:14 +09:30
2018-10-31 17:16:41 +00:00
2019-06-21 15:20:34 +02:00
2019-06-14 12:40:02 -06:00
2019-06-14 12:40:02 -06:00
2019-06-14 12:40:02 -06:00
2019-06-14 12:40:02 -06:00
2019-06-14 12:40:02 -06:00

		   README for GNU development tools

This directory contains various GNU compilers, assemblers, linkers, 
debuggers, etc., plus their support routines, definitions, and documentation.

If you are receiving this as part of a GDB release, see the file gdb/README.
If with a binutils release, see binutils/README;  if with a libg++ release,
see libg++/README, etc.  That'll give you info about this
package -- supported targets, how to use it, how to report bugs, etc.

It is now possible to automatically configure and build a variety of
tools with one command.  To build all of the tools contained herein,
run the ``configure'' script here, e.g.:

	./configure 
	make

To install them (by default in /usr/local/bin, /usr/local/lib, etc),
then do:
	make install

(If the configure script can't determine your type of computer, give it
the name as an argument, for instance ``./configure sun4''.  You can
use the script ``config.sub'' to test whether a name is recognized; if
it is, config.sub translates it to a triplet specifying CPU, vendor,
and OS.)

If you have more than one compiler on your system, it is often best to
explicitly set CC in the environment before running configure, and to
also set CC when running make.  For example (assuming sh/bash/ksh):

	CC=gcc ./configure
	make

A similar example using csh:

	setenv CC gcc
	./configure
	make

Much of the code and documentation enclosed is copyright by
the Free Software Foundation, Inc.  See the file COPYING or
COPYING.LIB in the various directories, for a description of the
GNU General Public License terms under which you can copy the files.

REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info
on where and how to report problems.
Description
Unofficial mirror of sourceware binutils-gdb repository. Updated daily.
Readme 780 MiB
Languages
C 51.8%
Makefile 22.4%
Assembly 12.3%
C++ 6%
Roff 1.4%
Other 5.4%