Commit Graph

99267 Commits

Author SHA1 Message Date
Tom de Vries
405feb71d4 [gdb] Fix typos in comments
Fix typos in comments.  NFC.

Tested on x86_64-linux.

gdb/ChangeLog:

2019-10-17  Tom de Vries  <tdevries@suse.de>

	* arm-nbsd-nat.c: Fix typos in comments.
	* arm-tdep.c: Same.
	* darwin-nat-info.c: Same.
	* dwarf2read.c: Same.
	* elfread.c: Same.
	* event-top.c: Same.
	* findvar.c: Same.
	* gdbtypes.c: Same.
	* hppa-tdep.c: Same.
	* i386-tdep.c: Same.
	* jit.c: Same.
	* main.c: Same.
	* mdebugread.c: Same.
	* moxie-tdep.c: Same.
	* nto-procfs.c: Same.
	* osabi.c: Same.
	* ppc-linux-tdep.c: Same.
	* remote.c: Same.
	* riscv-tdep.c: Same.
	* s390-tdep.c: Same.
	* sh-tdep.c: Same.
	* sparc-linux-tdep.c: Same.
	* sparc-nat.c: Same.
	* stack.c: Same.
	* target-descriptions.c: Same.
	* top.c: Same.
	* varobj.c: Same.

Change-Id: I6047967abd2d51c9000dea15184d19f4e952c3ff
2019-10-17 18:06:36 +02:00
Tom de Vries
062f1fc13a [gdb/testsuite] Fix gdb.fortran/module.exp for debug info from other files
On openSUSE Leap 15.1, I get:
...
FAIL: gdb.fortran/module.exp: info variables -n
...
because the info variables command prints info also for init.c:
...
File init.c:^M
24:     const int _IO_stdin_used;^M
...
while the regexps in the test-case only expect info for module.f90.

Fix this by extending the regexps.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2019-10-17  Tom de Vries  <tdevries@suse.de>

	* gdb.fortran/module.exp: Allow info variables to print info for files
	other than module.f90.

Change-Id: I401d8018b121fc7343f6bc8b671900349462457f
2019-10-17 10:07:05 +02:00
Alan Modra
a315e14713 PR29, Coreutils POSIX2_VERSION as 200112L
As of today we have just the following oddities left
./gnulib/update-gnulib.sh:ver=`autoconf --version 2>&1 | head -1 | sed 's/.*) //'`
./gnulib/update-gnulib.sh:ver=`automake --version 2>&1 | head -1 | sed 's/.*) //'`
./gnulib/update-gnulib.sh:ver=`aclocal --version 2>&1 | grep -v "called too early to check prototype" | head -1 | sed 's/.*) //'`
./src-release.sh:	head -1 $tool/version.in
./contrib/dg-extract-results.sh:tail -2 $FIRST_SUM | $GREP '^#' > /dev/null || tail -2 $FIRST_SUM

gnulib and contrib (from gcc) are outside of binutils control, so with
this patch I'm going to declare this 15 year old bug fixed.

	PR 29
	* src-release.sh (getver): Replace "head -1" with "head -n 1".
2019-10-17 16:34:02 +10:30
Tom Tromey
befcd486f4 Constify objfile::original_name
I noticed that objfile::original_name could be a "const char *" rather
than a plain "char *".  This patch implements this change.  Tested by
rebuilding.

gdb/ChangeLog
2019-10-16  Tom Tromey  <tom@tromey.com>

	* objfiles.h (struct objfile) <original_name>: Now const.
2019-10-16 20:44:21 -06:00
GDB Administrator
611fa2f46c Automatic date update in version.in 2019-10-17 00:00:23 +00:00
Andrew Burgess
0b54364d92 gdb/fortran: Add test for module variables in 'info variables' output
Recent work from Tom Tromey to better handle variables with associated
copy relocations has fixed a Fortran issue where module variables
wouldn't show up in the output of 'info variables'.

This commit adds a test for this functionality to ensure it doesn't
get broken in the future.

gdb/testsuite/ChangeLog:

	* gdb.fortran/module.exp: Extend with 'info variables' test.

Change-Id: I7306b1d0a9a72947fd48ad7a03f49df774d6573b
2019-10-16 22:22:09 +01:00
Andrew Burgess
7ff5fae704 gdb/testsuite: Allow cc-with-tweaks board file to be used with Fortran
The board file cc-with-tweaks is used as the core for lots of other
board files, for example cc-with-gdb-index and cc-with-debug-names.
This commit extends cc-with-tweaks so that it will wrap the Fortran
compiler, allowing for more test coverage.

I tested all of the board files that make use of cc-with-tweaks
running the gdb.fortran/*.exp test set, and in some cases I did see
extra failures.  The "standard" results are:

                    === gdb Summary ===

    # of expected passes            953
    # of known failures             2

With board file 'cc-with-dwz-m':

                    === gdb Summary ===

    # of expected passes            903
    # of unexpected failures        1
    # of known failures             2
    # of untested testcases         4

With board file 'dwarf4-gdb-index':

                    === gdb Summary ===

    # of expected passes            950
    # of unexpected failures        3
    # of known failures             2

With board file 'fission-dwp':

                    === gdb Summary ===

    # of expected passes            949
    # of unexpected failures        4
    # of known failures             2

Despite these extra failure I don't think this should prevent this
change going in as these failures presumably already exist in GDB.

gdb/testsuite/ChangeLog:

	* boards/cc-with-tweaks.exp: Setup F90_FOR_TARGET and
	F77_FOR_TARGET.

Change-Id: I06d412f94d0e119ad652dd6c20829f6705a54622
2019-10-16 22:22:09 +01:00
Christian Biesinger
17bfe554b9 Allow not saving the signal state in SIGSETJMP
Saving the signal state is very slow (this patch is a 14% speedup).  The
reason we need this code is because signal handler will leave the
signal blocked when we longjmp out of it.  But in this case we can
just manually unblock the signal instead of taking the unconditional
perf hit.

gdb/ChangeLog:

2019-10-16  Christian Biesinger  <cbiesinger@google.com>

	* gdbsupport/gdb_setjmp.h (SIGSETJMP): Allow passing in the value to
	pass on to sigsetjmp's second argument.
	* cp-support.c (gdb_demangle): Unblock SIGSEGV if we caught a crash.

Change-Id: Ib3010966050c64b4cc8b47d8cb45871652b0b3ea
2019-10-16 16:13:43 -05:00
Keith Seitz
950b74950f DWARF reader: Reject sections with invalid sizes
This is another fuzzer bug, gdb/23567.  This time, the fuzzer has
specifically altered the size of .debug_str:

$ eu-readelf -S objdump
Section Headers:
[Nr] Name                 Type         Addr             Off      Size     ES Flags Lk Inf Al
[31] .debug_str           PROGBITS     0000000000000000 0057116d ffffffffffffffff  1 MS     0   0  1

When this file is loaded into GDB, the DWARF reader crashes attempting
to access the string table (or it may just store a bunch of nonsense):

[gdb-8.3-6-fc30]
$ gdb -nx -q objdump
BFD: warning: /path/to/objdump has a corrupt section with a size (ffffffffffffffff) larger than the file size
Reading symbols from /path/to/objdump...
Segmentation fault (core dumped)

Nick has already committed a BFD patch to issue the warning seen above.

[gdb master 6acc1a0b]
$ gdb -BFD: warning: /path/to/objdump has a corrupt section with a size (ffffffffffffffff) larger than the file size
Reading symbols from /path/to/objdump...
(gdb) inf func
All defined functions:

File ./../include/dwarf2.def:
186:	const

              8 *>(.:
                     ;'@�B);
747:	const

              8 *�(.:
                     ;'@�B);
701:	const

              8 *�D �
                     (.:
                        ;'@�B);
71:	const

              8 *(.:
                    ;'@�B);
/* and more gibberish  */

