Joel Brobecker 31aa7e4ee9 DWARF: Read constant-class addresses correctly
Starting with DWARF version 4, the description of the DW_AT_high_pc
attribute was amended to say:

   if it is of class constant, the value is an unsigned integer offset
   which when added to the low PC gives the address of the first
   location past the last instruction associated with the entity.

A change was made in Apr 27th, 2012 to reflect that change:

  | commit 91da14142c0171e58a91ad58a32fd010b700e761
  | Author: Mark Wielaard <mjw@redhat.com>
  | Date:   Fri Apr 27 18:55:19 2012 +0000
  |
  |     * dwarf2read.c (dwarf2_get_pc_bounds): Check DW_AT_high_pc form to
  |     see whether it is an address or a constant offset from DW_AT_low_pc.
  |     (dwarf2_record_block_ranges): Likewise.
  |     (read_partial_die): Likewise.

Unfortunately, this new interpretation is now used regardless of
the CU's DWARF version. It turns out that one of WindRiver's compilers
(FTR: Diabdata 4.4) is generating DWARF version 2 info with
DW_AT_high_pc attributes improperly using the data4 form. Because of
that, we miscompute all high PCs incorrectly. This leads to a lot of
symtabs having overlapping ranges, which in turn causes havoc in
pc-to-symtab-and-line translations.

One visible effect is when inserting a breakpoint on a given function:

    (gdb) b world
    Breakpoint 1 at 0x4005c4

The source location of the breakpoint is missing. The output should be:

    (gdb) b world
    Breakpoint 1 at 0x4005c8: file dw2-rel-hi-pc-world.c, line 24.

What happens in this case is that the pc-to-SAL translation first
starts be trying to find the symtab associated to our PC using
each symtab's ranges. Because of the high_pc miscomputation,
many symtabs end up matching, and the heuristic trying to select
the most probable one unfortunately returns one that is unrelated
(it really had no change in this case to do any better). Once we
have the wrong symtab, the start searching the associated linetable,
where the addresses are correct, thus finding no match, and therefore
no SAL.

This patch is an attempt at handling the situation as gracefully
as we can, without guarantees.  It introduces a new function
"attr_value_as_address" which uses the correct accessor for getting
the value of a given attribute.  It then adjust the code throughout
this unit to use this function instead of assuming that addresses always
have the DW_FORM_addr format.

It also fixes the original issue of miscomputing the high_pc
by limiting the new interpretation of constant form DW_AT_high_pc
attributes to units using DWARF version 4 or later.

gdb/ChangeLog:

        * dwarf2read.c (attr_value_as_address): New function.
        (dwarf2_find_base_address, read_call_site_scope): Use
        attr_value_as_address in place of DW_ADDR.
        (dwarf2_get_pc_bounds): Use attr_value_as_address to get
        the low and high addresses.  Slight rework of the handling
        of the high pc being a constant form, and limit it to
        DWARF verson 4 or higher.
        (dwarf2_record_block_ranges): Likewise.
        (read_partial_die): Likewise.
        (new_symbol_full): Use attr_value_as_address in place of DW_ADDR.

gdb/testsuite/ChangeLog:

        * gdb.dwarf2/dw2-abs-hi-pc-hello-dbg.S: New file.
        * gdb.dwarf2/dw2-abs-hi-pc-hello.c: New file.
        * gdb.dwarf2/dw2-abs-hi-pc-world-dbg.S: New file.
        * gdb.dwarf2/dw2-abs-hi-pc-world.c: New file.
        * gdb.dwarf2/dw2-abs-hi-pc.c: New file.
        * gdb.dwarf2/dw2-abs-hi-pc.exp: New file.

Tested on x86_64-linux.
2014-02-26 11:43:23 -08:00
2014-02-26 09:30:38 +10:30
2014-02-06 11:26:26 -08:00
2014-02-21 08:04:00 -08:00
2014-02-11 11:26:37 -08:00
2014-02-10 09:59:35 +10:30
2014-02-09 15:56:36 -08:00
2014-02-25 08:52:02 -08:00
2014-02-06 11:01:57 +01:00
2014-02-06 11:01:57 +01: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
Binutils with MCST patches
Readme 404 MiB
Languages
C 52.1%
Makefile 22.5%
Assembly 12.2%
C++ 6.2%
Roff 1.1%
Other 5.3%