aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2019-02-14[gdb, hurd] Adjust to Hurd "proc" interface changesDavid Michael2-3/+12
Hurd's commit baf7e5c8ce176aead15c2559952d8bdf0da41ffd "hurd: Use polymorphic port types to return some rights" causes in the GDB build: /usr/bin/ld: process_reply_S.o: in function `_Xproc_pid2proc_reply': [...]/gdb/process_reply_S.c:754: undefined reference to `S_proc_pid2proc_reply' /usr/bin/ld: [...]/gdb/process_reply_S.c:730: undefined reference to `S_proc_pid2proc_reply' /usr/bin/ld: process_reply_S.o: in function `_Xproc_task2proc_reply': [...]/gdb/process_reply_S.c:589: undefined reference to `S_proc_task2proc_reply' /usr/bin/ld: [...]/gdb/process_reply_S.c:565: undefined reference to `S_proc_task2proc_reply' /usr/bin/ld: process_reply_S.o: in function `_Xproc_getmsgport_reply': [...]/gdb/process_reply_S.c:204: undefined reference to `S_proc_getmsgport_reply' /usr/bin/ld: [...]/gdb/process_reply_S.c:180: undefined reference to `S_proc_getmsgport_reply' collect2: error: ld returned 1 exit status gdb/ * gnu-nat.c (S_proc_getmsgport_reply, S_proc_task2proc_reply) (S_proc_pid2proc_reply): Adjust to Hurd "proc" interface changes.
2019-02-14[gdb, hurd] Address "ISO C++ forbids converting a string constant to 'char*' ↵Thomas Schwinge2-4/+8
[-Wwrite-strings]" diagnostics ... that appeared with 9bf2a700667c53003ece783c05e8b355801105f2 "-Wwrite-strings: Remove -Wno-write-strings". gdb/ * gnu-nat.c (gnu_write_inferior, parse_int_arg, _parse_bool_arg) (check_empty): Use "const char *".
2019-02-14[gdb, hurd] Repair build after "Use thread_info and inferior pointers more ↵Thomas Schwinge2-1/+5
throughout" ..., that is commit 00431a78b28f913a9d5c912c49680e39cfd20847 causing: [...]/gdb/gnu-nat.c: In member function 'virtual void gnu_nat_target::detach(inferior*, int)': [...]/gdb/gnu-nat.c:2284:23: error: invalid conversion from 'int' to 'inferior*' [-fpermissive] detach_inferior (pid); ^ In file included from [...]/gdb/gnu-nat.c:61:0: [...]/gdb/inferior.h:523:13: note: initializing argument 1 of 'void detach_inferior(inferior*)' extern void detach_inferior (inferior *inf); ^~~~~~~~~~~~~~~ Fixed by inlining the removed code. gdb/ * gnu-nat.c (gnu_nat_target::detach): Instead of 'detach_inferior (pid)' call 'detach_inferior (find_inferior_pid (pid))'.
2019-02-14[gdb, hurd] Repair build after "Share fork_inferior et al with gdbserver" ↵Thomas Schwinge3-0/+6
changes ..., that is commit 2090129c36c7e582943b7d300968d19b46160d84 causing: [...]/gdb/gnu-nat.c: In function 'void gnu_ptrace_me()': [...]/gdb/gnu-nat.c:2133:5: error: 'trace_start_error_with_name' was not declared in this scope trace_start_error_with_name ("ptrace"); ^~~~~~~~~~~~~~~~~~~~~~~~~~~ [...]/gdb/gnu-nat.c:2133:5: note: suggested alternative: 'throw_perror_with_name' trace_start_error_with_name ("ptrace"); ^~~~~~~~~~~~~~~~~~~~~~~~~~~ throw_perror_with_name [...]/gdb/gnu-nat.c: In function 'void gnu_create_inferior(target_ops*, const char*, const string&, char**, int)': [...]/gdb/gnu-nat.c:2147:9: error: 'fork_inferior' was not declared in this scope pid = fork_inferior (exec_file, allargs, env, gnu_ptrace_me, ^~~~~~~~~~~~~ [...]/gdb/gnu-nat.c:2147:9: note: suggested alternative: 'exit_inferior' pid = fork_inferior (exec_file, allargs, env, gnu_ptrace_me, ^~~~~~~~~~~~~ exit_inferior [...]/gdb/gnu-nat.c:2174:30: error: 'START_INFERIOR_TRAPS_EXPECTED' was not declared in this scope gdb_startup_inferior (pid, START_INFERIOR_TRAPS_EXPECTED); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/bin/ld: gnu-nat.o: in function `gnu_ptrace_me()': [...]/gdb/gnu-nat.c:2134: undefined reference to `trace_start_error_with_name(char const*)' /usr/bin/ld: gnu-nat.o: in function `gnu_create_inferior(target_ops*, char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char**, int)': [...]/gdb/gnu-nat.c:2148: undefined reference to `fork_inferior(char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char**, void (*)(), void (*)(int), void (*)(), char const*, void (*)(char const*, char* const*, char* const*))' /usr/bin/ld: fork-child.o: in function `gdb_startup_inferior(int, int)': [...]/gdb/fork-child.c:136: undefined reference to `startup_inferior(int, int, target_waitstatus*, ptid_t*)' collect2: error: ld returned 1 exit status gdb/ * configure.nat [gdb_host == i386gnu] (NATDEPFILES): Add 'nat/fork-inferior.o'. * gnu-nat.c: #include "nat/fork-inferior.h".
2019-02-14[gdb, hurd] Repair build after "Convert struct target_ops to C++" changesThomas Schwinge4-7/+15
..., that is commit f6ac5f3d63e03a81c4ff3749aba234961cc9090e causing: In file included from [...]/gdb/gnu-nat.c:24:0: [...]/gdb/gnu-nat.h:123:1: error: expected class-name before '{' token { ^ [...]/gdb/gnu-nat.h:128:16: error: 'inferior' has not been declared void detach (inferior *, int) override; ^~~~~~~~ [...]/gdb/gnu-nat.h:132:8: error: use of enum 'target_xfer_status' without previous declaration enum target_xfer_status xfer_partial (enum target_object object, ^~~~~~~~~~~~~~~~~~ [...]/gdb/gnu-nat.h:132:46: error: use of enum 'target_object' without previous declaration enum target_xfer_status xfer_partial (enum target_object object, ^~~~~~~~~~~~~ [...]/gdb/gnu-nat.h:124:8: error: 'void gnu_nat_target::attach(const char*, int)' marked 'override', but does not override void attach (const char *, int) override; ^~~~~~ [...] [...]/gdb/gnu-nat.c: In member function 'virtual void gnu_nat_target::detach(inferior*, int)': [...]/gdb/gnu-nat.c:2286:34: error: 'ops' was not declared in this scope inf_child_maybe_unpush_target (ops); ^~~ [...]/gdb/gnu-nat.c:2286:34: note: suggested alternative: 'open' inf_child_maybe_unpush_target (ops); ^~~ open [...]/gdb/gnu-nat.c:2286:3: error: 'inf_child_maybe_unpush_target' was not declared in this scope inf_child_maybe_unpush_target (ops); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ [...]/gdb/gnu-nat.c:2286:3: note: suggested alternative: 'maybe_unpush_target' inf_child_maybe_unpush_target (ops); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ maybe_unpush_target [...]/gdb/i386-gnu-nat.c:200:1: warning: 'void gnu_store_registers(target_ops*, regcache*, int)' defined but not used [-Wunused-function] gnu_store_registers (struct target_ops *ops, ^~~~~~~~~~~~~~~~~~~ [...]/gdb/i386-gnu-nat.c:109:1: warning: 'void gnu_fetch_registers(target_ops*, regcache*, int)' defined but not used [-Wunused-function] gnu_fetch_registers (struct target_ops *ops, ^~~~~~~~~~~~~~~~~~~ [...] /usr/bin/ld: i386-gnu-nat.o:(.data.rel+0x0): undefined reference to `vtable for i386_gnu_nat_target' collect2: error: ld returned 1 exit status gdb/ * gnu-nat.c (gnu_nat_target::detach): Instead of 'inf_child_maybe_unpush_target (ops)' call 'maybe_unpush_target'. * gnu-nat.h: #include "inf-child.h". * i386-gnu-nat.c (gnu_fetch_registers): Rename/move to 'i386_gnu_nat_target::fetch_registers'. (gnu_store_registers): Rename/move to 'i386_gnu_nat_target::store_registers'.
2019-02-14[gdb, hurd] Work around conflict between Mach's 'thread_info' function, and ↵Thomas Schwinge5-10/+27
GDB's 'thread_info' class In file included from ./nm.h:25:0, from [...]/gdb/defs.h:423, from [...]/gdb/gdb.c:19: [...]/gdb/regcache.h:35:46: warning: 'get_thread_regcache' initialized and declared 'extern' extern struct regcache *get_thread_regcache (thread_info *thread); ^~~~~~~~~~~ [...]/gdb/regcache.h:35:46: error: 'regcache* get_thread_regcache' redeclared as different kind of symbol [...] [...]/gdb/gdbarch.h:1203:69: error: 'thread_info' is not a type extern LONGEST gdbarch_get_syscall_number (struct gdbarch *gdbarch, thread_info *thread); ^~~~~~~~~~~ Fixed with a different (self-contained, more maintainable?) approach compared to what has been done in commit 7aabaf9d4ad52a1df1f551908fbd8cafc5e7597a "Create private_thread_info hierarchy", and commit 75cbc781e371279f4403045be93b07fd8fe7fde5 "gdb: For macOS, s/thread_info/struct thread_info/". We don't want to change all the GDB code to everywhere use 'class thread_info' or 'struct thread_info' instead of plain 'thread_info'. gdb/ * config/i386/nm-i386gnu.h: Don't "#include" any files. * gnu-nat.h (mach_thread_info): New function. * gnu-nat.c (thread_takeover_sc_cmd): Use it.
2019-02-14[gdb, hurd] Remove long obsolete 'gnu_target_pid_to_str' function declarationThomas Schwinge2-2/+4
... for function definition removed/renamed in 1999. ;-) gdb/ * config/i386/nm-i386gnu.h (gnu_target_pid_to_str): Remove.
2019-02-13(riscv/ada) fix error when calling functions with range argumentKONRAD Frederic2-0/+5
Using the gdb.ada/call_pn.exp testcase, and running it by hand on riscv64-elf, we get the following error: (gdb) call pn(55) Could not compute alignment of type The problem occurs because the parameter's type is a TYPE_CODE_RANGE, and that type code is not handled by riscv_type_alignment. So this patch fixes the issue by handling TYPE_CODE_RANGE the same way we handle other integral types. gdb/ChangeLog: * riscv-rdep.c (riscv_type_alignment): Handle TYPE_CODE_RANGE. Tested on riscv64-elf using AdaCore's testsuite.
2019-02-14(Windows) remove thread notification for main thread of inferiorJoel Brobecker2-21/+69
This is a followup on a recent patch which, among other things introduced the exit notification of the main thread in order to be symetrical with the fact that a thread notification was emitted before signaling its creation. This patch takes the opposite approach of removing both creation and exit notifications for that main thread, which is consistent with what is done on other platforms such as GNU/Linux for instance. gdb/ChangeLog * windows-nat.c (windows_add_thread): Add new parameter "main_thread_p" with default value set to false. Update function documentation as well as all callers. (windows_delete_thread): Likewise. (fake_create_process): Update call to windows_add_thread. (get_windows_debug_event) <CREATE_THREAD_DEBUG_EVENT> <CREATE_PROCESS_DEBUG_EVENT>: Likewise. <EXIT_THREAD_DEBUG_EVENT, EXIT_PROCESS_DEBUG_EVENT>: Update call to windows_delete_thread. Tested on x86-windows (MinGW) using AdaCore's testsuite.
2019-02-14Automatic date update in version.inGDB Administrator1-1/+1
2019-02-13Add Andrew Burgess as global maintainer of gdb/ and sim/Simon Marchi4-1/+11
2019-02-13Adding a test caseWeimin Pan3-0/+185
gdb/testsuite/ChangeLog 2019-02-12 Weimin Pan <weimin.pan@oracle.com> PR breakpoints/21870 * gdb.arch/aarch64-dbreg-contents.exp: New file. * gdb.arch/aarch64-dbreg-contents.c: New file.
2019-02-13Automatic date update in version.inGDB Administrator1-1/+1
2019-02-12Try to use the canonical version of a sysroot for debug file links.John Baldwin2-3/+15
Object file paths passed to find_separate_debug_file are always canonical paths with symbolic links resolved. If a sysroot path traverses a symbolic link, it will not match the object file paths. Generate a canonical version of the sysroot directory. If it is valid, use it instead of gdb_sysroot with child_path to determine if an object file is under a system root. gdb/ChangeLog: * symfile.c (find_separate_debug_file): Use canonical path of sysroot with child_path instead of gdb_sysroot if it is valid.
2019-02-12Use child_path to determine if an object file is under a sysroot.John Baldwin2-5/+12
This fixes the case where the sysroot happens to end in a trailing '/'. Note that the path returned from child_path always skips over the directory separator at the start of the base path, so a separator must always be explicitly added before the base path. gdb/ChangeLog: * symfile.c (find_separate_debug_file): Use child_path to determine if an object file is under a sysroot.
2019-02-12Add a new function child_path.John Baldwin5-0/+133
child_path returns a pointer to the first component in a child path that comes after a parent path. This does not depend on trying to stat() the paths since they may describe remote paths but instead relies on filename parsing. The function requires that the child path describe a filename that contains at least one component below the parent path and returns a pointer to the first component. gdb/ChangeLog: * Makefile.in (SUBDIR_UNITTESTS_SRCS): Add unittests/child-path-selftests.c. * common/pathstuff.c (child_path): New function. * common/pathstuff.h (child_path): New prototype. * unittests/child-path-selftests.c: New file.
2019-02-12Look for separate debug files in debug directories under a sysroot.John Baldwin2-2/+20
When an object file is present in a system root, GDB currently looks for separate debug files under the global debugfile directories. For example, if the sysroot is set to "/myroot" and hte global debugfile directory is set to "/usr/lib/debug", GDB will look for a separate debug file for "/myroot/lib/libc.so.7" in the following paths: /myroot/lib/libc.so.7.debug /myroot/lib/.debug/libc.so.7.debug /usr/lib/debug//myroot/lib/libc.so.7.debug /usr/lib/debug/lib/libc.so.7.debug However, some system roots include a full system installation including a nested global debugfile directory under the sysroot. This patch adds an additional check to support such systems. In the example above the additional path searched is: /myroot/usr/lib/debug/lib/libc.so.7.debug To try to preserve existing behavior as much as possible, this new path is searched last for each global debugfile directory. gdb/ChangeLog: * symfile.c (find_separate_debug_file): Look for separate debug files in debug directories under the sysroot.
2019-02-12Make symtab.c better styled.Philippe Waroquiers3-16/+59
Note that print_msymbol_info does not (yet?) print data msymbol using variable_name_style, as otherwise 'info variables' would show the non debugging symbols in variable name style, but 'real' variables would be not styled. 2019-02-12 Philippe Waroquiers <philippe.waroquiers@skynet.be> * symtab.h (struct minimal_symbol data_p): New const method. (struct minimal_symbol text_p): Likewise. * symtab.c (output_source_filename): Use file name style to print file name. (print_symbol_info): Likewise. (print_msymbol_info): Use address style to print addresses. Use function name style to print executable text symbols. (expand_symtab_containing_pc): Use data_p. (find_pc_sect_compunit_symtab): Likewise.
2019-02-12Use address style to print addresses in breakpoint information.Philippe Waroquiers2-3/+10
gdb/ChangeLog 2019-02-12 Philippe Waroquiers <philippe.waroquiers@skynet.be> * breakpoint.c (describe_other_breakpoints): Use address style to print addresses. (say_where): Likewise.
2019-02-12Use function_name_style to print Ada and C function namesPhilippe Waroquiers3-3/+17
Note that ada-typeprint.c print_func_type is called with types representing functions and is also called to print a function NAME together with its type. In such a case, the function name will be printed using function name style. Similarly, c_print_type_1 is called to print a type, optionally with the name of an object of this type in the VARSTRING arg. So, c_print_type_1 uses function name style to print varstring when the type code indicates that c_print_type_1 TYPE is some 'real code'. gdb/ChangeLog 2019-02-12 Philippe Waroquiers <philippe.waroquiers@skynet.be> * ada-typeprint.c (print_func_type): Print function name style to print function name. * c-typeprint.c (c_print_type_1): Likewise.
2019-02-12Updated French translation for ld/ and gold/ subdirectoriesNick Clifton4-2363/+2449
2019-02-12Fix splay tree KEY leak detected in GDB test gdb.base/macscp.exptromey4-5/+30
When a node is removed from a splay tree, the splay tree was not using the function splay_tree_delete_key_fn to release the key. This was causing a leak, fixed by Tom Tromey. This patch fixes another key leak, that happens when a key equal to a key already present is inserted. In such a case, we have to release the old KEY. Note that this is based on the assumption that the caller always allocates a new KEY when doing an insert. Also, clarify the documentation about when the release functions are called. 2019-02-11 Philippe Waroquiers <philippe.waroquiers@skynet.be> * splay-tree.h (splay_tree_delete_key_fn): Update comment. (splay_tree_delete_value_fn): Likewise. libiberty/ChangeLog 2019-02-11 Philippe Waroquiers <philippe.waroquiers@skynet.be> * splay-tree.c (splay_tree_insert): Also release old KEY in case of insertion of a key equal to an already present key. (splay_tree_new_typed_alloc): Update comment. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@268793 138bc75d-0d04-0410-961f-82ee72b054a4
2019-02-12Update description of how to make a release to include the use of the git ↵Nick Clifton2-74/+57
clean command. PR 23440 * README-how-to-make-a-release: Use git clean to delete spurious files from the local source repository.
2019-02-12Automatic date update in version.inGDB Administrator1-1/+1
2019-02-11AArch64: Detect exit from execve syscallAlan Hayward2-22/+39
Checking the syscall number when stopped on entry/exit relies on checking the value in register X8. However, on exit from an execve syscall, the registers will all be cleared. Given this is only checked on syscall entry/exit, then a cleared register state either means execve exit or syscall 0 (io_setup) entry with invalid parameters and an invalid FR and LR, which in reality should never happen. Use this to detect execve exit. Move function to allow use of aarch64_sys_execve enum, and use newer regcache functions. Fixes gdb.base/catch-syscall.exp on Aarch64. gdb/ChangeLog: * aarch64-linux-tdep.c (aarch64_linux_get_syscall_number): Check for execve.
2019-02-11Automatic date update in version.inGDB Administrator1-1/+1
2019-02-10gas: Pass max_bytes to TC_FRAG_INITH.J. Lu17-22/+52
ommit 3ae729d5a4f63740ed9a778960b17c2912b0bbdd Author: H.J. Lu <hjl.tools@gmail.com> Date: Wed Mar 7 04:18:45 2018 -0800 x86: Rewrite NOP generation for fill and alignment increased MAX_MEM_FOR_RS_ALIGN_CODE to 4095 which resulted in increase of assembler time and memory usage by 5 times for inputs with many .p2align directives, which is typical for LTO output. This patch passes max_bytes to TC_FRAG_INIT so that MAX_MEM_FOR_RS_ALIGN_CODE can be set as needed and tracked by backend it so that HANDLE_ALIGN can check the maximum alignment for each rs_align_code frag. Wall time to assemble the same cc1plus.s: before: 423.78user 0.89system 7:05.71elapsed 99%CPU after: 102.35user 0.27system 1:42.89elapsed 99%CPU PR gas/24165 * frags.c (frag_var_init): Pass max_chars to TC_FRAG_INIT as max_bytes. * config/tc-aarch64.h (TC_FRAG_INIT): Add and pass max_bytes to aarch64_init_frag. * /config/tc-arm.h (TC_FRAG_INIT): And and pass max_bytes to arm_init_frag. * config/tc-avr.h (TC_FRAG_INIT): And and ignore max_bytes. * config/tc-ia64.h (TC_FRAG_INIT): Likewise. * config/tc-mmix.h (TC_FRAG_INIT): Likewise. * config/tc-nds32.h (TC_FRAG_INIT): Likewise. * config/tc-ns32k.h (TC_FRAG_INIT): Likewise. * config/tc-rl78.h (TC_FRAG_INIT): Likewise. * config/tc-rx.h (TC_FRAG_INIT): Likewise. * config/tc-score.h (TC_FRAG_INIT): Likewise. * config/tc-tic54x.h (TC_FRAG_INIT): Likewise. * config/tc-tic6x.h (TC_FRAG_INIT): Likewise. * config/tc-xtensa.h (TC_FRAG_INIT): Likewise. * config/tc-i386.h (MAX_MEM_FOR_RS_ALIGN_CODE): Set to (alignment ? ((1 << alignment) - 1) : 1) (i386_tc_frag_data): Add max_bytes. (TC_FRAG_INIT): Add and track max_bytes. (HANDLE_ALIGN): Replace MAX_MEM_FOR_RS_ALIGN_CODE with fragP->tc_frag_data.max_bytes. * doc/internals.texi: Update TC_FRAG_TYPE with max_bytes.
2019-02-10Fix type_stack leaks in c expression parsing.Philippe Waroquiers2-0/+9
Valgrind detects a bunch of leaks in several tests, such as: ==22905== 40 (24 direct, 16 indirect) bytes in 1 blocks are definitely lost in loss record 531 of 3,268 ==22905== at 0x4C2C4CC: operator new(unsigned long) (vg_replace_malloc.c:344) ==22905== by 0x5893AD: get_type_stack() (parse.c:1509) ==22905== by 0x3F4EAD: c_yyparse() (c-exp.y:1223) ==22905== by 0x3F71BC: c_parse(parser_state*) (c-exp.y:3308) ==22905== by 0x588CEA: parse_exp_in_context_1(char const**, unsigned long, block const*, int, int, int*) [clone .constprop.89] (parse.c:1205) ==22905== by 0x588FA1: parse_exp_in_context (parse.c:1108) ==22905== by 0x588FA1: parse_exp_1 (parse.c:1099) ==22905== by 0x588FA1: parse_expression(char const*) (parse.c:1247) ... ==22395== 456 (168 direct, 288 indirect) bytes in 7 blocks are definitely lost in loss record 2,658 of 2,978 ==22395== at 0x4C2C4CC: operator new(unsigned long) (vg_replace_malloc.c:344) ==22395== by 0x5893AD: get_type_stack() (parse.c:1509) ==22395== by 0x3F4ECF: c_yyparse() (c-exp.y:1230) ==22395== by 0x3F71BC: c_parse(parser_state*) (c-exp.y:3308) ==22395== by 0x588CEA: parse_exp_in_context_1(char const**, unsigned long, block const*, int, int, int*) [clone .constprop.89] (parse.c:1205) ==22395== by 0x588FA1: parse_exp_in_context (parse.c:1108) ==22395== by 0x588FA1: parse_exp_1 (parse.c:1099) ==22395== by 0x588FA1: parse_expression(char const*) (parse.c:1247) ==22395== by 0x67BB9D: whatis_exp(char const*, int) (typeprint.c:515) ... ==22395== VALGRIND_GDB_ERROR_BEGIN ==22395== 144 (24 direct, 120 indirect) bytes in 1 blocks are definitely lost in loss record 1,016 of 2,978 ==22395== at 0x4C2C4CC: operator new(unsigned long) (vg_replace_malloc.c:344) ==22395== by 0x5893AD: get_type_stack() (parse.c:1509) ==22395== by 0x3F4E8A: c_yyparse() (c-exp.y:1217) ==22395== by 0x3F71BC: c_parse(parser_state*) (c-exp.y:3308) ==22395== by 0x588CEA: parse_exp_in_context_1(char const**, unsigned long, block const*, int, int, int*) [clone .constprop.89] (parse.c:1205) ==22395== by 0x588FA1: parse_exp_in_context (parse.c:1108) ==22395== by 0x588FA1: parse_exp_1 (parse.c:1099) ==22395== by 0x588FA1: parse_expression(char const*) (parse.c:1247) ==22395== by 0x67BB9D: whatis_exp(char const*, int) (typeprint.c:515) ... Fix these by storing the allocated type_stack in the cpstate->type_stacks vector. Tested on debian/amd64, natively and under valgrind. gdb/ChangeLog 2019-02-10 Philippe Waroquiers <philippe.waroquiers@skynet.be> * c-exp.y (direct_abs_decl): Use emplace_back to record the type_stack.
2019-02-10(Ada) -var-update crash for variable whose type is a reference to changeableJoel Brobecker7-0/+157
Consider the following variable, which is a string whose value is not known at compile time, because it is the return value from a function call (Get_Name): A : String := Get_Name; If one tries to create a varobj for that variable, everything works as expected: | (gdb) -var-create a * a | ^done,name="a",numchild="19",value="[19] \"Some kind of string\"",type="<ref> array (1 .. 19) of character",thread-id="1",has_more="0" However, try then to request an update, regardless of whether the string has changed or not, and we get a crash: | -var-update a | ~"/[...]/gdb/varobj.c:1379: internal-error: bool install_new_value(varobj*, value*, bool): Assertion `!value_lazy (var->value.get ())' failed.\nA problem internal to GDB has been detected,\nfurther debugging may prove unreliable.\nQuit this debugging session? (y or n) " When the varobj gets created (-var-create), the expression is evaluated and transformed into a value. The debugging information describes our variables as a reference to an array of characters, so our value has the corresponding type. We then call varobj.c::install_new_value to store that value inside our varobj, and we see that this function pretty starts by determining weither our varobj is changeable, via: | changeable = varobj_value_is_changeable_p (var); (where 'var' is the varobj we are building, and where the function varobj_value_is_changeable_p simply dispatches to the Ada version of this routine: ada_value_is_changeable_p). At this point, the varobj doesn't have a value, yet, but it does have a type which was provided by varobj_create a little bit before install_new_value was called. So ada_value_is_changeable_p uses that to determine whether or not our type is changeable. Since our type is a reference to an array, and that the value of such objects is displayed as if there weren't a reference, it means that our object is changeable -- in other words, if an element of the string changes, then the "value" field of the varobj will change accordingly. But unfortunately, ada_value_is_changeable_p mistakenly returns false, because it is missing the handling of reference types. As a consequence of this, install_new_value doesn't feel it is necessary to fetch the value's contents, as explained by the following comment inside that function: /* The new value might be lazy. If the type is changeable, that is we'll be comparing values of this type, fetch the value now. Otherwise, on the next update the old value will be lazy, which means we've lost that old value. */ This means that a lazy value gets installed inside our varobj as a result of the mistake in ada_value_is_changeable_p. Another important detail is that, after determining whether our varobj is changeable or not, it then purposefully removes the reference layer from our value: /* We are not interested in the address of references, and given that in C++ a reference is not rebindable, it cannot meaningfully change. So, get hold of the real value. */ if (value) value = coerce_ref (value); The consequence of those two facts on shows up only later, when the user requests an update (-var-update). When doing so, GDB evaluates the expression again into a value which is once more a reference to a string, and then calls install_new_value again to install the new value and report any changes. This time around, the call to... | changeable = varobj_value_is_changeable_p (var); ... now gets a varobj which has a value, and one which had the reference layer removed! So, this time, we classify the varobj correctly, and say it is changeable. And because it is changeable, we then go into the section of code in install_new_value which checks for changes, where we need the varobj's value to not be lazy, as explained by the comment we quoted above. That's what the assertion was about. This patch fixes the issues by teaching ada_value_is_changeable_p to ignore reference layers when evaluating a given varobj's type. gdb/ChangeLog: * ada-varobj.c (ada_value_is_changeable_p): Add handling of TYPE_CODE_REF types. gdb/testsuite/ChangeLog: * gdb.ada/mi_ref_changeable: New testcase. Prior to this patch, this testcase reports 2 unresolved tests (due to GDB hitting the internal error). With this patch, all tests in this testcase pass. Tested on x86_64-linux, no regression.
2019-02-10Automatic date update in version.inGDB Administrator1-1/+1
2019-02-09[ARC] don't force _init/_fini as DT_INIT/DT_FINI.Claudiu Zissulescu4-38/+12
Recent gcc commit b4371b277f1e ("[ARC] Enable init_array support") inhibits DT_"INIT,FINI} in favor of DT_{INIT,FINI}ARRAY. Even prior to that, it seems ARC port is the only one with this special DT_INIT/FINI handling in linker emulation. Removing it doesn't seem to change any uClibc/glibc testsuite results, so this can RIP anyways. bfd/ 2019-02-01 Vineet Gupta <vgupta@synopsys.com> * elf32-arc.c: Delete init_str, fini_str ld/ 2019-02-01 Vineet Gupta <vgupta@synopsys.com> * emultempl/arclinux.em : Delete special INIT/FINI handling.
2019-02-09Automatic date update in version.inGDB Administrator1-1/+1
2019-02-08RISC-V: Add FP register core file support.Jim Wilson2-2/+27
This adds fp reg support similar to the existing general reg support. This fixes one gdb testsuite failure FAIL: gdb.base/gcore.exp: corefile restored system registers which fails without the patch because fcsr was missing. Otherwise, no regressions with riscv64-linux native testsuite run. gdb/ * riscv-linux-tdep.c (riscv_linux_fregmap): New. (riscv_linux_fregset): New. (riscv_linux_iterate_over_regset_sections): Call cb for .reg2 section.
2019-02-08Add missing ChangeLog files for previous patch.Jim Wilson2-0/+10
2019-02-08RISC-V: Compress 3-operand beq/bne against x0.Jim Wilson2-0/+8
This lets us accept an instruction like beq a2,x0,.Label and generate a compressed beqz. This will allow some future simplications to the gcc support, e.g. eliminating some duplicate patterns, and avoiding adding new duplicate patterns, since currently we have to handle signed and equality compares against zero specially. Tested with rv{32,64}-{elf,linux} cross builds and make checks for binutils and gcc. There were no regressions. gas/ * config/tc-riscv.c (validate_riscv_insn) <'C'>: Add 'z' support. (riscv_ip) <'C'>: Add 'z' support. opcodes/ * riscv-opc.c (riscv_opcodes) <beq>: Use Cz to compress 3 operand form. <bne>: Likewise.
2019-02-08binutils: Add new GNU format mode to `size` utilityAndrew Burgess5-38/+145
The size tool currently defaults to berkeley format output. However, this output format has a weird quirk, read-only data is counted against the text sections, not the data sections. The code offers no real explanation for why this is, but I'm reluctant to change it for two reasons, first, I'm assuming it probably makes sense in some case that I'm not thinking of (maybe a target where sections are not marked executable, and so there's no distinction between read-only data and code), and second, the code has been this way for at least 20 years, I worry that changing things now might cause more confusion than it solves. This commit then introduces a new output format for the size tool, this new format displays the results in a similar manor to the berkeley format, but counts read-only data in the data column, and only executable sections are counted in the text column. Given that this is a brand new output format I've gone ahead and simplified things a little, while the berkeley format displays the total twice, once in decimal and once in hex, the new display format just displays the total in decimal. Of course, there's still the '--radix' option which can be used to display all the results in hexadecimal or octal. I've called the new format 'gnu', so '--format=gnu' or '-G' are used to access it. binutils/ChangeLog: * size.c (berkeley_format): Delete. (enum output_format): New enum. (selected_output_format): New variable. (usage): Update to mention GNU format. (main): Update to extract options, and select format as needed. Handle GNU format where needed. (berkeley_sum): Renamed to... (berkeley_or_gnu_sum): ...this, and updated to handle both formats. (berkeley_format): Renamed to... (berkeley_or_gnu_format): ...this, and updated to handle both formats. (print_sizes): Handle GNU format. * doc/binutils.texi (size): Document new GNU format. * testsuite/binutils-all/size.exp: Add test of extended functionality. * NEWS: Mention new functionality.
2019-02-08Make inline plt reloc "unsupported for bss-plt" an errorAlan Modra2-2/+7
This was always supposed to be an error. Code emitted by gcc for inline PLT calls assumes PLT is an array of addresses. * elf32-ppc.c (ppc_elf_relocate_section): Add %X to "unsupported for bss-plt" warning to make it an error.
2019-02-08binutils/size: Update example output in documentationAndrew Burgess2-3/+8
The example output from size in Berkeley format is out of date. The columns are now displayed right aligned. This patch updates the documentation to reflect reality. binutils/ChangeLog: * doc/binutils.texi (size): Update example output for Berkeley format output.
2019-02-08Automatic date update in version.inGDB Administrator1-1/+1
2019-02-07Arm: Backport hlt to all architectures.Tamar Christina7-2/+85
The software trap instruction HLT that was introduced in Armv8-a is used as the semihosting trap instruction in AArch64. In order to allow systems configured to run AArch64 code to also run AArch32 with semihosting it was decided that AArch32 should also use HLT in the case of the "mixed mode" environment. This requires that HLT also be backported to all earlier architectures. The instruction is in the undefined encoding space earlier architectures but must trigger a semihosting trap [3]. The Arm Architectural Reference Manual [1] doesn't explicitly mention this however this is an explicit requirement in the Semihosting-v2 protocol [2]. [1] https://developer.arm.com/docs/ddi0487/latest/arm-architecture-reference-manual-armv8-for-armv8-a-architecture-profile [2] https://developer.arm.com/docs/100863/latest/the-semihosting-interface [3] https://github.com/qemu/qemu/commit/19a6e31c9d2701ef648b70ddcfc3bf64cec8c37e gas/ChangeLog: * config/tc-arm.c (insns): Redefine THUMB_VARIANT and ARM_VARIANT for hlt to armv1. * testsuite/gas/arm/armv8a-automatic-hlt.d: Update TAGs * testsuite/gas/arm/hlt.d: New test. * testsuite/gas/arm/hlt.s: New test. opcodes/ChangeLog: * arm-dis.c (arm_opcodes): Redefine hlt to armv1.
2019-02-07AArch64: Add negative tests for Armv8.3-a complex number instructions ↵Tamar Christina3-0/+131
instructions. This patch just adds a few negative tests for the Armv8.3-a complex instructions. These already do the right disassembly without needing a verifier, but adding some tests to make sure that stays that way. gas/ChangeLog: * testsuite/gas/aarch64/undefined_advsimd_armv8_3.d: New test. * testsuite/gas/aarch64/undefined_advsimd_armv8_3.s: New test.
2019-02-07AArch64: Add verifier for By elem Single and Double sized instructions.Tamar Christina7-9/+147
The AArch64 instruction set has cut-outs inside instructions encodings for when a given encoding that would normally fall within the encoding space of an instruction is instead undefined. This updates the first few instructions FMLA, FMLA, FMUL and FMULX in the case where sz:L == 11. gas/ChangeLog: PR binutils/23212 * testsuite/gas/aarch64/undefined_by_elem_sz_l.s: New test. * testsuite/gas/aarch64/undefined_by_elem_sz_l.d: New test. opcodes/ChangeLog: PR binutils/23212 * aarch64-opc.h (enum aarch64_field_kind): Add FLD_sz. * aarch64-opc.c (verify_elem_sd): New. (fields): Add FLD_sz entr. * aarch64-tbl.h (_SIMD_INSN): New. (aarch64_opcode_table): Add elem_sd verifier to fmla, fmls, fmul and fmulx scalar and vector by element isns.
2019-02-07SPARC: fix PR ld/18841Eric Botcazou3-2/+71
This fixes the last ld failures on SPARC64/Linux: FAIL: Run pr18841 with libpr18841b.so FAIL: Run pr18841 with libpr18841c.so FAIL: Run pr18841 with libpr18841bn.so (-z now) FAIL: Run pr18841 with libpr18841cn.so (-z now) by mimicing what has been done on x86-64 and Aarch64 to fix the PR. bfd/ PR ld/18841 * elf32-sparc.c (elf32_sparc_reloc_type_class): Return reloc_class_ifunc for ifunc symbols. * elf64-sparc.c (elf64_sparc_reloc_type_class): Likewise.
2019-02-07Visium: fix bogus overflow check on 32-bit hostsEric Botcazou2-7/+11
bfd/ * elf32-visium.c (visium_elf_howto_parity_reloc): Minor tweak. <R_VISIUM_PC16>: Use explicit range test to detect an overflow.
2019-02-07Visium: align branch absolute instruction for the GR6Eric Botcazou7-10/+41
This is done in order to avoid a pipeline hazard on the GR6. gas/ * config/tc-visium.c (md_assemble) <mode_cad>: Align instruction on 64-bit boundaries for the GR6. * testsuite/gas/visium/allinsn_gr6.s: Tweak. * testsuite/gas/visium/allinsn_gr6.d: Likewise. * testsuite/gas/visium/bra-1.d: New test. * testsuite/gas/visium/bra-1.s: Likewise. * testsuite/gas/visium/visium.exp: Run bra-1 test.
2019-02-07Fix typo in description of --start-group/--end-group options.Nick Clifton2-1/+7
PR 24175 * ld.texi (Options): Add missing word to the description of the --start-group option.
2019-02-07Updated Swedish translation for the opcodes sub-directoryNick Clifton2-308/+352
2019-02-07gdbserver: When attaching, add process before lwpsAlan Hayward5-24/+100
The recent BP/WP changes for AArch64 swapping the order in add_lwp() so that the process was added before the lwp. This was due to the lwp creation requiring the process data. This also needs changing in linux_attach(). Also add additional checks to make sure cannot attach to the same process twice. Add test case for this - do this by splitting attach.exp into distinct pass and error case sections. Fixes gdb.server/ext-attach.exp on Aarch64. gdb/gdbserver/ChangeLog: * linux-low.c (linux_attach): Add process before lwp. * server.c (attach_inferior): Check if already attached. gdb/testsuite/ChangeLog: * gdb.base/attach.exp: Add double attach test.
2019-02-07Move potentially obsolete BFD targets into the definitely obsolete section. ↵Nick Clifton5-11/+23
Add a note to the README-how-to-make-a-release document about doing this. bfd * config.bfd: Move the powerpc-lynxos and powerpc-windiss targets into the definitely obsolete list. binutils * README-how-to-make-a-release: Add a note about updating the obsolete targets in the bfd/config.bfd file.
2019-02-07Make gdb.base/corefile.exp work on terminals with few rowsSimon Marchi2-24/+26
When creating a pty to spawn a subprocess (such as gdb), Expect copies the settings of its own controlling terminal, including the number of rows and columns. If you "make check" on a terminal with just a few rows (e.g. 4), GDB will paginate before reaching the initial prompt. In default_gdb_start, used by most tests, this is already handled: if we see the pagination prompt, we sent \n to continue. Philippe reported that gdb.base/corefile.exp didn't work in terminals with just a few rows. This test spawns GDB by hand, because it needs to check things before the initial prompt, which it couldn't do if it used default_gdb_start. In this case I think it's not safe to use the same technique as in default_gdb_start. Even if we could send a \n if we see a pagination prompt, we match some multiline regexes in there. So if a pagination slips in there, it might make the regexes not match and fail the test. It's also not possible to use -ex "set height 0" or -iex "set height 0", it is handled after the introduction text is shown. The simplest way I found to avoid showing the pagination completely is to set stty_init (documented in expect's man page) to initialize gdb's pty with a fixed number of rows. And actually, if we set stty_init in gdb_init, it works nicely as a general solution applicable to all tests. We can therefore remove the solution introduced in e882ef3cfc3 ("testsuite: expect possible pagination when starting gdb") where we matched the pagination prompt during startup. gdb/testsuite/ChangeLog: * lib/gdb.exp (default_gdb_start): Don't match pagination prompt. (gdb_init): Set stty_init.
generated by cgit v1.1 at 2024-11-20 10:23:10 +0000