Consider read_indirect_string_at_offset_from:

static const char *
read_indirect_string_at_offset_from (struct objfile *objfile,
                                     bfd *abfd, LONGEST str_offset,
                                     struct dwarf2_section_info *sect,
                                     const char *form_name,
                                     const char *sect_name)
{
  dwarf2_read_section (objfile, sect);
  if (sect->buffer == NULL)
    error (_("%s used without %s section [in module %s]"),
           form_name, sect_name, bfd_get_filename (abfd));
  if (str_offset >= sect->size)
    error (_("%s pointing outside of %s section [in module %s]"),
           form_name, sect_name, bfd_get_filename (abfd));
  gdb_assert (HOST_CHAR_BIT == 8);
  if (sect->buffer[str_offset] == '\0')
    return NULL;
  return (const char *) (sect->buffer + str_offset);
}

With sect_size being ginormous, the code attempts to access
sect->buffer[GINORMOUS], and depending on the layout of memory,
GDB either stores a bunch of gibberish strings or crashes.

This is an attempt to mitigate this by implementing a similar approach
used by BFD. In our case, we simply reject the section with the invalid
length:

$ ./gdb -nx -q objdump
BFD: warning: /path/to/objdump has a corrupt section with a size (ffffffffffffffff) larger than the file size
Reading symbols from /path/to/objdump...

warning: Discarding section .debug_str which has a section size (ffffffffffffffff) larger than the file size [in module /path/to/objdump]
DW_FORM_strp used without .debug_str section [in module /path/to/objdump]
(No debugging symbols found in /path/to/objdump)
(gdb)

Unfortunately, I have not found a way to regression test this, since it
requires poking ELF section headers.

gdb/ChangeLog:
2019-10-16  Keith Seitz  <keiths@redhat.com>

	PR gdb/23567
	* dwarf2read.c (dwarf2_per_objfile::locate_sections): Discard
	sections whose size is greater than the file size.

Change-Id: I896ac3b4eb2207c54e8e05c16beab3051d9b4b2f
2019-10-16 11:35:16 -07:00
Jim Wilson
ff371ec999 Add initial compile command support to RISC-V port.
This adds initial compile command support to the RISC-V port.  This fixes
about 228 testsuite failures on a riscv64-linux machine.  We need to get
the triplet right which is normally riscv64 or riscv32 instead of the
default riscv.  Also, we need to get the compiler options right, since we
don't accept the default -m64 and -mcmodel=large options, so we need to
construct -march and -mabi options which are correct for the target.  We
currently don't have info about all extensions used by the target, so this
may need to be adjusted later.  For now, I'm assuming that we have all
extensions required by the linux platform spec.

	gdb/
	* riscv-tdep.c (riscv_gcc_target_options): New.
	(riscv_gnu_triplet_regexp): New.
	(riscv_gdbarch_init): Call set_gdbarch_gcc_triplet_options and
	set_gdbarch_gnu_triplet_regexp.

Change-Id: I315ce8de7789ddf7bdd3b532f917519464941294
2019-10-16 10:58:37 -07:00
Christian Biesinger
fec4e896d6 Create xml-builtin.h to declare xml_builtins
xml-builtin.c only has character arrays and no dependencies, so this
creates a simple header file for that purpose so that gdbserver
can include that instead of re-declaring xml_builtin.

Despite the name, feature_to_c.sh is already specific to xml_builtins
(it hardcodes the variable name), so making it always output the
include for xml-builtin.h seems fine.

gdb/ChangeLog:

2019-10-16  Christian Biesinger  <cbiesinger@google.com>

	* Makefile.in: Add xml-builtin.h.
	* features/feature_to_c.sh: Add an include for xml-builtin.h
	to ensure that the compiler checks that the types match.
	* xml-builtin.h: New file.
	* xml-support.c (fetch_xml_builtin): Add missing const.
	* xml-support.h: Remove declaration of xml_builtins.

gdb/gdbserver/ChangeLog:

2019-10-16  Christian Biesinger  <cbiesinger@google.com>

	* server.c: Include xml-builtin.h.
	(get_xml_features): Don't declare xml_builtins here.

