The code so far has been assuming that we only compile common/ objects.
Now that we're ready to compile arch-specific objects, refactor some of
the flags & checks a bit to support both.
Now that all arches create libsim.a from the top-level, we have full
access to their inputs, and can move the actual generation from the
subdir up to the top-level. This avoids recursive makes and will
help simplify state passing between the two.
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
The mips code is a little more tricky than others because, for multi-run
targets, it generates the list of sources & objects on the fly in the
configure script.
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
Nothing uses this hook anymore, so punt it. It was largely used to
track generated files (which we do in the top-level now) and extra
header files (which we use automake depgen for now).
Add rules for tracking generated subdir modules.c files. This doesn't
actually generate the file from the top-level, but allows us to add
rules that need to be ordered wrt it. Once those changes land, we can
rework this to actually generate from the top-level.
This currently builds off of the objects that go into the libsim.a as
we don't build those from the top-level either. Once we migrate that
up, we can switch this to the source files directly. It's a bit hacky
overall, but makes it easier to migrate things in smaller chunks, and
we aren't going to keep this logic long term.
During breakpoint re-setting, the source_filename of an
explicit_location_spec is used to lookup the symtabs associated with
the breakpoint being re-set. This source_filename is compared with each
known symtab filename in order to retrieve the breakpoint's symtabs.
However the source_filename may have been originally copied from a
symtab's fullname (the path where GDB found the source file) when the
breakpoint was first created. If a breakpoint symtab's filename and
fullname differ and there is no substitute-path rule that converts the
fullname to the filename, this will cause a NOT_FOUND_ERROR to be thrown
during re-setting.
Fix this by using a symtab's filename to set the explicit_location_spec
source_filename instead of the symtab's fullname.
Although the bool want_start_sal isn't actually used without being assigned
a value, initialize it to be false in order to prevent the following
-Wmaybe-uninitialized warning:
linespec.c: In function ‘void minsym_found(linespec_state*, objfile*, minimal_symbol*, std::vector<symtab_and_line>*)’:
linespec.c:4150:19: warning: ‘want_start_sal’ may be used uninitialized [-Wmaybe-uninitialized]
4150 | if (is_function && want_start_sal)
This fixes a memory leak in the vanishingly rare cases (found by
fuzzers of course) when something goes wrong in the save_section_vma,
htab_create_alloc or alloc_trie_leaf calls before *pinfo is written.
If *pinfo is not written, _bfd_dwarf2_cleanup_debug_info won't be able
to free that memory.
* dwarf2.c (_bfd_dwarf2_slurp_debug_info): Save stash pointer
on setting up stash.
Also fix a memory leak, and make some style changes. I tend to read
(sizeof * x) as a multiplication of two variables, which I would not
do if binutils followed the gcc coding conventions consistently (see
https://gcc.gnu.org/codingconventions.html#Expressions). (sizeof *x)
looks a lot better to me, or even (sizeof (*x)) which I've used here.
* peXXigen.c (get_contents_sanity_check): New function.
(pe_print_idata): Use it here..
(pe_print_edata): ..and here. Free data on error return.
(rsrc_parse_entry): Check entry size read from file.
(rsrc_parse_entries): Style fixes.
(rsrc_process_section): Use bfd_malloc_and_get_section.
(_bfd_XXi_final_link_postscript): Likewise.
Similar to commit c799eddb3512, but for mips-ecoff. mips-ecoff is
marked obsolete, but we still allow reading of these object files in
a number of mips targets.
* coff-mips.c (struct mips_hi, mips_refhi_list): Delete.
(mips_refhi_reloc, mips_reflo_reloc): Access mips_refhi_list
in ecoff_data.
* ecoff.c (_bfd_ecoff_close_and_cleanup): New function.
* libecoff.h (struct mips_hi): Moved from coff-mips.c.
(struct ecoff_tdata): Add mips_refhi_list.
(_bfd_ecoff_close_and_cleanup): Declare.
init.c contains just one function that doesn't do much. Move it to
bfd.c and give it something to do, initialising static state. So far
the only initialisation is for bfd.c static variables.
The idea behind reinitialising state is to see whether some set of
flaky oss-fuzz crashes go away. oss-fuzz stresses binutils in ways
that can't occur in reality, feeding multiple testcases into the
internals of binutils. So one testcase may affect the result of the
next testcase.
* init.c: Delete file. Move bfd_init to..
* bfd.c (bfd_init): ..here. Init static variables.
* Makefile.am (BFD32_LIBS): Remove init.lo.
(BFD32_LIBS_CFILES, BFD_H_FILES): Remove init.c.
* doc/local.mk: Remove mention of init.texi and init.c.
* Makefile.in: Regenerate.
* bfd-in2.h: Regenerate.
* po/SRC-POTFILES.in: Regenerate.
PR c++/29503 points out that something like "b->Base::member" will
crash when 'b' does not have pointer type. This seems to be a simple
oversight in eval_op_member.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29503
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
In order to get the ifunc relocs properly sorted the correct class
needs to be returned. The code mimics what has been done for AArch64.
Fixes:
FAIL: Run pr18841 with libpr18841b.so
FAIL: Run pr18841 with libpr18841c.so
FAIL: Run pr18841 with libpr18841bn.so (-z now)
FAIL: Run pr18841 with libpr18841cn.so (-z now)
bfd/
PR ld/18841
* elf32-arm.c (elf32_arm_reloc_type_class): Return
reloc_class_ifunc for ifunc symbols.
ld/testsuite/
* ld-arm/ifunc-12.rd: Update relocations order.
* ld-arm/ifunc-3.rd: Likewise.
* ld-arm/ifunc-4.rd: Likewise.
icpx/icx give the following warning if '-g' is used without '-O'.
icpx: remark: Note that use of '-g' without any optimization-level
option will turn off most compiler optimizations similar to use of
'-O0'; use '-Rno-debug-disables-optimization' to disable this
remark [-Rdebug-disables-optimization]
The warning makes dejagnu think that compilation has failed. E.g.:
$ make check TESTS="gdb.cp/local.exp" RUNTESTFLAGS="CXX_FOR_TARGET='icpx' CC_FOR_TARGET=icx"
...
gdb compile failed, icpx: remark: Note that use of '-g' without any optimization-level option will turn off most compiler optimizations similar to use of '-O0'; use '-Rno-debug-disables-optimization' to disable this remark [-Rdebug-disables-optimization]
=== gdb Summary ===
# of untested testcases 1
Furthermore, if no -O flag is passed, icx/icc optimize
the code by default. This breaks assumptions in many GDB tests
that the code is unoptimized by default. E.g.:
$ make check TESTS="gdb.cp/cmpd-minsyms.exp" RUNTESTFLAGS="CXX_FOR_TARGET='icpx' CC_FOR_TARGET=icx"
...
FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at 'GDB<int>::a() const'
FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at 'GDB<int>::b() volatile'
FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at 'GDB<int>::c() const volatile'
FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at GDB<int>::operator ==
FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at GDB<int>::operator==(GDB<int> const&)
FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at GDB<char>::harder(char)
FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at GDB<int>::harder(int)
FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at "int GDB<char>::even_harder<int>(char)"
FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at GDB<int>::simple()
=== gdb Summary ===
# of expected passes 1
# of unexpected failures 9
To fix both problems, pass the -O0 flag explicitly, if no optimization
option is given.
With this patch we get, e.g.:
$ make check TESTS="gdb.cp/cmpd-minsyms.exp gdb.cp/local.exp" RUNTESTFLAGS="CXX_FOR_TARGET='icpx' CC_FOR_TARGET=icx"
...
=== gdb Summary ===
# of expected passes 19
# of known failures 1
Approved-By: Tom Tromey <tom@tromey.com>
