uefi-ref/binutils-gdb
1
0
Fork 0
mirror of https://sourceware.org/git/binutils-gdb.git synced 2026-08-27 00:26:02 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions
No description
124601 commits 392 branches 146 tags 559 MiB
Find a file
Exact
Jan Vrany e855469f9d Revert "gdb: change blockvector::contains() to handle blockvectors with "holes"" 
This reverts commit cc1fc6af41, since it
causes a number of regressions that seem not to be easily fixable.

The problem lies in existence of "freestanding" code, a code that is
part of a CU but does not have any block associated with it. Consider
following program:

    __asm__(
      ".type foo,@function   \n"
      "foo:                  \n"
      "  mov %rdi, %rax      \n"
      "  ret                 \n"
    );

    static int foo(int i);

    int main(int argc, char **argv) {
      return foo(argc);
    }

When compiled, the foo function has no block of itself:

    Blockvector:

    no map

    block #000, object at 0x55978957b510, 1 symbols in 0x1129..0x1148
     int main(int, char **); block object 0x55978957b380, 0x112d..0x1148 section .text
      block #001, object at 0x55978957b470 under 0x55978957b510, 2 symbols in 0x1129..0x1148
       typedef int int;
       typedef char char;
        block #002, object at 0x55978957b380 under 0x55978957b470, 2 symbols in 0x112d..0x1148, function main
         int argc; computed at runtime
         char **argv; computed at runtime

In this case lookup(0x1129) returns static block and, because of the
change in cc1fc6af4, contains(0x1129) which is wrong.

Such "freestanding" code is perhaps not common but it does exist,
especially in system code. In fact the regressions were at least in part
caused by such "freestanding" code in glibc (libc_sigaction.c).

The whole idea of commit cc1fc6af4 was to handle "holes" in CUs, a case
where one CU spans over multiple disjoint regions, possibly interleaved
with other CUs. Consider somewhat extreme case with two CUs:

    /* hole-1.c */
    int give_me_zero ();

    int
    main ()
    {
      return give_me_zero ();
    }

    /* hole-2.c */
        int __attribute__ ((section (".text_give_me_one"))) __attribute__((noinline))
    baz () { return 42; }

    __asm__(
      ".section  .text_give_me_one,\"ax\",@progbits\n"
      ".type foo,@function         \n"
      "foo:                        \n"
            "  mov %rdi, %rax      \n"
            "  ret                 \n"
            "  nop                 \n"
            "  nop                 \n"
            "  nop                 \n"
    );
    int __attribute__ ((section (".text_give_me_one"))) __attribute__((noinline))
    give_me_one ()
    {
      return 1;
    }

    __asm__(
      ".section  .text_give_me_zero,\"ax\",@progbits\n"
      "bar:                        \n"
            "  jmp give_me_one     \n"
            "  nop                 \n"
            "  nop                 \n"
            "  nop                 \n"
    );
    int __attribute__ ((section (".text_give_me_zero")))
    give_me_zero ()
    {
      extern int bar();
      return give_me_one() - 1;
    }

This when compiled with a carefully crafted linker script to force code
at certain positions, creates following layout:

   0x080000..0x080007   # "freestanding" bar from hole-2.c
   0x080008..0x080016   # give_me_zero() from hole-2.c
   0x080109..0x080114   # main from hole-1.c
   0xf00000..0xf0000b   # baz() from hole-2.c
   0xf0000b..0xf00011   # "freestanding" foo from hole-2.
   0xf0000b..0xf0001c   # gice_me_one() from hole-2.

The block vector for hole-1.c looks:

    Blockvector:

    no map

    block #000, object at 0x555a5d85fb90, 1 symbols in 0x80109..0x80114
     int main(void); block object 0x555a5d85faa0, 0x80109..0x80114 section .text
      block #001, object at 0x555a5d85faf0 under 0x555a5d85fb90, 1 symbols in 0x80109..0x80114
       typedef int int;
        block #002, object at 0x555a5d85faa0 under 0x555a5d85faf0, 0 symbols in 0x80109..0x80114, function main