Change-Id: I806ef0851c43ead90b545a11794e41f5e5178436
2019-10-16 18:19:14 +02:00
Simon Marchi
cbbbc402e0 libctf: mark swap.h inline functions as static
When building binutils with mingw-w64, I get the following errors:

    make[4]: Entering directory '/home/simark/build/binutils-gdb-mingw/binutils'
    /bin/sh ./libtool  --tag=CC   --mode=link ccache x86_64-w64-mingw32-gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 -Wno-format -Werror -I/home/simark/src/binutils-gdb/binutils/../zlib -g3 -O0 -D__USE_MINGW_ACCESS  -Wl,--stack,12582912 -o objdump.exe objdump.o dwarf.o prdbg.o rddbg.o debug.o stabs.o rdcoff.o bucomm.o version.o filemode.o elfcomm.o  ../opcodes/libopcodes.la ../libctf/libctf.la ../bfd/libbfd.la ../libiberty/libiberty.a -lintl
    libtool: link: ccache x86_64-w64-mingw32-gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 -Wno-format -Werror -I/home/simark/src/binutils-gdb/binutils/../zlib -g3 -O0 -D__USE_MINGW_ACCESS -Wl,--stack -Wl,12582912 -o .libs/objdump.exe objdump.o dwarf.o prdbg.o rddbg.o debug.o stabs.o rdcoff.o bucomm.o version.o filemode.o elfcomm.o  ../opcodes/.libs/libopcodes.a ../libctf/.libs/libctf.a -L/home/simark/build/binutils-gdb-mingw/zlib ../bfd/.libs/libbfd.a -lz ../libiberty/libiberty.a -lintl
    /usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: ../libctf/.libs/libctf.a(ctf-open.o): in function `flip_header':
    /home/simark/src/binutils-gdb/libctf/ctf-open.c:964: undefined reference to `bswap_16'
    /usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: /home/simark/src/binutils-gdb/libctf/ctf-open.c:967: undefined reference to `bswap_32'
    /usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: /home/simark/src/binutils-gdb/libctf/ctf-open.c:968: undefined reference to `bswap_32'
    /usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: /home/simark/src/binutils-gdb/libctf/ctf-open.c:969: undefined reference to `bswap_32'
    /usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: /home/simark/src/binutils-gdb/libctf/ctf-open.c:970: undefined reference to `bswap_32'
    /usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: /home/simark/src/binutils-gdb/libctf/ctf-open.c:971: undefined reference to `bswap_32'
    /usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: ../libctf/.libs/libctf.a(ctf-open.o):/home/simark/src/binutils-gdb/libctf/ctf-open.c:972: more undefined references to `bswap_32' follow
    /usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: ../libctf/.libs/libctf.a(ctf-open.o): in function `flip_types':
    /home/simark/src/binutils-gdb/libctf/ctf-open.c:1112: undefined reference to `bswap_16'
    /usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: /home/simark/src/binutils-gdb/libctf/ctf-open.c:1113: undefined reference to `bswap_16'
    /usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: /home/simark/src/binutils-gdb/libctf/ctf-open.c:1132: undefined reference to `bswap_32'
    /usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: /home/simark/src/binutils-gdb/libctf/ctf-open.c:1133: undefined reference to `bswap_32'
    /usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: /home/simark/src/binutils-gdb/libctf/ctf-open.c:1134: undefined reference to `bswap_32'
    /usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: /home/simark/src/binutils-gdb/libctf/ctf-open.c:1135: undefined reference to `bswap_32'
    /usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: /home/simark/src/binutils-gdb/libctf/ctf-open.c:1144: undefined reference to `bswap_32'
    /usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: ../libctf/.libs/libctf.a(ctf-open.o):/home/simark/src/binutils-gdb/libctf/ctf-open.c:1145: more undefined references to `bswap_32' follow
    /usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: ../libctf/.libs/libctf.a(ctf-open.o): in function `ctf_bufopen_internal':
    /home/simark/src/binutils-gdb/libctf/ctf-open.c:1342: undefined reference to `bswap_16'
    /usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: ../libctf/.libs/libctf.a(ctf-open-bfd.o): in function `ctf_fdopen':
    /home/simark/src/binutils-gdb/libctf/ctf-open-bfd.c:268: undefined reference to `bswap_16'

Apparently [1], if we have a function with `inline` but not `static`,
there should be a compilation unit defining the symbol too.
Alternatively, making those functions `static` fixes that.

[1] https://stackoverflow.com/questions/16245521/c99-inline-function-in-c-file/16254679#16254679

libctf/ChangeLog:

	* swap.h (bswap_16, bswap_32, bswap_64): Make static.

Change-Id: I8fd12aedf6c90f9b7418af948e5e0bae0c32eead
2019-10-16 11:12:23 -04:00
Tom de Vries
d10eccaa72 [gdb/tdep] Fix inferior call arg passing for amd64
We currently have 12 KFAILS in gdb.base/infcall-nested-structs.exp for
PR tdep/25096.

A minimal version of the failure looks like this.  Consider test.c:
...
struct s { int c; struct { int a; float b; } s1; };
struct s ref = { 0, { 'a', 'b' } };

int __attribute__((noinline,noclone)) check (struct s arg)
{ return arg.s1.a == 'a' && arg.s1.b == 'b' && arg.c == 0; }

int main (void)
{ return check (ref); }
...

When calling 'check (ref)' from main, we have '1' as expected:
...
$ g++ test.c -g ; ./a.out ; echo $?
1
...

But when calling 'check (ref)' from the gdb prompt, we get '0':
...
$ gdb a.out -batch -ex start -ex "p check (ref)"
Temporary breakpoint 1 at 0x400518: file test.c, line 8.

Temporary breakpoint 1, main () at test.c:8
8       { return check (ref); }
$1 = 0
...

The layout of struct s is this:
- the field c occupies 4 bytes at offset 0,
- the s1.a field occupies 4 bytes at offset 4, and
- the s1.b field occupies 4 bytes at offset 8.

When compiling at -O2, we can see from the disassembly of main:
...
  4003f0:       48 8b 3d 31 0c 20 00    mov    0x200c31(%rip),%rdi \
                                               # 601028 <ref>
  4003f7:       f3 0f 10 05 31 0c 20    movss  0x200c31(%rip),%xmm0 \
                                               # 601030 <ref+0x8>
  4003fe:       00
  4003ff:       e9 ec 00 00 00          jmpq   4004f0 <_Z5check1s>
...
that check is called with fields c and s1.a passed in %rdi, and s1.b passed
in %xmm0.

However, the classification in theclass (a variable representing the first and
second eightbytes, to put it in SYSV X86_64 psABI terms) in
amd64_push_arguments is incorrect:
...
(gdb) p theclass
$1 = {AMD64_INTEGER, AMD64_INTEGER}
...
and therefore the struct is passed using %rdi and %rsi instead of using %rdi
and %xmm0, which explains the failure.

The reason that we're misclassifying the argument in amd64_classify_aggregate
has to do with how nested struct are handled.

Rather than using fields c and s1.a for the first eightbyte, and using field
s1.b for the second eightbyte, instead field c is used for the first
eightbyte, and fields s1.a and s1.b are classified together in an intermediate
eightbyte, which is then used to merge with both the first and second
eightbyte.

Fix this by factoring out a new function amd64_classify_aggregate_field, and
letting it recursively handle fields of nested structs.

Tested on x86_64-linux.

Tested with g++ 4.8.5, 7.4.1, 8.3.1, 9.2.1.

Tested with clang++ 5.0.2 (which requires removing additional_flags=-Wno-psabi
and adding additional_flags=-Wno-deprecated).

gdb/ChangeLog:

2019-10-16  Tom de Vries  <tdevries@suse.de>

	PR tdep/25096
	* amd64-tdep.c (amd64_classify_aggregate_field): Factor out of ...
	(amd64_classify_aggregate): ... here.
	(amd64_classify_aggregate_field): Handled fiels of nested structs
	recursively.

gdb/testsuite/ChangeLog:

2019-10-16  Tom de Vries  <tdevries@suse.de>

	PR tdep/25096
	* gdb.base/infcall-nested-structs.exp: Remove PR25096 KFAILs.

Change-Id: Id55c74755f0a431ce31223acc86865718ae0c123
2019-10-16 17:11:56 +02:00
Tom de Vries
745ff14e6e [gdb/tdep] Fix 'Unexpected register class' assert in amd64_push_arguments
Atm, when executing gdb.base/infcall-nested-structs.exp on x86_64-linux, we get:
...
FAIL: gdb.base/infcall-nested-structs.exp: l=c++: types-tc-tf: \
  p/d check_arg_struct_02_01 (ref_val_struct_02_01)
FAIL: gdb.base/infcall-nested-structs.exp: l=c++: types-ts-tf: \
  p/d check_arg_struct_02_01 (ref_val_struct_02_01)
FAIL: gdb.base/infcall-nested-structs.exp: l=c++: types-ti-tf: \
  p/d check_arg_struct_02_01 (ref_val_struct_02_01)

                === gdb Summary ===

nr of expected passes            9255
nr of unexpected failures        3
nr of expected failures          142
...

The 3 FAILs are reported as PR tdep/25096.

The 142 XFAILs are for a gdb assertion failure, reported in PR tdep/24104,
which should have been KFAILs since there's a problem in gdb rather than in
the environment.

A minimal version of the assertion failure looks like this. Consider test.c:
...
struct s { struct { } es1; long f; };
struct s ref = { {}, 'f' };

int __attribute__((noinline,noclone)) check (struct s arg)
{ return arg.f == 'f'; }

int main (void)
{ return check (ref); }
...

When calling 'check (ref)' from main, we have '1' as expected:
...
$ g++ test3.c -g && ( ./a.out; echo $? )
1
...

But when calling 'check (ref)' from the gdb prompt, we get:
...
$ gdb a.out -batch -ex start -ex "p check (ref)"
Temporary breakpoint 1 at 0x4004f7: file test.c, line 8.

Temporary breakpoint 1, main () at test.c:8
8       { return check (ref); }
src/gdb/amd64-tdep.c:982: internal-error: \
  CORE_ADDR amd64_push_arguments(regcache*, int, value**, CORE_ADDR, \
                                 function_call_return_method): \
  Assertion `!"Unexpected register class."' failed.
