aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2019-10-16Create xml-builtin.h to declare xml_builtinsChristian Biesinger8-7/+50
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-16libctf: mark swap.h inline functions as staticSimon Marchi2-3/+7
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[gdb/tdep] Fix inferior call arg passing for amd64Tom de Vries4-55/+80
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[gdb/tdep] Fix 'Unexpected register class' assert in amd64_push_argumentsTom de Vries4-12/+21
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[gdb/testsuite] Fix local-static.exp with g++-4.8Tom de Vries2-3/+42
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[gdb/testsuite] Fix regexp for reg value in jit-reader.expTom de Vries2-20/+26
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-16PR13616, linker should pad executable sections with nops, not zerosAlan Modra10-69/+116
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-16Fix potential illegal memory access when disassembling corrupt RX binaries.Nick Clifton2-15/+92
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-16genscripts comment tidyAlan Modra2-58/+45
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-16qsort: tc-xtensa.c tidyAlan Modra2-22/+33
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-16Automatic date update in version.inGDB Administrator1-1/+1
2019-10-15gdb/gdbserver: Remove reference to vec-ipa.oAndrew Burgess2-1/+4
This comit: commit 0dc327459b19e6765c8fe80957f5c8620611628e 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-15gdb: Update comments that reference VEC or vec.hAndrew Burgess11-22/+29
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-15gdb: Remove vec.{c,h} and update code to not include vec.hAndrew Burgess41-1312/+45
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-15gdb: Remove use of VEC from dwarf2read.cAndrew Burgess3-42/+84
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-15Use %x when printing the TIDTom Tromey2-2/+7
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-15Rename pid -> tid in windows-nat.cTom Tromey2-4/+9
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-15Change gcc_target_options to return std::stringTom Tromey11-19/+35
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-15Make tui-winsource not use breakpoint_chainChristian Biesinger3-8/+11
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-15Change iterate_over_breakpoints to take a function_viewChristian Biesinger8-38/+64
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-15m68hc1x: better arg checking for reloc_warningAlan Modra2-21/+26
* 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-15s390: Fix infcalls passing a single-field struct with static membersAndreas Arnez2-3/+23
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-15remove more xmalloc in bfdAlan Modra6-50/+79
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-15PR25100, Compile fails in elf64-ppc.c because of single equal sign instead ↵Alan Modra2-3/+6
of double equal for comparison PR 25100 * elf64-ppc.c (sfpr_define): Delete dead code that triggered a warning.
2019-10-15Simplify power of two testAlan Modra2-1/+6
* bfd.c (bfd_check_compression_header): Check for powers of two with x == (x & -x).
2019-10-15[gdb/testsuite] Fix gdb.ada/mi_task_arg.expTom de Vries1-1/+7
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-15Automatic date update in version.inGDB Administrator1-1/+1
2019-10-14gdb.mi/list-thread-groups-available.exp: read entries one by one instead of ↵Simon Marchi2-9/+23
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-14gdb: remove unused includes from dwarf2read.cSimon Marchi2-12/+4
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-14qsort: ldctor.c CONSTRUCTORSAlan Modra3-21/+31
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-14qsort: pe-dll.c reloc sortingAlan Modra2-3/+19
* pe-dll.c (reloc_data_type): Add idx field. (reloc_sort): Perform final sort by idx. (generate_reloc): Set idx.
2019-10-14qsort: objcopy.c section sortAlan Modra2-9/+19
* objcopy.c (compare_section_lma): Correct comment. Dereference section pointer earlier and lose unnecessary const. Style fixes. Add final sort by id.
2019-10-14qsort: syms.c stab sortingAlan Modra2-3/+13
* syms.c (struct indexentry): Add idx field. (cmpindexentry): Final sort on idx. (_bfd_stab_section_find_nearest_line): Set idx.
2019-10-14qsort: dwarf2.cAlan Modra2-5/+24
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-14qsort: elf_link_add_object_symbols weak aliasesAlan Modra2-12/+49
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-14qsort: elf_sort_sections use of target_indexAlan Modra3-10/+23
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-14qsort: SHF_LINK_ORDER section sortAlan Modra2-61/+51
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-14qsort issuesAlan Modra5-8/+60
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-14PR24955, libbfd terminating program on out of memory (part2)Alan Modra5-10/+37
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-14Automatic date update in version.inGDB Administrator1-1/+1
2019-10-13gdb: Silence -Wformat-nonliteral warning with clangSimon Marchi2-0/+14
We get this warning when building with clang: CXX ui-out.o /home/smarchi/src/binutils-gdb/gdb/ui-out.c:590:22: error: format string is not a string literal [-Werror,-Wformat-nonliteral] do_message (style, format, args); ^~~~~~ This can be considered a legitimate warning, as call_do_message's format parameter is not marked as a format string. Therefore, we should normally mark the call_do_message method with the `format` attribute. However, doing so just moves (and multiplies) the problem, as all the uses of call_do_message in the vmessage method now warn. If we wanted to continue on that path, we should silence the warning for each of them, as a way of telling the compiler "it's ok, we know what we are doing". But since call_do_message is really just vmessage's little helper, it's simpler to just silence the warning at that single point. gdb/ChangeLog: * ui-out.c (ui_out::call_do_message): Silence -Wformat-nonliteral warning. Change-Id: I58ad41793448f38835c5d6ba7b9e5c4dd8df260f
2019-10-13Mention PR c++/20020 in ChangeLog entryTom de Vries1-0/+1
[ Port of gdb-8.3-branch commit 59047affb0a "Update ChangeLog entry of commit 98c90f8028 and mention PR c++/20020". ]
2019-10-13Mention PR testsuite/25016 in ChangeLog entryTom de Vries1-0/+1
[ Port of gdb-8.3-branch commit 3d80b2e754f "Update ChangeLog entry of commit 3b752ac2e6 and mention PR testsuite/25016". ]
2019-10-13Mention PR breakpoints/25011 in ChangeLog entryTom de Vries2-0/+2
[ Port of gdb-8.3-branch commit 88f07f28d5b "Update ChangeLog entry of commit 7e38ddcb2e and mention PR breakpoints/25011". ]
2019-10-13Mention PR gdb/25010 in ChangeLog entryTom de Vries1-0/+1
[ Port of gdb-8.3-branch commit 5ca0b868fa7 "Update ChangeLog entry of commit 8ac39635f6 and mention PR gdb/25010". ]
2019-10-13Update the README-how-to-make-a-release file with a note to reset the ↵Nick Clifton4-2/+12
development flag back to true after making a point release. Aldo fix a typo in the ld/NEWS file. binutils* README-how-to-make-a-release: Add a note to reset the development flag back to true after making a point release. ld * NEWS: Delete superflous "Changes in 2.33" comment.
2019-10-12gdb: small cleanup in breakpoint.c's includesSimon Marchi2-5/+7
In an attempt to reduce the number of files re-build when some headers are touched, I ran include-what-you-use with breakpoint.c as a guinea pig. It revealed a few files that were unnecessary to include, which this patch removes. breakpoint.c uses tilde_expand from readline, hence the necessity to include tilde.h. AFAIK, it's fine to include just that, and not the whole readline headers. include-what-you-use also reported many header files that should be included but aren't, I suppose that breakpoint.c currently includes them indirectly. For now I'll pretend I didn't see that :). gdb/ChangeLog: * breakpoint.c: Remove some includes: continuations.h, skip.h, mi/mi-main.h, readline/readline.h, readline/history.h. Add include: readline/tilde.h. -#include "skip.h" #include "ax-gdb.h" #include "dummy-frame.h" #include "interps.h" @@ -69,11 +67,9 @@ #include "thread-fsm.h" #include "tid-parse.h" #include "cli/cli-style.h" -#include "mi/mi-main.h" /* readline include files */ -#include "readline/readline.h" -#include "readline/history.h" +#include "readline/tilde.h" /* readline defines this. */ #undef savestring Change-Id: I88bfe9071f2f973fd84caaf04b95c33a4dfb33de
2019-10-13[gdb/testsuite] Add KFAIL for missing support of reverse-debugging xsaveTom de Vries9-8/+87
Normally the gdb.reverse/*.exp test-cases pass on my system (apart from the record/23188 KFAIL for gdb.reverse/step-precsave.exp). But when specifying GLIBC_TUNABLES=glibc.tune.hwcaps=-XSAVEC_Usable to force glibc to use _dl_runtime_resolve_xsave instead of _dl_runtime_resolve_xsavec, we run into 1054 FAILs like this: ... (gdb) PASS: gdb.reverse/sigall-reverse.exp: b gen_HUP continue^M Continuing.^M Process record does not support instruction 0xfae64 at address \ 0x7ffff7ded958.^M Process record: failed to record execution log.^M ^M Program stopped.^M 0x00007ffff7ded958 in _dl_runtime_resolve_xsave () from \ /lib64/ld-linux-x86-64.so.2^M (gdb) FAIL: gdb.reverse/sigall-reverse.exp: get signal ABRT ... The problem is that the xsave instruction is not supported in reverse-debugging (PR record/25038). Add KFAILs for this PR. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2019-10-13 Tom de Vries <tdevries@suse.de> PR record/25038 * gdb.reverse/sigall-precsave.exp: Add PR record/25038 KFAIL. * gdb.reverse/sigall-reverse.exp: Same. * gdb.reverse/solib-precsave.exp: Same. * gdb.reverse/solib-reverse.exp: Same. * gdb.reverse/step-precsave.exp: Same. * gdb.reverse/until-precsave.exp: Same. * gdb.reverse/until-reverse.exp: Same. * lib/gdb.exp (gdb_continue_to_breakpoint): Same.
2019-10-13Automatic date update in version.inGDB Administrator1-1/+1
2019-10-12Remove unnecessary declaration of trace_regblock_sizeChristian Biesinger2-2/+6
This variable is declared in tracepoint.h, which is already included by remote.c. gdb/ChangeLog: 2019-10-12 Christian Biesinger <cbiesinger@google.com> * remote.c (remote_target::get_trace_status): Remove declaration of trace_regblock_size.
generated by cgit v1.1 at 2024-11-25 07:21:38 +0000