And for hole-2.c:

    Blockvector:

    map
      0x0 -> 0x0
      0x80008 -> 0x555a5d85ff50
      0x80016 -> 0x0
      0xf00000 -> 0x555a5d860280
      0xf0000b -> 0x0
      0xf00012 -> 0x555a5d860110
      0xf0001d -> 0x0

    block #000, object at 0x555a5d8603b0, 3 symbols in 0x80008..0xf0001d
     int give_me_zero(void); block object 0x555a5d85ff50, 0x80008..0x80016 section .text
     int give_me_one(void); block object 0x555a5d860110, 0xf00012..0xf0001d section .text
     int baz(void); block object 0x555a5d860280, 0xf00000..0xf0000b section .text
      block #001, object at 0x555a5d8602d0 under 0x555a5d8603b0, 1 symbols in 0x80008..0xf0001d
       typedef int int;
        block #002, object at 0x555a5d85ff50 under 0x555a5d8602d0, 0 symbols in 0x80008..0x80016, function give_me_zero
        block #003, object at 0x555a5d860280 under 0x555a5d8602d0, 0 symbols in 0xf00000..0xf0000b, function baz
        block #004, object at 0x555a5d860110 under 0x555a5d8602d0, 0 symbols in 0xf00012..0xf0001d, function give_me_one

Note that despite the fact "freestanding" bar belongs to hole-2.c, the
corresponding CU's global and static blocks start at 0x80008! Looking
at DWARF for the second program, it looks like that the compiler (GCC 15)
did not record the presence of "freestanding" code:

    <0><71>: Abbrev Number: 1 (DW_TAG_compile_unit)
        <72>   DW_AT_producer    : (indirect string, offset: 0): GNU C23 15.2.0 -mtune=generic -march=x86-64 -g -fasynchronous-unwind-tables
        <76>   DW_AT_language    : 29   (C11)
        <77>   Unknown AT value: 90: 3
        <78>   Unknown AT value: 91: 0x31647
        <7c>   DW_AT_name        : (indirect line string, offset: 0x2d): hole-2.c
        <80>   DW_AT_comp_dir    : (indirect line string, offset: 0): test_programs
        <84>   DW_AT_ranges      : 0xc
        <88>   DW_AT_low_pc      : 0
        <90>   DW_AT_stmt_list   : 0x51

and corresponding part of .debug_aranges:

      Length:                   76
      Version:                  2
      Offset into .debug_info:  0x65
      Pointer Size:             8
      Segment Size:             0

        Address            Length
        0000000000f00000 000000000000000b
        0000000000f00012 000000000000000b
        0000000000080008 000000000000000e
        0000000000000000 0000000000000000

Thiago suggested to use minsymbols to tell whether or a CU contains
given address. I do not think this would work reliably as minsymbols do
no know to which CU they belong. In slightly more complicated case of
interleaved CUs it does not seem to be possible to tell for sure to which
one a given minsymbol belongs.

Moreover, Tom suggested that the comment in find_compunit_symtab_for_pc_sect
(which led to cc1fc6af4) may be outdated [2].

Given all that, I'm just reverting the change.