...

The assert happens in this loop in amd64_push_arguments:
...
          for (j = 0; len > 0; j++, len -= 8)
            {
              int regnum = -1;
              int offset = 0;

              switch (theclass[j])
                {
                case AMD64_INTEGER:
                  regnum = integer_regnum[integer_reg++];
                  break;

                case AMD64_SSE:
                  regnum = sse_regnum[sse_reg++];
                  break;

                case AMD64_SSEUP:
                  gdb_assert (sse_reg > 0);
                  regnum = sse_regnum[sse_reg - 1];
                  offset = 8;
                  break;

                default:
                  gdb_assert (!"Unexpected register class.");
                }
		...
            }
...
when processing theclass[0], which is AMD64_NO_CLASS:
...
(gdb) p theclass
$1 = {AMD64_NO_CLASS, AMD64_INTEGER}
...

The layout of struct s is that the empty field es1 occupies one byte (due to
c++) at offset 0, and the long field f occupies 8 bytes at offset 8.

When compiling at -O2, we can see from the disassembly of main:
...
  4003f0:       48 8b 3d 41 0c 20 00    mov    0x200c41(%rip),%rdi \
                                               # 601038 <ref+0x8>
  4003f7:       e9 e4 00 00 00          jmpq   4004e0 <_Z5check1s>
  4003fc:       0f 1f 40 00             nopl   0x0(%rax)
...
that check is called with field f passed in %rdi, meaning that the
classification in theclass is correct, it's just not supported in the loop in
amd64_push_arguments mentioned above.

Fix the assert by implementing support for 'AMD64_NO_CLASS' in that loop.

This exposes 9 more FAILs of the PR tdep/25096 type, so mark all 12 of them as
KFAIL.

Tested on x86_64-linux.

Tested with g++ 4.8.5, 7.4.1, 8.3.1, 9.2.1.  With 4.8.5, 3 of the 12 KFAILs
are KPASSing.

Tested with clang++ 5.0.2 (which requires removing additional_flags=-Wno-psabi
and adding additional_flags=-Wno-deprecated).

gdb/ChangeLog:

2019-10-16  Tom de Vries  <tdevries@suse.de>

	PR tdep/24104
	* amd64-tdep.c (amd64_push_arguments): Handle AMD64_NO_CLASS in loop
	that handles 'theclass'.

gdb/testsuite/ChangeLog:

2019-10-16  Tom de Vries  <tdevries@suse.de>

	PR tdep/24104
	* gdb.base/infcall-nested-structs.exp: Remove XFAIL for PR tdep/24104.
	Add KFAIL for PR tdep/25096.

Change-Id: I8b66345bbf5c00209ca75b1209fd4d60b36e9ede
2019-10-16 17:11:56 +02:00
Tom de Vries
03e1ab9424 [gdb/testsuite] Fix local-static.exp with g++-4.8
With g++-4.8, I see:
...
(gdb) PASS: gdb.cp/local-static.exp: c++: print free_inline_func(void)
print 'S::method()'::S_M_s_var_int^M
No symbol "S_M_s_var_int" in specified context.^M
(gdb) FAIL: gdb.cp/local-static.exp: c++: print 'S::method()'::S_M_s_var_int
...

The variable is declared like this (showing pruned .ii):
...
void S::method ()
{
  static int S_M_s_var_int = 4;
}
...

But the DWARF generated for the variable is encapsulated in an unnamed lexical
block:
...
 <1><121>: Abbrev Number: 5 (DW_TAG_structure_type)
    <122>   DW_AT_name        : S
    ...
 <2><14f>: Abbrev Number: 6 (DW_TAG_subprogram)
    ...
    <150>   DW_AT_name        : (indirect string, offset: 0x599): method
    <156>   DW_AT_linkage_name: (indirect string, offset: 0x517): \
                                _ZN1S6methodEv /* demangled: dS::method() */
    ...
 <1><3f8>: Abbrev Number: 21 (DW_TAG_subprogram)
    <3f9>   DW_AT_specification: <0x14f>
    ...
    <3fe>   DW_AT_low_pc      : 0x4004fc
    <406>   DW_AT_high_pc     : 0x2c /* 0x400528 */
    ...
 <2><418>: Abbrev Number: 17 (DW_TAG_formal_parameter)
    <419>   DW_AT_name        : (indirect string, offset: 0x68a): this
    ...
 <2><424>: Abbrev Number: 18 (DW_TAG_lexical_block)
    <425>   DW_AT_low_pc      : 0x400508
    <42d>   DW_AT_high_pc     : 0x1e /* 0x400526 */
 <3><435>: Abbrev Number: 22 (DW_TAG_variable)
    <436>   DW_AT_name        : (indirect string, offset: 0x29d): S_M_s_var_int
...
which has the effect that the variable is not addressable unless the program
counter is in the range of the lexical block.

This is caused by gcc PR debug/55541, which was fixed in gcc 5.

Mark in total 225 FAILs as XFAIL.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2019-10-16  Tom de Vries  <tdevries@suse.de>

	PR testsuite/25059
	* gdb.cp/local-static.exp (do_test): Add xfails for gcc PR debug/55541.

