For DWARF5 the zero file list entry in the .debug_line table represents
the compile unit main file. It can be set with .file 0 when -gdwarf-5
is given. But since this directive is illegal for older versions, this
is almost never set. To make sure it is always set (so DW_AT_name of
the compile unit can be set) use file (and dir) 1 if that is defined
(otherwise fall back to pwd, to match DW_AT_comp_dir).
gas/ChangeLog:
* gas/dwarf2dbg.c (out_dir_and_file_list): For DWARF5 emit at
least one directory if there is at least one file. Use dirs[1]
if dirs[0] is not set, or if there is no dirs[1] the current
working directory. Use files[1] filename, when files[0] filename
isn't set.
DWARF5 CU headers have a new unit type field and move the abbrev offset
to the end of the header.
gas/ChangeLog:
* dwarf2dbg.c (out_debug_info): Emit unit type and abbrev offset
for DWARF5.
* gas/testsuite/gas/elf/dwarf-4-cu.d: New file.
* gas/testsuite/gas/elf/dwarf-4-cu.s: Likewise.
* gas/testsuite/gas/elf/dwarf-5-cu.d: Likewise.
* gas/testsuite/gas/elf/dwarf-5-cu.s: Likewise.
* testsuite/gas/elf/elf.exp: Run dwarf-4-cu and dwarf-5-cu.
When reverting commit 9cfd2b89bd "[gdb/testsuite] Fix
gdb.arch/amd64-entry-value-paramref.S", we run into an internal-error:
...
(gdb) file amd64-entry-value-paramref^M
Reading symbols from amd64-entry-value-paramref...^M
src/gdb/dwarf2/read.c:18903: internal-error: could not find partial DIE
0x1b7 in cache [from module amd64-entry-value-paramref]^M
A problem internal to GDB has been detected,^M
further debugging may prove unreliable.^M
...
because of invalid dwarf.
In contrast, when using -readnow, we have:
...
(gdb) file -readnow amd64-entry-value-paramref
Reading symbols from amd64-entry-value-paramref...
Expanding full symbols from amd64-entry-value-paramref...
Dwarf Error: Cannot find DIE at 0x1b7 referenced from DIE at 0x11a \
[in module amd64-entry-value-paramref]
(gdb)
...
Change the internal error into a Dwarf Error, such that we have:
...
(gdb) file amd64-entry-value-paramref^M
Reading symbols from amd64-entry-value-paramref...^M
Dwarf Error: Cannot not find DIE at 0x1b7 \
[from module amd64-entry-value-paramref]^M
^M
(No debugging symbols found in amd64-entry-value-paramref)^M
(gdb)
...
Build and tested on x86_64-linux.
gdb/ChangeLog:
2020-08-04 Tom de Vries <tdevries@suse.de>
PR symtab/23270
* dwarf2/read.c (find_partial_die): Change internal error into Dwarf
Error.
This matches the current set of system calls in the FreeBSD head
development branch as of r363367. Some of these system calls
were also included in 12.1 release.
gdb/ChangeLog:
* syscalls/freebsd.xml: Regenerate.
The MSP430 GAS option "-md" is supposed to indicate that the CRT startup
code should copy data from ROM to RAM at startup. However, this option
has no effect; GAS handles the related behaviour automatically by
looking for the presence of certain symbols in the input file.
gas/ChangeLog:
* config/tc-msp430.c (OPTION_MOVE_DATA): Remove.
(md_parse_option): Remove case for OPTION_MOVE_DATA.
(md_longopts): Remove "md" entry.
(md_show_usage): Likewise.
When reading an exec with a .debug_line section containing a vendor-specific
extended opcode, we get:
...
$ gdb -batch -iex "set complaints 10" dw2-vendor-extended-opcode
During symbol reading: mangled .debug_line section
...
and reading of the .debug_line section is abandoned.
The vendor-specific extended opcode should be ignored, as specified in the
DWARF standard (7.1 Vendor Extensibility). [ FWIW, vendor-specific
standard opcodes are already ignored. ]
Fix this by ignoring all vendor-specific extended opcodes.
Build and tested on x86_64-linux.
gdb/ChangeLog:
2020-08-03 Tom de Vries <tdevries@suse.de>
PR symtab/26333
* dwarf2/read.c (dwarf_decode_lines_1): Ignore
DW_LNE_lo_user/DW_LNE_hi_user range.
gdb/testsuite/ChangeLog:
2020-08-03 Tom de Vries <tdevries@suse.de>
PR symtab/26333
* lib/dwarf.exp (DW_LNE_user): New proc.
* gdb.dwarf2/dw2-vendor-extended-opcode.c: New test.
* gdb.dwarf2/dw2-vendor-extended-opcode.exp: New file.
As far as I can tell, the following comment is false nowadays.
/* Calls to m-alloc get turned by sed into xm-alloc. */
Remove it, and call xmalloc.
* ldlex.l (yy_create_string_buffer): Use xmalloc rather than malloc.
* lexsup.c (parse_args): Likewise.
There are compilation warnings / errors when compiling coremaker2.c
for the gdb.base/corefile2.exp tests. Here's the command to use
on x86_64 linux:
make check RUNTESTFLAGS="--target_board unix/-m32" \
TESTS="gdb.base/corefile2.exp"
These are the warnings / errors - I've shortened the paths somewhat:
gdb compile failed, gdb/testsuite/gdb.base/coremaker2.c: In function 'main':
gdb/testsuite/gdb.base/coremaker2.c:106:11: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
106 | addr = ((unsigned long long) buf_ro + pagesize) & ~(pagesize - 1);
| ^
gdb/testsuite/gdb.base/coremaker2.c:108:15: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
108 | if (addr <= (unsigned long long) buf_ro
| ^
gdb/testsuite/gdb.base/coremaker2.c:109:18: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
109 | || addr >= (unsigned long long) buf_ro + sizeof (buf_ro))
| ^
gdb/testsuite/gdb.base/coremaker2.c:115:19: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
115 | mbuf_ro = mmap ((void *) addr, pagesize, PROT_READ,
| ^
gdb/testsuite/gdb.base/coremaker2.c:130:11: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
130 | addr = ((unsigned long long) buf_rw + pagesize) & ~(pagesize - 1);
| ^
gdb/testsuite/gdb.base/coremaker2.c:132:15: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
132 | if (addr <= (unsigned long long) buf_rw
| ^
gdb/testsuite/gdb.base/coremaker2.c:133:18: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
133 | || addr >= (unsigned long long) buf_rw + sizeof (buf_rw))
| ^
gdb/testsuite/gdb.base/coremaker2.c:139:19: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
139 | mbuf_rw = mmap ((void *) addr, pagesize, PROT_READ,
| ^
These were fixed by changing unsigned long long to uintptr_t.
Tested on either rawhide or Fedora 32 with architectures: x86_64,
x86_64/-m32, aarch64, s390x, and ppc64le.
gdb/testsuite/ChangeLog:
* gdb.base/coremaker2.c: Change all uses of 'unsigned long long'
to 'uintptr_t'
(inttypes.h): Include.
It turns out that the recently added gdb.base/corefile2.exp test won't
run on ppc64le linux. The test case fails the internal checks which
ensure that a mmap'd region can be placed within the statically
allocated regions buf_rw[] and buf_ro[].
ppc64le linux apparently has 64k pages, which is much larger than
the 24k regions originally allocated for buf_rw[] and buf_ro[].
This patch increases the size of each region to 256 KiB.
Tested on either rawhide or Fedora 32 for these architectures: x86_64,
x86_64/-m32, ppc64le, aarch64, and s390x.
gdb/testsuite/ChangeLog:
* gdb.base/coremaker2.c (buf_rw): Increase size to 256 KiB.
(C5_24k): Delete.
(C5_8k, C5_64k, C5_256k): New macros.
(buf_ro): Allocate 256 KiB of initialized data.
LTO can be used to build binutils with
$ CC="gcc -flto -ffat-lto-objects -Wl,--as-needed" CXX="g++ -flto -ffat-lto-objects -Wl,--as-needed" .../configure
But not all linker tests are compatible with LTO. Pass -fno-lto to CC
to disable LTO on linker tests by default. -flto is passed explicitly
to CC in linker LTO tests.
* testsuite/ld-elf/indirect.exp: Append -fno-lto to CC.
* testsuite/ld-elfvers/vers.exp: Likewise.
* testsuite/ld-elfweak/elfweak.exp: Likewise.
* testsuite/ld-ifunc/ifunc.exp: Likewise.
* testsuite/ld-plugin/lto.exp (no_lto): New.
Add $no_lto to build pr15146c.so.
* testsuite/lib/ld-lib.exp (at_least_gcc_version): Filter out
-Wl,xxx options.
(check_gcc_plugin_enabled): Likewise.
(run_ld_link_exec_tests): Prepend -fno-lto to $cflags.
(run_cc_link_tests): Likewise.
gcc -O2 -g -o ar -Wl,--as-needed arparse.o arlex.o ar.o not-ranlib.o arsup.o rename.o binemul.o emul_vanilla.o bucomm.o version.o filemode.o libbfd-2.35-3.fc33.so libiberty.a -Wl,-R,.
All of the above .o files are lto, leading to libbfd-2.35-3.fc33.so
not being found needed when loading the IR objects. That's problem
number one: We exclude IR references when deciding a shared library
is needed. See PR15146. Thus none of the libbfd.so symbols are
loaded before libiberty.a is scanned, and libbfd.so contains copies of
libiberty.a functions. We ought to be using the libbfd.so copies
rather than extracting them from the archive (an object is extracted
even to satisfy IR symbols). After lto recompilation, libbfd.so is of
course found to be needed and loaded. But that causes more problems.
The lto recompilation didn't see symbol references from libbfd.so and
variables like _xexit_cleanup are made local in the recompiled
objects. Oops, two copies of them. Finally, those silly undefined
symbols in the lto output debug files, combined with definitions in
both libbfd.so and IR objects result in IR symbols being made
dynamic.
The main fix here is to revert the PR15146 change to
elf_link_add_object_symbols.
PR 26314
* elflink.c (bfd_elf_link_record_dynamic_symbol): Don't allow
IR symbols to become dynamic.
(elf_link_add_object_symbols): Don't exclude IR symbols when
deciding whether an as-needed shared library is needed.
With this patch, ld/pr24511 test passes for ARC.
At first glance, the test was failing because the order of
"__init_array_start" and "__fini_array_start" weak symbols were
reversed:
$ nm -n dump.out
expected output | real output
00002104 D __init_array_start | 00002104 D __fini_array_start
0000210c D __fini_array_start | 00002104 D __init_array_start
The order of the symbols are different as a side effect of both
symbols being mapped to the _same_ address (0x2104). Looking
further into the mapping logs [1] revealed that the linker
script must consider all instances of ".init_array" (in other
words ".init_array.*") inside its relevant section. Same logic
holds for ".fini_array".
Therefore, adding "KEEP (*(SORT(.init_array.*)))" to the linker
script, along with the one for ".finit_array.*", resolved the
problem. While at it, I took the liberty of refactoring the
script a little bit and made those pieces of script macros.
[1] Linker's mapping for the relevant part of the test
---------------------------------------------------------------
.init_array 0x2104 0x0
0x2104 PROVIDE (__init_array_start = .)
*(.init_array)
[!provide] PROVIDE (__init_array_end = .)
.fini_array 0x2104 0x0
0x2104 PROVIDE (__fini_array_start = .)
*(.fini_array)
[!provide] PROVIDE (__fini_array_end = .)
.data 0x2104 0x0
*(.data .data.* .gnu.linkonce.d.*)
.data 0x2104 0x0 pr24511.o
.init_array.01000
0x2104 0x8
.init_array.01000
0x2104 0x8 pr24511.o
.fini_array.01000
0x210c 0x8
.fini_array.01000
0x210c 0x8 pr24511.o
---------------------------------------------------------------
ld:
* scripttempl/elfarc.sc (.init_array): Keep ".init_array.*".
(.fini_array): Keep ".fini_array.*".
Signed-off-by: Claudiu Zissulescu <claziss@gmail.com>
PR 26318 shows that running `maint print symbols` on an Ada binary,
compiled with an Ada distribution that includes debug info for the
standard library, triggers this assertion:
/home/simark/src/binutils-gdb/gdb/gdbtypes.h:526: internal-error: LONGEST dynamic_prop::const_val() const: Assertion `m_kind == PROP_CONST' failed.
The problem is in particular when printing type
`system__object_reader__decoded_ada_name__TTdecodedSP1___XDL_0`, which
has a dynamic high bound (PROP_LOCLIST kind). When printing a concrete
value of this type, this type gets resolved to a type with a constant
high bound, so ada_modulus can return this constant value.
However, when printing the dynamic range type on its own, such as with
`maint print symbols`, the high bound is still of kind PROP_LOCLIST.
When ada_modulus tries to access the property as a const value, the
assert triggers.
There's no sensible numerical value to return in this case. Ideally,
ada_modulus would return something to the caller indicating that the
value is dynamic and therefore can't be returned as an integer. The
callers would handle it, for example `maint print symbols` would say
that the high bound of the type is dynamic.
However, this patch implements the simpler fix of returning 0 in that
case. It kind of restores the previous behavior of before we validated
the dynamic property kind in the getters, where we would just return
whatever random integer value was in `const_val`. Except now it's
consistently 0.
This is what we had before we added dynamic property getters:
$ ./gdb -q ~/foo -ex "maint expand-symtabs" -ex "maint print symbols" -batch | grep 'typedef <system__object_reader__decoded_ada_name__TTdecodedSP1'
typedef <system__object_reader__decoded_ada_name__TTdecodedSP1: mod 107820865988257;
and this is what we have now:
$ ./gdb -q ~/foo -ex "maint expand-symtabs" -ex "maint print symbols" -batch | grep 'typedef <system__object_reader__decoded_ada_name__TTdecodedSP1'
typedef <system__object_reader__decoded_ada_name__TTdecodedSP1: mod 0;
The value 107820865988257 is the `baton` field of the property's union
interpreted as an integer, so a bogus value.
gdb/ChangeLog:
PR ada/26318
* ada-lang.c (ada_modulus): Return 0 if property is not of const
kind.
Change-Id: I3f6d343a9c3cd7cd62a4fc591943a43541223d50
Apply minor refactoring to 'set_breakpoint_condition'.
gdb/ChangeLog:
2020-07-30 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* breakpoint.c (set_breakpoint_condition): Do minor refactoring.
In 'set_breakpoint_condition', GDB resets the condition expressions
before parsing the condition input by the user. This leads to the
problem of losing the condition expressions if the new condition
does not parse successfully and is thus rejected.
For instance:
$ gdb ./test
Reading symbols from ./test...
(gdb) start
Temporary breakpoint 1 at 0x114e: file test.c, line 4.
Starting program: test
Temporary breakpoint 1, main () at test.c:4
4 int a = 10;
(gdb) break 5
Breakpoint 2 at 0x555555555155: file test.c, line 5.
Now define a condition that would evaluate to false. Next, attempt
to overwrite that with an invalid condition:
(gdb) cond 2 a == 999
(gdb) cond 2 gibberish
No symbol "gibberish" in current context.
(gdb) info breakpoints
Num Type Disp Enb Address What
2 breakpoint keep y 0x0000555555555155 in main at test.c:5
stop only if a == 999
It appears as if the bad condition is successfully rejected. But if we
resume the program, we see that we hit the breakpoint although the condition
would evaluate to false.
(gdb) continue
Continuing.
Breakpoint 2, main () at test.c:5
5 a = a + 1; /* break-here */
Fix the problem by not resetting the condition expressions before
parsing the condition input.
Suppose the fix is applied. A similar problem could occur if the
condition is valid, but has "junk" at the end. In this case, parsing
succeeds, but an error is raised immediately after. It is too late,
though; the condition expression is already updated.
For instance:
$ gdb ./test
Reading symbols from ./test...
(gdb) start
Temporary breakpoint 1 at 0x114e: file test.c, line 4.
Starting program: test
Temporary breakpoint 1, main () at test.c:4
4 int a = 10;
(gdb) break 5
Breakpoint 2 at 0x555555555155: file test.c, line 5.
(gdb) cond 2 a == 999
(gdb) cond 2 a == 10 if
Junk at end of expression
(gdb) info breakpoints
Num Type Disp Enb Address What
2 breakpoint keep y 0x0000555555555155 in main at test.c:5
stop only if a == 999
(gdb) c
Continuing.
Breakpoint 2, main () at test.c:5
5 a = a + 1; /* break-here */
(gdb)
We should not have hit the breakpoint because the condition would
evaluate to false.
Fix this problem by updating the condition expression of the breakpoint
after parsing the input successfully and checking that there is no
remaining junk.
gdb/ChangeLog:
2020-07-30 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* breakpoint.c (set_breakpoint_condition): Update the condition
expressions after checking that the input condition string parses
successfully and does not contain junk at the end.
gdb/testsuite/ChangeLog:
2020-07-30 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.base/condbreak-bad.exp: Extend the test with scenarios
that attempt to overwrite an existing condition with a condition
that fails parsing and also with a condition that parses fine
but contains junk at the end.
The condition of a breakpoint can be set with the 'cond' command. If
the condition has errors that make it problematic to evaluate, it
appears like GDB rejects the condition, but updates the breakpoint's
condition string, which causes incorrect/unintuitive behavior.
For instance:
$ gdb ./test
Reading symbols from ./test...
(gdb) break 5
Breakpoint 1 at 0x1155: file test.c, line 5.
(gdb) cond 1 gibberish
No symbol "gibberish" in current context.
At this point, it looks like the condition was rejected.
But "info breakpoints" shows the following:
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y 0x0000000000001155 in main at test.c:5
stop only if gibberish
Running the code gives the following behavior, where re-insertion of
the breakpoint causes failures.
(gdb) run
Starting program: test
warning: failed to reevaluate condition for breakpoint 1: No symbol "gibberish" in current context.
warning: failed to reevaluate condition for breakpoint 1: No symbol "gibberish" in current context.
warning: failed to reevaluate condition for breakpoint 1: No symbol "gibberish" in current context.
warning: failed to reevaluate condition for breakpoint 1: No symbol "gibberish" in current context.
warning: failed to reevaluate condition for breakpoint 1: No symbol "gibberish" in current context.
[Inferior 1 (process 19084) exited normally]
(gdb)
This broken behavior occurs because GDB updates the condition string
of the breakpoint *before* checking that it parses successfully.
When parsing fails, the update has already taken place.
Fix the problem by updating the condition string *after* parsing the
condition. We get the following behavior when this patch is applied:
$ gdb ./test
Reading symbols from ./test...
(gdb) break 5
Breakpoint 1 at 0x1155: file test.c, line 5.
(gdb) cond 1 gibberish
No symbol "gibberish" in current context.
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y 0x0000000000001155 in main at test.c:5
(gdb) run
Starting program: test
Breakpoint 1, main () at test.c:5
5 a = a + 1; /* break-here */
(gdb) c
Continuing.
[Inferior 1 (process 15574) exited normally]
(gdb)
A side note: The problem does not occur if the condition is given
at the time of breakpoint definition, as in "break 5 if gibberish",
because the parsing of the condition fails during symtab-and-line
creation, before the breakpoint is created.
Finally, the code included the following comment:
/* I don't know if it matters whether this is the string the user
typed in or the decompiled expression. */
This comment did not make sense to me because the condition string is
the user-typed input. The patch updates this comment, too.
gdb/ChangeLog:
2020-07-30 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* breakpoint.c (set_breakpoint_condition): Update the
condition string after parsing the new condition successfully.
gdb/testsuite/ChangeLog:
2020-07-30 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.base/condbreak-bad.c: New test.
* gdb.base/condbreak-bad.exp: New file.
On aarch64 the first PLT entry is 32 bytes, subsequent entries
are 16 bytes by default but can be 24 bytes with BTI or with
PAC-PLT.
sh_entsize of .plt was set to the PLT entry size, so in some
cases sh_size % sh_entsize != 0, which breaks some tools.
Note that PLT0 (and the TLSDESC stub code which is also in the
PLT) were historically not padded up to meet the sh_size
requirement, but to ensure that PLT stub code is aligned on
cache lines. Similar layout is present on other targets too
which just happens to make sh_size a multiple of sh_entsize and
it is not expected that sh_entsize of .plt is used for anything.
This patch sets sh_entsize of .plt to 0: the section does not
hold a table of fixed-size entries so other values are not
conforming in principle to the ELF spec.
bfd/ChangeLog:
PR ld/26312
* elfnn-aarch64.c (elfNN_aarch64_init_small_plt0_entry): Set sh_entsize
to 0.
(elfNN_aarch64_finish_dynamic_sections): Remove sh_entsize setting.
When running test-case gdb.fortran/info-modules.exp with gfortran 4.8.5, I
get:
...
FAIL: gdb.fortran/info-modules.exp: info module functions: \
check for entry 'info-types.f90', '35', \
'void mod1::__copy_mod1_M1t1\(Type m1t1, Type m1t1\);'
FAIL: gdb.fortran/info-modules.exp: info module functions -m mod1: \
check for entry 'info-types.f90', '35', \
'void mod1::__copy_mod1_M1t1\(Type m1t1, Type m1t1\);'
FAIL: gdb.fortran/info-modules.exp: info module variables: \
check for entry 'info-types.f90', '(35)?', \
'Type m1t1 mod1::__def_init_mod1_M1t1;'
FAIL: gdb.fortran/info-modules.exp: info module variables: \
check for entry 'info-types.f90', '(35)?', \
'Type __vtype_mod1_M1t1 mod1::__vtab_mod1_M1t1;'
...
With gfortran 7.5.0, we have:
...
$ readelf -wi info-modules | egrep "DW_AT_name.*(copy|def_init|vtype)_mod1"
<286> DW_AT_name : __def_init_mod1_M1t1
<29f> DW_AT_name : __vtype_mod1_M1t1
<3de> DW_AT_name : __copy_mod1_M1t1
$
...
but with gfortran 4.8.5:
...
$ readelf -wi info-modules | egrep "DW_AT_name.*(copy|def_init|vtype)_mod1"
$
...
Fix this by allowing these module functions and variables to be missing.
Tested on x86_64-linux with gcc 4.8.5 and gcc 7.5.0.
gdb/testsuite/ChangeLog:
2020-07-30 Tom de Vries <tdevries@suse.de>
* lib/sym-info-cmds.exp (GDBInfoModuleSymbols::check_entry_1): Factor
out of ...
(GDBInfoModuleSymbols::check_entry): ... here.
(GDBInfoModuleSymbols::check_optional_entry): New proc.
* gdb.fortran/info-modules.exp: Use check_optional_entry for entries
related to __def_init_mod1_M1t1 / __vtype_mod1_M1t1 / __copy_mod1_M1t1.
GDB currently doesn't build on 32-bit Solaris:
* On Solaris 11.4/x86:
In file included from /usr/include/sys/procfs.h:26,
from /vol/src/gnu/gdb/hg/master/dist/gdb/i386-sol2-nat.c:24:
/usr/include/sys/old_procfs.h:31:2: error: #error "Cannot use procfs in the large file compilation environment"
#error "Cannot use procfs in the large file compilation environment"
^~~~~
* On Solaris 11.3/x86 there are several more instances of this.
The interaction between procfs and large-file support historically has
been a royal mess on Solaris:
* There are two versions of the procfs interface:
** The old ioctl-based /proc, deprecated and not used any longer in
either gdb or binutils.
** The `new' (introduced in Solaris 2.6, 1997) structured /proc.
* There are two headers one can possibly include:
** <procfs.h> which only provides the structured /proc, definining
_STRUCTURED_PROC=1 and then including ...
** <sys/procfs.h> which defaults to _STRUCTURED_PROC=0, the ioctl-based
/proc, but provides structured /proc if _STRUCTURED_PROC == 1.
* procfs and the large-file environment didn't go well together:
** Until Solaris 11.3, <sys/procfs.h> would always #error in 32-bit
compilations when the large-file environment was active
(_FILE_OFFSET_BITS == 64).
** In both Solaris 11.4 and Illumos, this restriction was lifted for
structured /proc.
So one has to be careful always to define _STRUCTURED_PROC=1 when
testing for or using <sys/procfs.h> on Solaris. As the errors above
show, this isn't always the case in binutils-gdb right now.
Also one may need to disable large-file support for 32-bit compilations
on Solaris. config/largefile.m4 meant to do this by wrapping the
AC_SYS_LARGEFILE autoconf macro with appropriate checks, yielding
ACX_LARGEFILE. Unfortunately the macro doesn't always succeed because
it neglects the _STRUCTURED_PROC part.
To make things even worse, since GCC 9 g++ predefines
_FILE_OFFSET_BITS=64 on Solaris. So even if largefile.m4 deciced not to
enable large-file support, this has no effect, breaking the gdb build.
This patch addresses all this as follows:
* All tests for the <sys/procfs.h> header are made with
_STRUCTURED_PROC=1, the definition going into the various config.h
files instead of having to make them (and sometimes failing) in the
affected sources.
* To cope with the g++ predefine of _FILE_OFFSET_BITS=64,
-U_FILE_OFFSET_BITS is added to various *_CPPFLAGS variables. It had
been far easier to have just
#undef _FILE_OFFSET_BITS
in config.h, but unfortunately such a construct in config.in is
commented by config.status irrespective of indentation and whitespace
if large-file support is disabled. I found no way around this and
putting the #undef in several global headers for bfd, binutils, ld,
and gdb seemed way more invasive.
* Last, the applicability check in largefile.m4 was modified only to
disable largefile support if really needed. To do so, it checks if
<sys/procfs.h> compiles with _FILE_OFFSET_BITS=64 defined. If it
doesn't, the disabling only happens if gdb exists in-tree and isn't
disabled, otherwise (building binutils from a tarball), there's no
conflict.
What initially confused me was the check for $plugins here, which
originally caused the disabling not to take place. Since AC_PLUGINGS
does enable plugin support if <dlfcn.h> exists (which it does on
Solaris), the disabling never happened.
I could find no explanation why the linker plugin needs large-file
support but thought it would be enough if gld and GCC's lto-plugin
agreed on the _FILE_OFFSET_BITS value. Unfortunately, that's not
enough: lto-plugin uses the simple-object interface from libiberty,
which includes off_t arguments. So to fully disable large-file
support would mean also disabling it in libiberty and its users: gcc
and libstdc++-v3. This seems highly undesirable, so I decided to
disable the linker plugin instead if large-file support won't work.
The patch allows binutils+gdb to build on i386-pc-solaris2.11 (both
Solaris 11.3 and 11.4, using GCC 9.3.0 which is the worst case due to
predefined _FILE_OFFSET_BITS=64). Also regtested on
amd64-pc-solaris2.11 (again on Solaris 11.3 and 11.4),
x86_64-pc-linux-gnu and i686-pc-linux-gnu.
config:
* largefile.m4 (ACX_LARGEFILE) <sparc-*-solaris*|i?86-*-solaris*>:
Check for <sys/procfs.h> incompatilibity with large-file support
on Solaris.
Only disable large-file support and perhaps plugins if needed.
Set, substitute LARGEFILE_CPPFLAGS if so.
bfd:
* bfd.m4 (BFD_SYS_PROCFS_H): New macro.
(BFD_HAVE_SYS_PROCFS_TYPE): Require BFD_SYS_PROCFS_H.
Don't define _STRUCTURED_PROC.
(BFD_HAVE_SYS_PROCFS_TYPE_MEMBER): Likewise.
* elf.c [HAVE_SYS_PROCFS_H] (_STRUCTURED_PROC): Don't define.
* configure.ac: Use BFD_SYS_PROCFS_H to check for <sys/procfs.h>.
* configure, config.in: Regenerate.
* Makefile.am (AM_CPPFLAGS): Add LARGEFILE_CPPFLAGS.
* Makefile.in, doc/Makefile.in: Regenerate.
binutils:
* Makefile.am (AM_CPPFLAGS): Add LARGEFILE_CPPFLAGS.
* Makefile.in, doc/Makefile.in: Regenerate.
* configure: Regenerate.
gas:
* Makefile.am (AM_CPPFLAGS): Add LARGEFILE_CPPFLAGS.
* Makefile.in, doc/Makefile.in: Regenerate.
* configure: Regenerate.
gdb:
* proc-api.c (_STRUCTURED_PROC): Don't define.
* proc-events.c: Likewise.
* proc-flags.c: Likewise.
* proc-why.c: Likewise.
* procfs.c: Likewise.
* Makefile.in (INTERNAL_CPPFLAGS): Add LARGEFILE_CPPFLAGS.
* configure, config.in: Regenerate.
gdbserver:
* configure, config.in: Regenerate.
gdbsupport:
* Makefile.am (AM_CPPFLAGS): Add LARGEFILE_CPPFLAGS.
* common.m4 (GDB_AC_COMMON): Use BFD_SYS_PROCFS_H to check for
<sys/procfs.h>.
* Makefile.in: Regenerate.
* configure, config.in: Regenerate.
gnulib:
* configure.ac: Run ACX_LARGEFILE before gl_EARLY.
* configure: Regenerate.
gprof:
* Makefile.am (AM_CPPFLAGS): Add LARGEFILE_CPPFLAGS.
* Makefile.in: Regenerate.
* configure: Regenerate.
ld:
* Makefile.am (AM_CPPFLAGS): Add LARGEFILE_CPPFLAGS.
* Makefile.in: Regenerate.
* configure: Regenerate.
When running test-case gdb.fortran/ptype-on-functions.exp with gfortran 4.8.5,
we run into:
...
(gdb) ptype some_module::get_number^M
type = integer(kind=4) (Type __class_some_module_Number)^M
(gdb) FAIL: gdb.fortran/ptype-on-functions.exp: ptype some_module::get_number
ptype some_module::set_number^M
type = void (Type __class_some_module_Number, integer(kind=4))^M
(gdb) FAIL: gdb.fortran/ptype-on-functions.exp: ptype some_module::set_number
...
The test-case pattern expects a "_t" suffix on "__class_some_module_Number".
The difference is caused by a gcc commit 073afca6884 'class.c
(gfc_build_class_symbol): Append "_t" to target class names to make the
generated type names unique' which has been present since gcc 4.9.0.
Fix the pattern by optionally matching the _t suffix.
Tested on x86_64-linux, with gfortran 4.8.5 and 7.5.0.
gdb/testsuite/ChangeLog:
2020-07-30 Tom de Vries <tdevries@suse.de>
* gdb.fortran/ptype-on-functions.exp: Make "_t" suffix on
"__class_some_module_Number_t" optional.
When building CFLAGS/CXXFLAGS="-O2 -g -Wall" and gcc 4.8.5, we run into:
...
src/gdb/cli/cli-style.c:154:42: warning: '*((void*)&<anonymous> +8)' \
may be used uninitialized in this function [-Wmaybe-uninitialized]
src/gdb/cli/cli-style.c:154:42: warning: '*((void*)&<anonymous> +9)' \
may be used uninitialized in this function [-Wmaybe-uninitialized]
src/gdb/cli/cli-style.c:154:42: warning: '*((void*)&<anonymous> +10)' \
may be used uninitialized in this function [-Wmaybe-uninitialized]
...
The root cause is that the data members of class color, nested in struct
ui_file_style in gdb/ui-style.h:
...
bool m_simple;
int m_value;
uint8_t m_red, m_green, m_blue;
...
are only partially initialized by this constructor:
...
color (int c)
: m_simple (true),
m_value (c)
{
gdb_assert (c >= -1 && c <= 255);
}
...
but the default copy constructor will copy all the fields.
The member m_simple acts as a discriminant, to indicate which other members
are valid:
- m_value (with m_simple == true)
- m_red, m_green, m_blue (with m_simple == false)
So, we don't need storage for both m_value and m_red/m_green/m_blue at the
same time.
Fix this by wrapping the respective members in a union:
...
bool m_simple;
union
{
int m_value;
struct
{
uint8_t m_red, m_green, m_blue;
};
};
...
which also fixes the warning.
Build and reg-tested on x86_64-linux.
gdb/ChangeLog:
2020-07-30 Tom de Vries <tdevries@suse.de>
PR build/26320
* ui-style.h (struct ui_file_style::color): Wrap m_value and
m_red/m_green/m_blue in a union.
I ran
for i in $(find . -name configure.ac); do pushd $(dirname $i); autoreconf -vf; popd; done
to re-generate all automake/autoconf files throughout the repo (with
upstream autoconf 2.69 and automake 1.15.1). These were the changes
that came out. I am pushing this as obvious.
libdecnumber/ChangeLog:
* aclocal.m4, configure: Re-generate.
sim/bfin/ChangeLog:
* aclocal.m4, configure: Re-generate.
sim/erc32/ChangeLog:
* configure: Re-generate.
sim/mips/ChangeLog:
* configure: Re-generate.
sim/testsuite/ChangeLog:
* configure: Re-generate.
Change-Id: I97335c09972d25cc5f6fd8da4db4ffe4a0348787
Make the MIPS/IRIX naming of local section symbols consistent between
files produced by generic ELF code and ELF linker code, complementing
commit 174fd7f955 ("New bfd elf hook: force naming of local section
symbols"), <https://sourceware.org/ml/binutils/2004-02/msg00072.html>.
Local section symbols have no names in the standard ELF gABI, however
the lack of a name causes problems with IRIX's MIPSpro linker. To work
around the issue we give them names, however we do that in generic ELF
code only, based on what the `elf_backend_name_local_section_symbols'
hook returns if present. That makes objects created by GAS or `objdump'
work correctly, however not ones created by `ld -r'. That would not
normally cause issues with IRIX systems using GAS and `objdump' only
with the MIPSpro linker, however if GNU LD was used for whatever reason
in producing objects later fed to IRIX's MIPSpro linker, then things
would break.
Modify ELF linker code accordingly then, using the same hook. Adjust
the `ld-elf/64ksec-r' test accordingly so that it also accepts a section
symbol with a name.
Also modify the hook itself so that only actual ET_REL objects have
names assigned to local section symbols. Other kinds of ELF files are
not ever supposed to be relocated with the MIPSpro linker, so we can
afford producing more standard output.
Add suitable GAS, LD and `objcopy' test cases to the relevant testsuites
to keep these tools consistently verified. This change also fixes:
FAIL: objcopy executable (pr25662)
across MIPS targets using the IRIX compatibility mode.
bfd/
* elflink.c (bfd_elf_final_link): Give local symbols a name if
so requested.
* elfxx-mips.c (_bfd_mips_elf_name_local_section_symbols): Only
return TRUE if making ET_REL output.
binutils/
* testsuite/binutils-all/mips/global-local-symtab-sort-o32.d:
New test.
* testsuite/binutils-all/mips/global-local-symtab-sort-o32t.d:
New test.
* testsuite/binutils-all/mips/global-local-symtab-sort-n32.d:
New test.
* testsuite/binutils-all/mips/global-local-symtab-sort-n32t.d:
New test.
* testsuite/binutils-all/mips/global-local-symtab-sort-n64.d:
New test.
* testsuite/binutils-all/mips/global-local-symtab-sort-n64t.d:
New test.
* testsuite/binutils-all/mips/global-local-symtab-final-o32.d:
New test.
* testsuite/binutils-all/mips/global-local-symtab-final-n32.d:
New test.
* testsuite/binutils-all/mips/global-local-symtab-final-n64.d:
New test.
* testsuite/binutils-all/mips/mips.exp: Run the new tests.
gas/
* testsuite/gas/mips/global-local-symtab-sort-o32.d: New test.
* testsuite/gas/mips/global-local-symtab-sort-o32t.d: New test.
* testsuite/gas/mips/global-local-symtab-sort-n32.d: New test.
* testsuite/gas/mips/global-local-symtab-sort-n32t.d: New test.
* testsuite/gas/mips/global-local-symtab-sort-n64.d: New test.
* testsuite/gas/mips/global-local-symtab-sort-n64t.d: New test.
* testsuite/gas/mips/mips.exp: Run the new tests.
ld/
* testsuite/ld-elf/sec64k.exp: Also accept a section symbol with
a name.
* testsuite/ld-mips-elf/global-local-symtab-sort-o32.d: New
test.
* testsuite/ld-mips-elf/global-local-symtab-sort-o32t.d: New
test.
* testsuite/ld-mips-elf/global-local-symtab-sort-n32.d: New
test.
* testsuite/ld-mips-elf/global-local-symtab-sort-n32t.d: New
test.
* testsuite/ld-mips-elf/global-local-symtab-sort-n64.d: New
test.
* testsuite/ld-mips-elf/global-local-symtab-sort-n64t.d: New
test.
* testsuite/ld-mips-elf/global-local-symtab-final-o32.d: New
test.
* testsuite/ld-mips-elf/global-local-symtab-final-n32.d: New
test.
* testsuite/ld-mips-elf/global-local-symtab-final-n64.d: New
test.
* testsuite/ld-mips-elf/mips-elf.exp: Run the new tests.
Correct ELF linker code so as to set the `sh_info' value of the static
symbol table section according to the section symbols vs other symbols
split where required by the selection of the IRIX compatibility mode for
MIPS target. Add a `elf_backend_elfsym_local_is_section' hook for that
purpose, returning TRUE if it is only STB_LOCAL/STT_SECTION symbols that
are to be considered local for the purpose of this split rather than all
STB_LOCAL symbols.
We do it already in generic ELF code, and have done it since 1993, with
the `elf_backend_sym_is_global' hook, affecting GAS and `objcopy', so
these tools produce correct ELF output in the IRIX compatibility mode,
however if such output is fed as input to `ld -r', then the linker's
output is no longer valid for that mode. The relevant changes to
generic ELF code are:
commit 062189c6ea
Author: Ian Lance Taylor <ian@airs.com>
Date: Thu Nov 18 17:12:47 1993 +0000
and:
commit 6e07e54f1b
Author: Ian Lance Taylor <ian@airs.com>
Date: Thu Jan 6 20:01:42 1994 +0000
(split across two GIT commits likely due to repository conversion
peculiarities).
The `elf_backend_sym_is_global' hook however operates on BFD rather than
ELF symbols, making it unsuitable for the ELF linker as the linker does
not convert any symbol tables processed into the BFD format. Converting
the hook to operate on ELF symbols would in principle be possible, but
it would still require a considerable rewrite of `bfd_elf_final_link' to
adapt to the interface.
Therefore, especially given that no new use for the IRIX compatibility
mode is expected, minimize changes made to the ELF linker code and just
add an entirely new hook, and wire it in the o32 and n32 MIPS backends
accordingly; the n64 backend never uses the IRIX compatibility mode.
Since we have no coverage here at all add suitable GAS, LD and `objcopy'
test cases to the relevant testsuites to keep these tools consistently
verified.
bfd/
* elf-bfd.h (elf_backend_data): Add
`elf_backend_elfsym_local_is_section' member.
* elfxx-target.h (elf_backend_elfsym_local_is_section): New
macro.
(elfNN_bed): Add `elf_backend_elfsym_local_is_section' member.
* elflink.c (bfd_elf_final_link): Use it to determine whether
set the `.symtab' section's `sh_info' value to the index of the
first non-local or non-section symbol.
* elf32-mips.c (mips_elf32_elfsym_local_is_section): New
function.
(elf_backend_elfsym_local_is_section): New macro.
* elfn32-mips.c (mips_elf_n32_elfsym_local_is_section): New
function.
(elf_backend_elfsym_local_is_section): New macro.
binutils/
* testsuite/binutils-all/mips/global-local-symtab-o32.d: New
test.
* testsuite/binutils-all/mips/global-local-symtab-o32t.d: New
test.
* testsuite/binutils-all/mips/global-local-symtab-n32.d: New
test.
* testsuite/binutils-all/mips/global-local-symtab-n32t.d: New
test.
* testsuite/binutils-all/mips/global-local-symtab-n64.d: New
test.
* testsuite/binutils-all/mips/mips.exp: Run the new tests.
gas/
* testsuite/gas/mips/global-local-symtab-o32.d: New test.
* testsuite/gas/mips/global-local-symtab-o32t.d: New test.
* testsuite/gas/mips/global-local-symtab-n32.d: New test.
* testsuite/gas/mips/global-local-symtab-n32t.d: New test.
* testsuite/gas/mips/global-local-symtab-n64.d: New test.
* testsuite/gas/mips/global-local-symtab.s: New test source.
* testsuite/gas/mips/mips.exp: Run the new tests.
ld/
* testsuite/ld-mips-elf/global-local-symtab-o32.d: New test.
* testsuite/ld-mips-elf/global-local-symtab-o32t.d: New test.
* testsuite/ld-mips-elf/global-local-symtab-n32.d: New test.
* testsuite/ld-mips-elf/global-local-symtab-n32t.d: New test.
* testsuite/ld-mips-elf/global-local-symtab-n64.d: New test.
* testsuite/ld-mips-elf/global-local-symtab.ld: New test linker
script.
* testsuite/ld-mips-elf/mips-elf.exp: Run the new tests.
In s390-mkopc.c, the function insertExpandedMnemonic() searches for the
first occurrence of '*' or '$' in the given mnemonic, and, if a match is
found, chooses an extension table using a switch() on that character. The
switch statement contains a default case that prints an error message and
does not set the extension table. Although this case cannot occur, some
GCC versions obviously conclude that the extension table might have been
left uninitialized after the switch statement and consequently emit
maybe-uninitialized warnings for the variables 'ext_table' and
'ext_table_length'.
Circumvent the warning by handling the unreachable default case with
abort().
opcodes/
* s390-mkopc.c (insertExpandedMnemonic): Handle unreachable
default case with abort() instead of printing an error message and
continuing, to avoid a maybe-uninitialized warning.
When building gcc with CFLAGS/CXXFLAGS="-O2 -g", and running the regression
tests, I run into the following FAILs:
...
FAIL: gdb.gdb/complaints.exp: breakpoint in captured_command_loop
FAIL: gdb.gdb/python-interrupts.exp: breakpoint in captured_command_loop
FAIL: gdb.gdb/python-selftest.exp: breakpoint in captured_command_loop
...
The problem is that when setting the breakpoint at captured_command_loop:
...
(gdb) break captured_command_loop^M
Breakpoint 1 at 0x4230ed: captured_command_loop. (2 locations)^M
(gdb) FAIL: gdb.gdb/complaints.exp: breakpoint in captured_command_loop
...
there are two breakpoint locations instead of one. This is due to
PR26096 - "gdb sets breakpoint at cold clone":
...
$ nm gdb | grep captured_command_loop| c++filt
0000000000659f20 t captured_command_loop()
00000000004230ed t captured_command_loop() [clone .cold]
...
Work around this by allowing multiple breakpoint locations for
captured_command_loop.
Reg-tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-07-29 Tom de Vries <tdevries@suse.de>
* lib/selftest-support.exp (selftest_setup): Allow breakpoint at
multiple locations.
We get lots of errors before we get to this code, but let's not
segfault.
* elflink.c (bfd_elf_final_link): Don't segfault on local dynsyms
defined in excluded sections.
When excluding SHF_LINK_ORDER sections that happen to have SEC_KEEP
set, we need to set SEC_EXCLUDE here to avoid a problem later.
* ldelf.c (ldelf_before_place_orphans): Set SEC_EXCLUDE for
discarded sections.
When building gdb with CFLAGS/CXXFLAGS="-O2 -g -Wall", I see:
...
src/gdb/s390-tdep.c: In function 'void s390_displaced_step_fixup(gdbarch*, \
displaced_step_closure*, CORE_ADDR, CORE_ADDR, regcache*)':
src/gdb/s390-tdep.c:528:30: warning: 'r2' may be used uninitialized in this \
function [-Wmaybe-uninitialized]
528 | if (insn[0] == op_basr && r2 == 0)
| ~~~~~~~~~~~~~~~~~~~^~~~~~~~~~
...
The problem is that the compiler is unaware that
'is_rr (insn, op_basr, &r1, &r2) == 1' ensures that 'insn[0] == op_basr':
...
if (is_rr (insn, op_basr, &r1, &r2)
|| is_rx (insn, op_bas, &r1, &d2, &x2, &b2))
{
/* Recompute saved return address in R1. */
regcache_cooked_write_unsigned (regs, S390_R0_REGNUM + r1,
amode | (from + insnlen));
/* Update PC iff the instruction doesn't actually branch. */
if (insn[0] == op_basr && r2 == 0)
regcache_write_pc (regs, from + insnlen);
}
...
Fix this by storing the result of the call, and using it instead of
'insn[0] ==op_basr'.
Build on x86_64-linux with --enable-targets=s390-suse-linux,s390x-suse-linux.
gdb/ChangeLog:
2020-07-29 Tom de Vries <tdevries@suse.de>
PR tdep/26280
* s390-tdep.c (s390_displaced_step_fixup): Fix Wmaybe-uninitialized.
On aarch64, there are FAILs for gdb.dwarf2/dw2-line-number-zero.exp due to
problems in the prologue analyzer (filed as PR26310).
Make the test-case more robust by avoiding to use the prologue analyzer:
...
-gdb_breakpoint "bar1"
+gdb_breakpoint "$srcfile:27"
...
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-07-29 Tom de Vries <tdevries@suse.de>
* gdb.dwarf2/dw2-line-number-zero.exp: Set breakpoints on lines
rather than function name.