[1]: https://sourceware.org/bugzilla/show_bug.cgi?id=33679#c13
[2]: https://inbox.sourceware.org/gdb-patches/87cy6xzd3j.fsf@tromey.com/

Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33679
2025-12-22 12:54:52 +00:00
bfd Automatic date update in version.in 2025-12-21 00:00:08 +00:00
binutils LoongArch: Add disassembly support for ud ui5 2025-12-20 10:49:47 +08:00
config tidy m4 plugin config support 2025-11-03 10:59:50 +10:30
contrib [contrib] Accept _("") and operator() in check_GNU_style_lib.py 2025-11-20 10:46:54 +01:00
cpu Add markers for 2.45 branch 2025-07-13 08:35:45 +01:00
elfcpp bitwise operation between different enumeration types 2025-12-09 20:17:41 +10:30
etc Update year range in copyright notice of binutils files 2025-01-01 18:29:57 +10:30
gas LoongArch: Add disassembly support for ud ui5 2025-12-20 10:49:47 +08:00
gdb Revert "gdb: change blockvector::contains() to handle blockvectors with "holes"" 2025-12-22 12:54:52 +00:00
gdbserver [gdb] Fix whitespace in *.def 2025-12-10 00:25:20 +01:00
gdbsupport Don't use "module" name 2025-12-18 11:50:08 -07:00
gnulib Import the c-ctype module from gnulib 2025-09-09 11:58:27 -06:00
gold gold testsuite volatile fixes 2025-12-09 20:17:41 +10:30
gprof gprofng: Add documentation on converting gmon files. 2025-11-20 14:59:33 +02:00
gprofng gprofng: protect against standard library macros 2025-11-28 21:46:04 +01:00
include bfd: include: sframe: fix PR ld/32789 2025-12-19 23:11:45 -08:00
ld Add back non-solaris ELF targets to solaris config 2025-12-20 23:08:13 +10:30
libbacktrace tidy m4 plugin config support 2025-11-03 10:59:50 +10:30
libctf ctf-archive sanity checks 2025-11-03 13:01:42 +10:30
libdecnumber regen config 2023-08-12 10:27:57 +09:30
libiberty tidy m4 plugin config support 2025-11-03 10:59:50 +10:30
libsframe libsframe: testsuite: fix build failure 2025-12-19 23:36:53 -08:00
opcodes LoongArch: Add disassembly support for ud ui5 2025-12-20 10:49:47 +08:00
readline readline/tcap.h: Update definitions for C23 2025-05-02 12:00:05 -06:00
sim sim: make local variable 'const' 2025-12-05 14:23:30 +00:00
texinfo
zlib tidy m4 plugin config support 2025-11-03 10:59:50 +10:30
.cvsignore
.editorconfig toplevel: unify the GCC and GDB/binutils .editorconfig files 2025-10-01 16:20:29 +01:00
.gitattributes binutils-gdb/git: Handle *.ac and *.m4 files in .gitattributes 2025-12-18 10:00:54 +01:00
.gitignore Add Vim swap files to .gitignore 2025-02-28 16:06:25 +00:00
.pre-commit-config.yaml [pre-commit] Move codespell-log to post-commit 2025-12-15 17:19:26 +01:00
ar-lib
ChangeLog Add markers for 2.45 branch 2025-07-13 08:35:45 +01:00
compile
config-ml.in MSP430: Add -fno-exceptions multilib 2023-08-12 10:24:26 +09:30
config.guess Sync config.guess and config.sub with latest versions from the config project. 2025-01-17 10:18:30 +00:00
config.rpath
config.sub Sync config.guess and config.sub with latest versions from the config project. 2025-01-17 10:18:30 +00:00
configure Sync top-level with GCC 2025-11-03 09:53:04 +00:00
configure.ac Sync top-level with GCC 2025-11-03 09:53:04 +00:00
COPYING
COPYING.LIB
COPYING.LIBGLOSS
COPYING.NEWLIB
COPYING3
COPYING3.LIB
depcomp
djunpack.bat
install-sh
libtool.m4 Binutils/GCC: Add clang LTO support to AR, NM and RANLIB 2025-09-25 12:30:13 +08:00
ltgcc.m4
ltmain.sh ltmain.sh: allow more flags at link-time 2024-09-25 19:06:10 +01:00
ltoptions.m4
ltsugar.m4
ltversion.m4
lt~obsolete.m4
MAINTAINERS Fix compiling bfd/vms-lib.c for a 32-bit host. 2024-03-18 10:26:16 +00:00
Makefile.def Sync top-level with GCC 2025-11-03 09:53:04 +00:00
Makefile.in Sync toplevel files from gcc 2025-10-02 07:42:18 +08:00
Makefile.tpl Sync toplevel files from gcc 2025-10-02 07:42:18 +08:00
makefile.vms
missing
mkdep
mkinstalldirs
move-if-change
multilib.am Merge autoconf / automake update changes from GCC. 2018-10-31 17:10:56 +00:00
README README: don't talk about libg++ 2025-09-07 04:06:01 +01:00
README-maintainer-mode Note that at least dejagnu version 1.5.3 is required in order to be ale to run the testsuites. 2022-10-04 10:54:19 +01:00
SECURITY.txt Add a SECURITY.txt file describing the GNU Binutils' project's stance on security related bugs. 2023-04-20 16:52:11 +01:00
setup.com
src-release.sh Rename 'binutils' to 'binutils_with_gold'. Rename 'bin_no_gold' to 'binutils'. Add 'gold' 2025-02-04 11:50:02 +00:00
symlink-tree
test-driver
ylwrap

README 

		   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, and so on. 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.