Change-Id: Ibe86707eecffc79f1bb474d7928ea7d0c39a00a2
2019-10-16 17:00:04 +02:00
Tom de Vries
b17fcc1039 [gdb/testsuite] Fix regexp for reg value in jit-reader.exp
On openSUSE Leap 15.1 (as well as on Fedora-x86_64-m64 buildbot) I see:
...
FAIL: gdb.base/jit-reader.exp: with jit-reader: after mangling: current frame: info registers
...

The problem is that r10 is printed signed:
...
r10            0xffffffffffffffb0  -80^M
...
but the regexp expects a signed value:
...
            "r10            $hex +$decimal" \
...

Fix this by allowing signed values.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2019-10-16  Tom de Vries  <tdevries@suse.de>

	* gdb.base/jit-reader.exp: Allow non-pointer registers to be printed
	as signed.

Change-Id: Ie494d24fad7a9af7ac6bfaf731c4aa04f1333830
2019-10-16 16:53:37 +02:00
Alan Modra
22216541c1 PR13616, linker should pad executable sections with nops, not zeros
This implements padding of orphan executable sections for PowerPC.
Of course, the simple implementation of bfd_arch_ppc_nop_fill and
removing the NOP definition didn't work, with powerpc64 hitting a
testsuite failure linking to S-records.  That's because the srec
target is BFD_ENDIAN_UNKNOWN so the test of bfd_big_endian (abfd) in
default_data_link_order therefore returned false, resulting in a
little-endian nop pattern.  The rest of the patch fixes that problem
by adding a new field to bfd_link_info that can be used to determine
actual endianness on targets like srec.

	PR 13616
include/
	* bfdlink.h (struct bfd_link_info <big_endian>): New field.
bfd/
	* cpu-powerpc.c (bfd_arch_ppc_nop_fill): New function, use it
	for all ppc arch info.
	* linker.c (default_data_link_order): Pass info->big_endian to
	arch_info->fill function.
ld/
	* emulparams/elf64lppc.sh (NOP): Don't define.
	* emulparams/elf64ppc.sh (NOP): Don't define.
	* ldwrite.c (build_link_order): Use link_info.big_endian.  Move
	code determining endian to use for data_statement to..
	* ldemul.c (after_open_default): ..here.  Set link_info.big_endian.
2019-10-16 23:07:27 +10:30
Nick Clifton
12234dfd5f Fix potential illegal memory access when disassembling corrupt RX binaries.
opcodes * rx-dis.c (get_register_name): New function.  Provides safe
	access to name array.
	(get_condition_name, get_flag_name, get_double_register_name)
	(get_double_register_high_name, get_double_register_low_name)
	(get_double_control_register_name, get_double_condition_name):
	Likewise.
	(print_insn_rx): Use the accessor functions.
2019-10-16 12:56:58 +01:00
Alan Modra
dfde93ab8c genscripts comment tidy
Some of the comments in this file are ancient and no longer reflect
reality.  This patch removes those comments, and also the description
of ld options emitted to script files.  While describing what an
option does in the script file might help reinforce what the option
does, it's unnecessary and makes for overlong lines.  Also, some of
the descriptions did not mention all the options.

	* genscripts.sh: Correct comments.  Remove outdated comment block
	saying "Generate 5 or 6 script files..".  Remove description of
	ld options from comment emitted to script files, and order options
	as per comment block in genscripts.sh saying which scripts are
	generated.
2019-10-16 11:03:34 +10:30
Alan Modra
8ef6decbc1 qsort: tc-xtensa.c tidy
Not much to see here, just reduce the number of calls to S_GET_VALUE
and symbol_symbolS in the comparison functions.

	* config/tc-xtensa.c (xg_order_trampoline_chain_entry): Don't
	call S_GET_VALUE multiple times for a symbol.  Rearrange code
	so it is obvious what is the primary sort key.
	(xg_order_trampoline_chain): Similarly.
2019-10-16 11:03:34 +10:30
GDB Administrator
d9f06fca19 Automatic date update in version.in 2019-10-16 00:00:20 +00:00
Andrew Burgess
00975ff6eb gdb/gdbserver: Remove reference to vec-ipa.o
This comit:

    commit 0dc327459b
    Date:   Mon Oct 7 16:38:53 2019 +0100

        gdb: Remove vec.{c,h} and update code to not include vec.h

Broke the GDB build due to leaving a reference to vec-ipa.o in the
Makefile.in, this file is built from vec.c which has been removed.

I got away with this as I had an old version of the vec-ipa.o file
still in my build tree.

With this commit in place a clean build now completed successfully.

gdb/ChangeLog:

	* Makefile.in: Remove references to vec-ipa.o.

Change-Id: I4cf55951158dd7ee8f60cd054311a7c367e1d7bf
2019-10-15 22:01:53 +01:00
Andrew Burgess
791b7405f4 gdb: Update comments that reference VEC or vec.h
With the removal of the old VEC mechanism from the code base, update
comments that still make reference to VECs.  There should be no user
visible changes after this commit.

gdb/ChangeLog:

	* linespec.c (decode_digits_ordinary): Update comment.
	* make-target-delegates: No longer need to handle VEC case.
	* memrange.c (normalize_mem_ranges): Update comment.
	* namespace.c (add_using_directive): Update comment.
	* objc-lang.c (uniquify_strings): Update comment.
	* ppc-linux-nat.c (struct thread_points): Update comment.
	* probe.h (find_probes_in_objfile): Update comment.
	* target.h (enum flash_preserve_mode): Update comment.
	* varobj.c (varobj_restrict_range): Update comment.
	* varobj.h (varobj_list_children): Update comment.

Change-Id: Iefd2e903705c3e79cd13b43395c7a1c167f9a088
2019-10-15 21:32:28 +01:00
Andrew Burgess
0dc327459b gdb: Remove vec.{c,h} and update code to not include vec.h
Removes vec.c and vec.h from the source tree, and remove all the
remaining includes of vec.h.  There should be no user visible changes
after this commit.

I did have a few issues rebuilding GDB after applying this patch due
to cached dependencies, I found that running this command in the build
directory resolved my build issues without requiring a 'make clean':

    rm -fr gdb/gdbserver/gdbsupport/.deps/

gdb/ChangeLog:

	* Makefile.in: Remove references to vec.h and vec.c.
	* aarch64-tdep.c: No longer include vec.h.
	* ada-lang.c: Likewise.
	* ada-lang.h: Likewise.
	* arm-tdep.c: Likewise.
	* ax.h: Likewise.
	* breakpoint.h: Likewise.
	* charset.c: Likewise.
	* cp-support.h: Likewise.
	* dtrace-probe.c: Likewise.
	* dwarf2read.c: Likewise.
	* extension.h: Likewise.
	* gdb_bfd.c: Likewise.
	* gdbsupport/gdb_vecs.h: Likewise.
	* gdbsupport/vec.c: Remove.
	* gdbsupport/vec.h: Remove.
	* gdbthread.h: Likewise.
	* guile/scm-type.c: Likewise.
	* inline-frame.c: Likewise.
	* machoread.c: Likewise.
	* memattr.c: Likewise.
	* memrange.h: Likewise.
	* namespace.h: Likewise.
	* nat/linux-btrace.h: Likewise.
	* osdata.c: Likewise.
	* parser-defs.h: Likewise.
	* progspace.h: Likewise.
	* python/py-type.c: Likewise.
	* record-btrace.c: Likewise.
	* rust-exp.y: Likewise.
	* solib-target.c: Likewise.
	* stap-probe.c: Likewise.
	* target-descriptions.c: Likewise.
	* target-memory.c: Likewise.
	* target.h: Likewise.
	* varobj.c: Likewise.
	* varobj.h: Likewise.
	* xml-support.h: Likewise.

gdb/gdbserver/ChangeLog:

	* Makefile.in: Remove references to vec.c.

Change-Id: I0c91d7170bf1b5e992a387fcd9fe4f2abe343bb5
2019-10-15 21:31:55 +01:00
Andrew Burgess
ae6400219c gdb: Remove use of VEC from dwarf2read.c
This removes a use of VEC from GDB, from dwarf2read.c.  This removal
is not very clean, and would probably benefit from additional
refactoring in the future.

The problem here is that the VEC is contained within struct
dwarf2_per_cu_data, which is treated as POD in dwarf2read.c.  As such
it is actually a VEC pointer.  When converting this to a std::vector
in an ideal world we would not use a std::vector pointer, and use the
std::vector directly.  Sadly, to do that would require some rewriting
in dwarf2read.c - my concern would be introducing bugs during this
rewrite.

If we move to a std::vector pointer then we need to take care to
handle the case where the pointer is null.  The old VEC library would
handle null for us, making the VEC interface very clean.  With
std::vector we need to handle the null pointer case ourselves.

The achieve this then I've added a small number of function that wrap
up access to the std::vector, hopefully hiding the null pointer
management.

The final ugliness with this conversion is that, ideally, when
wrapping a data member behind an interface I would make the data
member private, however, treating the structure as POD once again
prevents this, so we are left with the data member being public, but
access (ideally) being through the published interface functions.

There should be no user visible changes after this commit.

gdb/ChangeLog:

	* gdb/dwarf2read.c (dwarf2_per_objfile::~dwarf2_per_objfile):
	Update for new std::vector based implementation.
	(process_psymtab_comp_unit_reader): Likewise.
	(scan_partial_symbols): Likewise.
	(recursively_compute_inclusions): Likewise.
	(compute_compunit_symtab_includes): Likewise.
	(process_imported_unit_die): Likewise.
	(queue_and_load_dwo_tu): Likewise.
	(follow_die_sig_1): Likewise.
	* gdb/dwarf2read.h: Remove DEF_VEC_P.
	(typedef dwarf2_per_cu_ptr): Remove.
	(struct dwarf2_per_cu_data) <imported_symtabs_empty>: New
	function.
	(struct dwarf2_per_cu_data) <imported_symtabs_push>: New function.
	(struct dwarf2_per_cu_data) <imported_symtabs_size>: New function.
	(struct dwarf2_per_cu_data) <imported_symtabs_free>: New function.
	(struct dwarf2_per_cu_data) <imported_symtabs>: Change to
	std::vector.

Change-Id: Id0f4bda977c9dd83b0ba3d7fb42f7e5e2b6869c8
2019-10-15 20:12:25 +01:00
Tom Tromey
55dfc88f7e Use %x when printing the TID
One spot in windows-nat.c uses %ld to print the TID, but all other
spots use %x, as does the infrun logging.  This makes it unnecessarily
hard to tell which other log messages correspond to this one.  This
patch changes the one outlier to use %x.

gdb/ChangeLog
2019-10-15  Tom Tromey  <tromey@adacore.com>

	* windows-nat.c (windows_nat_target::resume): Use %x when logging
	TID.

Change-Id: Ic66efeb8a7ec08e7fb007320318f51acbf976734
2019-10-15 11:42:35 -06:00
Tom Tromey
96b49c5ec0 Rename pid -> tid in windows-nat.c
A couple of spots in windows-nat.c used the name "pid" to refer to the
thread ID.  I found this confusing, so this patch changes the names.

gdb/ChangeLog
2019-10-15  Tom Tromey  <tromey@adacore.com>

	* windows-nat.c (windows_nat_target::fetch_registers)
	(windows_nat_target::store_registers): Rename "pid" to "tid".

Change-Id: Ia1a447e8da822d01ad94a5ca3760342bbdc0e66c
2019-10-15 11:42:35 -06:00
Tom Tromey
953cff5630 Change gcc_target_options to return std::string
This patch was inspired by a recent review that recommended using
std::string in a new implementation of the gcc_target_options gdbarch
function.  It changes this function to return std::string rather than
an ordinary xmalloc'd string.

I believe this caught a latent memory leak in compile.c:get_args.

Tested on x86-64 Fedora 29.

gdb/ChangeLog
2019-10-15  Tom Tromey  <tromey@adacore.com>

	* gdbarch.h, gdbarch.c: Rebuild.
	* gdbarch.sh (gcc_target_options): Change return type to
	std::string.
	* compile/compile.c (get_args): Update.
	* nios2-tdep.c (nios2_gcc_target_options): Return std::string.
	* arm-linux-tdep.c (arm_linux_gcc_target_options): Return
	std::string.
	* aarch64-linux-tdep.c (aarch64_linux_gcc_target_options): Return
	std::string.
	* arch-utils.c (default_gcc_target_options): Return std::string.
	* arch-utils.h (default_gcc_target_options): Return std::string.
	* s390-tdep.c (s390_gcc_target_options): Return std::string.

Change-Id: I51f61703426a323089e646da8f22320a2cafbc1f
2019-10-15 11:03:57 -06:00
Christian Biesinger
81e6b8eb20 Make tui-winsource not use breakpoint_chain
That's an internal variable of breakpoint.c. Insted, use
iterate_over_breakpoints to update the breakpoint list.

gdb/ChangeLog:

2019-10-15  Christian Biesinger  <cbiesinger@google.com>

	* breakpoint.c (breakpoint_chain): Make static.
	* tui/tui-winsource.c: Call iterate_over_breakpoints instead
	of accessing breakpoint_chain.

Change-Id: Ic259b2c3a4c1f5a47f34cfd7fccbdcf274417429
2019-10-15 15:30:00 +02:00
Christian Biesinger
95da600f40 Change iterate_over_breakpoints to take a function_view
This allows callers to pass in capturing lambdas.  Also changes the return
type to bool.

gdb/ChangeLog:

2019-10-15  Christian Biesinger  <cbiesinger@google.com>

	* breakpoint.c (iterate_over_breakpoints): Change function pointer
	to a gdb::function_view and return value to bool.
	* breakpoint.h (iterate_over_breakpoints): Likewise.
	* dummy-frame.c (pop_dummy_frame_bpt): Update.
	(pop_dummy_frame): Update.
	* guile/scm-breakpoint.c (bpscm_build_bp_list): Update.
	(gdbscm_breakpoints): Update.
	* python/py-breakpoint.c (build_bp_list): Update.
	(gdbpy_breakpoints): Update.
	* python/py-finishbreakpoint.c (bpfinishpy_detect_out_scope_cb):
	Update.
	(bpfinishpy_handle_stop): Update.
	(bpfinishpy_handle_exit): Update.
	* solib-svr4.c (svr4_update_solib_event_breakpoint): Update.
	(svr4_update_solib_event_breakpoints): Update.

Change-Id: Ia9de4deecae562a70a40f5cd49f5a74d64570251
2019-10-15 15:29:55 +02:00
Alan Modra
9b142ddb4a m68hc1x: better arg checking for reloc_warning
* elf32-m68hc1x.c (reloc_warning): Add printf attribute.
	(elf32_m68hc11_relocate_section): Don't use a variable for format
	strings.  Delete some unnecessary xgettext:c-format comments.
2019-10-15 23:25:11 +10:30
Andreas Arnez
ba18312d8f s390: Fix infcalls passing a single-field struct with static members
The infcall-nested-structs test case yields 36 FAILs on s390x because GCC
and GDB disagree on how to pass a C++ struct like this as an argument to a
function:

  struct s { float x; static float y; };

For the purpose of argument passing, GCC ignores static fields, while GDB
does not.  Thus GCC passes the argument in a floating-point register and
GDB passes it via memory.

Fix this by explicitly ignoring static fields when detecting single-field
structs.

gdb/ChangeLog:

	* s390-tdep.c (s390_effective_inner_type): Ignore static fields
	when unwrapping single-field structs.
2019-10-15 14:20:14 +02:00
Alan Modra
9a73315161 remove more xmalloc in bfd
Also fixes m68hc1x printf arguments which would have bombed when
compiling on a 32-bit host with --enable-64-bit-bfd.

bfd/
	PR 24955
	* elf32-arm.c (set_cmse_veneer_addr_from_implib): Use bfd_malloc
	rather than xmalloc.
	* elf32-m68hc1x.c (reloc_warning): New function.
	(elf32_m68hc11_relocate_section): Use it here.  Cast bfd_vma values
	corresponding to %lx in format strings.
	* elf32-nds32.c (nds32_insertion_sort): Use a stack temporary.
gas/
	* config/tc-nds32.c (nds32_set_section_relocs): Use relocs and n
	parameters rather than equivalent sec->orelocation and
	sec->reloc_count.  Don't sort for n <= 1.  Tidy.
2019-10-15 16:50:32 +10:30
Alan Modra
779f2ae733 PR25100, Compile fails in elf64-ppc.c because of single equal sign instead of double equal for comparison
PR 25100
	* elf64-ppc.c (sfpr_define): Delete dead code that triggered a warning.
2019-10-15 16:01:05 +10:30
Alan Modra
ed481f9799 Simplify power of two test
* bfd.c (bfd_check_compression_header): Check for powers of two
	with x == (x & -x).
2019-10-15 16:00:54 +10:30
Tom de Vries
b7be2d03fb [gdb/testsuite] Fix gdb.ada/mi_task_arg.exp
On openSUSE Leap 15.1, we have:
...
FAIL: gdb.ada/mi_task_arg.exp: -stack-list-arguments 1 (unexpected output)
...

The problem is that the stack-list-arguments command prints a frame argument
'self_id' for function system.tasking.stages.task_wrapper:
...
frame={level="2",args=[{name="self_id",value="0x12345678"}]
...
where none (args=[]) is expected.

The frame argument is in fact correct.  The FAIL does not show for say, fedora
30, because there the executable uses the system.tasking.stages.task_wrapper
from /lib64/libgnarl-9.so.  Adding "additional_flags=-bargs
additional_flags=-shared additional_flags=-largs" to the flags argument of
gdb_compile_ada gives us the same PASS, but installing libada7-debuginfo gets
us the same FAIL again.

Fix the FAIL by allowing the 'self_id' argument.

Tested on x86_64-linux.

Change-Id: I5aee5856fa6aeb0cc78aa4fe69deecba5b00b77a
2019-10-15 02:21:37 +02:00
GDB Administrator
22cc288441 Automatic date update in version.in 2019-10-15 00:00:20 +00:00
Simon Marchi
9223170f68 gdb.mi/list-thread-groups-available.exp: read entries one by one instead of increasing timeout
Commit 580f1034 ("Increase timeout in
gdb.mi/list-thread-groups-available.exp") changed
gdb.mi/list-thread-groups-available.exp to significantly increase the
timeout, which was necessary for when running with make check-read1.

Pedro suggested a better alternative, which is to use gdb_test_multiple
and consume one entry at a time.  This patch does that.

gdb/testsuite/ChangeLog:

	* gdb.mi/list-thread-groups-available.exp: Read entries one by
	one instead of increasing timeout.

Change-Id: I51b689458503240f24e401f054e6583d9172ebdf
2019-10-14 12:12:24 -04:00
Simon Marchi
6acc1a0b9d gdb: remove unused includes from dwarf2read.c
include-what-you-use says:

../../../src/binutils-gdb/gdb/dwarf2read.c should remove these lines:
- #include <ctype.h>  // lines 67-67
- #include <sys/stat.h>  // lines 59-59
- #include <sys/types.h>  // lines 83-83
- #include <cmath>  // lines 88-88
- #include <forward_list>  // lines 90-90
- #include <set>  // lines 89-89
- #include <unordered_set>  // lines 85-85
- #include "completer.h"  // lines 60-60
- #include "expression.h"  // lines 44-44
- #include "gdbsupport/byte-vector.h"  // lines 78-78
- #include "gdbsupport/filestuff.h"  // lines 71-71
- #include "gdbsupport/gdb_unlinker.h"  // lines 74-74

After a quick glance, that makes sense, so this patch removes them.

gdb/ChangeLog:

	* dwarf2read.c: Remove includes.

Change-Id: I13cfcb2f1d747144fddba7f66b329630b79dae90
2019-10-14 10:15:51 -04:00
Alan Modra
3d9ee7d24b qsort: ldctor.c CONSTRUCTORS
ctor_cmp had an ineffective comparison of addresses in an attempt to
ensure sort stability.  Comparing the addresses passed to the
comparison function can't work since those addresses may be from an
array that is already perturbed by qsort.

	* ldctor.h (struct set_element): Make next field a union, adding
	idx field.
	* ldctor.c (ctor_cmp): Dereference pointer and lose unnecessary
	const.  Replace final sort on pointer value with final sort on idx.
	(ldctor_add_set_entry): Adjust next field access.
	(ldctor_build_sets): Likewise.  Set u.idx field for sort.
2019-10-14 16:47:13 +10:30
Alan Modra
08dec09d8a qsort: pe-dll.c reloc sorting
* pe-dll.c (reloc_data_type): Add idx field.
	(reloc_sort): Perform final sort by idx.
	(generate_reloc): Set idx.
2019-10-14 16:47:13 +10:30
Alan Modra
6ce9ba7afc qsort: objcopy.c section sort
* objcopy.c (compare_section_lma): Correct comment.  Dereference
	section pointer earlier and lose unnecessary const.  Style fixes.
	Add final sort by id.
2019-10-14 16:47:13 +10:30
Alan Modra
47f6ff2f9e qsort: syms.c stab sorting
* syms.c (struct indexentry): Add idx field.
	(cmpindexentry): Final sort on idx.
	(_bfd_stab_section_find_nearest_line): Set idx.
2019-10-14 16:47:13 +10:30
Alan Modra
8025b0554c qsort: dwarf2.c
This patch ensures qsort stability in line and function sorting done
in dwarf2.c.  For the line sequences we make use of an existing field
that isn't used until later, as a monotonic counter for the qsort.

	* dwarf2.c (struct lookup_funcinfo): Add idx field.
	(compare_lookup_funcinfos): Perform final sort on idx.
	(build_lookup_funcinfo_table): Set idx.
	(compare_sequences): Perform final sort on num_lines.
	(build_line_info_table): Set num_lines and line_info_lookup earlier.
	(sort_line_sequences): Set num_lines for sort.
2019-10-14 16:47:13 +10:30
Alan Modra
3a3f4bf76a qsort: elf_link_add_object_symbols weak aliases
This particular sort almost certainly does not need to be stable for
the ELF linker to work correctly.  However it is conceivable that an
unstable sort could affect linker output, and thus different output be
seen with differing qsort implementations.  The argument goes like
this:  Given more than one strong alias symbol of equal section, value,
and size, the aliases will compare equal by elf_sort_symbol and thus
which one is chosen as the "real" symbol to be made dynamic depends on
qsort.  Why would anyone define two symbols at the same address?
Well, sometimes the fact that there are more than one strong alias
symbol is due to linker script symbols like __bss_start being made
dynamic.  This will match the first symbol defined in .bss if it
doesn't have correct size, and forgetting to properly set size and
type of symbols isn't as rare as it should be.

This patch adds some more heuristics to elf_sort_symbol.

	* elflink.c (elf_sort_symbol): Sort on type and name as well.
	(elf_link_add_object_symbols): Style fix.
2019-10-14 16:47:13 +10:30
Alan Modra
48db329734 qsort: elf_sort_sections use of target_index
elf_sort_sections tried to ensure a stable qsort by using target_index
as the final comparison, but target_index hasn't been set by anything
at the time elf_sort_sections was run.  This patch arrange to have
target_index set.

	* elf.c (_bfd_elf_map_sections_to_segments): Init target_index
	for sections about to be sorted.
	(assign_file_positions_for_load_sections): Likewise.
	(elf_sort_sections): Don't bother optimising both TOEND case.
	* elflink.c (bfd_elf_final_link): Reset target_index.
2019-10-14 16:47:13 +10:30
Alan Modra
8c1c5e5de4 qsort: SHF_LINK_ORDER section sort
The linker SHF_LINK_ORDER section sorting had a number of defects.
1) The ordering was by VMA, which won't work with overlays.  LMA is
   better.
2) Zero size sections can result in two sections at the same LMA/VMA.
   When only one of the two sections at the same LMA is zero size,
   that one must be first.
3) Warnings given by elf_get_linked_section_vma won't ever be emitted
   since elf_object_p warns and excludes objects with zero sh_link on
   a SHF_LINK_ORDER section.
4) Section offset was adjusted down rather than up by section
   alignment, possibly creating overlapping sections.
5) Finding the linked section did so the hard way, rather than simply
   using elf_linked_to_section.

	* elflink.c (elf_get_linked_section_vma): Delete.
	(compare_link_order): Use elf_linked_to_section and sort by lma,
	size, and id.
	(elf_fixup_link_order): Use size_t variables where appropriate.
	Make use of elf_linked_to_section.  Formatting.  Properly align
	sections.
2019-10-14 16:47:13 +10:30
Alan Modra
dcea6a95d7 qsort issues
qsort isn't guaranteed to be a stable sort, that is, elements
comparing equal according to the comparison function may be reordered
relative to their original ordering.  Of course sometimes you may not
care, but even in those cases it is good to force some ordering
(ie. not have the comparison function return 0) so that linker output
is reproducible over different libc qsort implementations.

One way to make qsort stable (which the glibc manual incorrectly says
is the only way) is to augment the elements being sorted with a
monotonic counter of some kind, and use that counter as the final
arbiter of ordering in the comparison function.

Another way is to set up an array of pointers into the array of
elements, first pointer to first element, second pointer to second
element and so so, and sort the pointer array rather than the element
array.  Final arbiter in the comparison function then is the pointer
difference.  This works well with, for example, the symbol pointers
returned by _bfd_elf_canonicalize_symtab which point into a symbol
array.

This patch fixes a few places where sorting by symbol pointers is
appropriate, and adds comments where qsort stability is a non-issue.

	* elf-strtab.c (strrevcmp): Comment.
	* merge.c (strrevcmp): Likewise.
	* elf64-ppc.c (compare_symbols): Correct final pointer comparison.
	Comment on why comparing pointers ensures a stable sort.
	* elflink.c (struct elf_symbol): Add void* to union.
	(elf_sort_elf_symbol): Ensure a stable sort with pointer comparison.
	(elf_sym_name_compare): Likewise.
	(bfd_elf_match_symbols_in_sections): Style fix.
	(elf_link_sort_cmp1): Comment.
2019-10-14 16:47:12 +10:30
Alan Modra
ec9bd0a22d PR24955, libbfd terminating program on out of memory (part2)
PR 24955
	* elflink.c (elf_output_implib): Don't use xmalloc.  Don't ignore
	return value of bfd_alloc2.
	* peXXigen.c (_bfd_XXi_write_codeview_record): Don't use xmalloc.
	* pef.c (bfd_pef_print_symbol): Likewise.  Don't ignore return
	value of bfd_get_section_contents.
	* som.c (som_write_space_strings): Don't use xmalloc.
	(som_write_symbol_strings): Likewise.
2019-10-14 16:47:12 +10:30
GDB Administrator
03f04b53b2 Automatic date update in version.in 2019-10-14 00:00:24 +00:00