- 22 Nov, 2017 4 commits
-
-
Gary Benson authored
This commit adds two new commands which may be used to test thread debugging libraries used by GDB: * "maint check libthread-db" tests the thread debugging library GDB is using for the current inferior. * "maint set/show check-libthread-db" selects whether libthread_db tests should be run automatically as libthread_db is auto-loaded. The default is to not run tests automatically. The test itself is a basic integrity check exercising all libthread_db functions used by GDB on GNU/Linux systems. By extension this also exercises the proc_service functions provided by GDB that libthread_db uses. This functionality is useful for NPTL developers and libthread_db developers. It could also prove useful investigating bugs reported against GDB where the thread debugging library or GDB's proc_service layer is suspect. gdb/ChangeLog: * linux-thread-db.c (valprint.h): New include. (struct check_thread_db_info): New structure. (check_thread_db_on_load, tdb_testinfo): New static globals. (check_thread_db, check_thread_db_callback): New functions. (try_thread_db_load_1): Run integrity checks if requested. (maintenance_check_libthread_db): New function. (_initialize_thread_db): Register "maint check libthread-db" and "maint set/show check-libthread-db". gdb/doc/ChangeLog: * gdb.texinfo (Maintenance Commands): Document "maint check libthread-db" and "maint set/show check-libthread-db". gdb/testsuite/ChangeLog: * gdb.threads/check-libthread-db.exp: New file. * gdb.threads/check-libthread-db.c: Likewise. -
claziss authored
For ARCv2, h-regs are only valid unitl r31. gas/ 2017-11-21 Claudiu Zissulescu <claziss@synopsys.com> * testsuite/gas/arc/hregs-err.s: New test. opcodes/ 2017-11-21 Claudiu Zissulescu <claziss@synopsys.com> * arc-opc.c (insert_rhv2): Check h-regs range. -
H.J. Lu authored
The -n command-line of x86 assembler disables optimization of alignment directives, like ".balign 8, 0x90", with multi-byte nop instructions such as leal 0(%esi),%esi. PR gas/22464 * testsuite/gas/i386/align-1.s: New file. * testsuite/gas/i386/align-1a.d: Likewise. * testsuite/gas/i386/align-1b.d: Likewise. * testsuite/gas/i386/i386.exp: Run align-1a and align-1b.
-
GDB Administrator authored
-
- 21 Nov, 2017 20 commits
-
-
Jerome Guitton authored
When debugging a program using a ravenscar runtime, the thread layer sometimes gets confused, and even missing some threads. This was traced to an assumption that ravenscar_wait was making, which is that calling the "to_wait" target_ops method would set the inferior_ptid, so that we could then use that assumption to update our thread_list and current ptid. However, this has not been the case for quite a while now. This patch fixes the problem by assigning inferior_ptid the ptid returned by "to_wait". gdb/ChangeLog: * ravenscar-thread.c (ravenscar_wait): Update inferior ptid with event ptid from the lower layer before doing the ravenscar-specific update.
-
Joel Brobecker authored
Connecting to a TSIM simulator over the remote protocol causes GDB to crash with the following failed assertion: (gdb) tar remote :1234 Remote debugging using :1234 /[...]/gdb/ravenscar-thread.c:182: internal-error: ravenscar_update_inferior_ptid: Assertion `!is_ravenscar_task (inferior_ptid)' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) y What happens is the following. Upon connection to the target, GDB sends a 'qfThreadInfo' query, which is the query asking the target for the ID of the first thread, and TSIM replies 'm0': Sending packet: $qfThreadInfo#bb...Ack Packet received: m0 As a result of this, GDB takes the '0' as the TID, and because of it, constructs a ptid whose value is {42000, 0, 0}. This trips our !is_ravenscar_task check, because all it does to identify threads corresponding to ravenscar tasks is that their lwp is null, because that's how we construct their ptid. But this is unfortunatly not sufficient when debugging with TSIM, because the thread ID that TSIM returns causes the creation of a ptid whose lwp is zero, which matches the current identification scheme and yet is clearly not a ravenscar task. The fix is to also make sure that the ptid's tid field is nonzero. gdb/ChangeLog: * ravenscar-thread.c (is_ravenscar_task): Also verify that the ptid's TID is nonzero. -
Joel Brobecker authored
Trying to debug a program using a stripped version of the ravenscar runtime, we can get the following error: (gdb) cont Continuing. Cannot find Ada_Task_Control_Block type. Aborting This is because the ravenscar-thread layer makes the assumption that the runtime is built the way we expect it, meaning that the Ada tasking units we rely on for Ada tasking debugging, are built with debugging information, and that this debug information has not been stripped from the runtime. When this assumption is not true, resuming such a program can trigger the error above, which then leads GDB a little confused. For instance, we can see things like: (gdb) bt Target is executing. This patch fixes the issue by disabling the ravenscar thread layer if we detect that the runtime is missing some of the debugging info we need in order to support Ada task debugging. This is the best we can do, as the ravenscar-thread layer actually depends on the ada-tasks layer to implement thread debugging. gdb/ChangeLog: * ada-lang.h (ada_get_tcb_types_info): Add declaration. * ada-tasks.c (ada_get_tcb_types_info): Renames get_tcb_types_info. Make non-static. Change return type to char *. Adjust code accordingly. Rewrite the function's documentation. (read_atcb): Adjust call to get_tcb_types_info accordingly. * ravenscar-thread.c (ravenscar_inferior_created): Check that we have enough debugging information in the runtime to support Ada task debugging before we enable the ravenscar-thread layer. -
Joel Brobecker authored
This patch reworks the ravenscar-thread layer to remove the assumption that the target only has 1 CPU. In particular, when connected to a QEMU target over the remote protocol, QEMU reports each CPU as one thread. This patch adapts the ravenscar-thread layer to this, and adds a large comment explaining the general design of this unit. gdb/ChangeLog: * ada-lang.h (ada_get_task_info_from_ptid): Add declaration. * ada-tasks.c (ada_get_task_info_from_ptid): New function. * ravenscar-thread.c: Add into comment. (base_magic_null_ptid): Delete. (base_ptid): Change documentation. (ravenscar_active_task): Renames ravenscar_running_thread. All callers updated throughout. (is_ravenscar_task, ravenscar_get_thread_base_cpu): New function. (ravenscar_task_is_currently_active): Likewise. (get_base_thread_from_ravenscar_task): Ditto. (ravenscar_update_inferior_ptid): Adjust to handle multiple CPUs. (ravenscar_runtime_initialized): Likewise. (get_running_thread_id): Add new parameter "cpu". Adjust implementation to handle this new parameter. (ravenscar_fetch_registers): Small adjustment to use is_ravenscar_task and ravenscar_task_is_currently_active in order to decide whether to use the target beneath or this module's arch_ops. (ravenscar_store_registers, ravenscar_prepare_to_store): Likewise. (ravenscar_stopped_by_sw_breakpoint): Use get_base_thread_from_ravenscar_task to get the underlying thread, rather than using base_ptid. (ravenscar_stopped_by_hw_breakpoint, ravenscar_stopped_by_watchpoint) (ravenscar_stopped_data_address, ravenscar_core_of_thread): Likewise. (ravenscar_inferior_created): Do not set base_magic_null_ptid. -
Joel Brobecker authored
At the user level, this patch enhances the debugger to print the ID of the base CPU a task is running on: (gdb) info task 3 Ada Task: 0x13268 Name: raven1 Thread: 0x13280 LWP: 0 !!!-> Base CPU: 1 No parent Base Priority: 127 State: Runnable This new field is only printed when the base CPU is nonzero or, in other words, if the base CPU info is being provided by the runtime. For instance, on native systems, where threads/processes can "jump" from CPU to CPU, the info is not available, and the output of the command above then remains unchanged. At the internal level, the real purpose of this change is to prepare the way for ravenscar-thread to start handling SMP systems. For that, we'll need to know which CPU each task is running on... More info on that in the commit that actually adds support for it. gdb/ChangeLog: * ada-lang.h (struct ada_task_info) <base_cpu>: New field. * ada-lang.c (struct atcb_fieldno) <base_cpu>: New field. (get_tcb_types_info): Set fieldnos.base_cpu. (read_atcb): Set task_info->base_cpu. (info_task): Print "Base CPU" info if set by runtime. -
Joel Brobecker authored
We have noticed a regression in our watchpoint support when debugging through the remote protocol a program running on a bare metal platform, when the program uses what we call the Ravenscar Runtime. This runtime is a subset of the Ada runtime defined by the Ravenscar Profile. One of the nice things about this runtime is that it provides tasking, which is equivalent to the concept of threads in C (it is actually often mapped to threads, when available). For bare metal targets, however, there is no OS, and therefore no thread layer. What we did, then, was add a ravenscar-thread layer, which has insider knowledge of the runtime to get the list of threads, but also all necessary info to perform thread switching. For the record, the commit which caused the regression is: commit 799a2abe Date: Mon Nov 30 16:05:16 2015 +0000 Subject: remote: stop reason and watchpoint data address per thread Running local-watch-wrong-thread.exp with "maint set target-non-stop on" exposes that gdb/remote.c only records whether the target stopped for a breakpoint/watchpoint plus the watchpoint data address *for the last reported remote event*. But in non-stop mode, we need to keep that info per-thread, as each thread can end up with its own last-status pending. Our testcase is very simple. We have a package defining a global variable named "Watch"... package Pck is Watch : Integer := 1974; end Pck; ... and a main subprogram which changes its value procedure Foo is begin Pck.Watch := Pck.Watch + 1; end Foo; To reproduce, we built our program as usual, started it in QEMU, and then connected GDB to QEMU... (gdb) target remote :4444 (gdb) break _ada_foo (gdb) cont <--- this is to make sure the program is started and the variable we want to watch is initialized ... at which point we try to use a watchpoint on our global variable: (gdb) watch watch ... but, upon resuming the execution with a "cont", we expected to get a watchpoint-hit notification, such as... (gdb) cont Hardware watchpoint 2: watch Old value = 1974 New value = 1975 0xfff00258 in foo () at /[...]/foo.adb:6 6 end Foo; ... but unfortunately, we get a SIGTRAP instead: (gdb) cont Program received signal SIGTRAP, Trace/breakpoint trap. foo () at /[...]/foo.adb:6 6 end Foo; What happens is that, on the one hand, the change in remote.c now stores the watchpoint-hit notification info in the thread that received it; and on the other hand, we have a ravenscar-thread layer which manages the thread list on top of the remote protocol layer. The two of them get disconnected, and this eventually results in GDB not realizing that we hit a watchpoint. Below is how: First, once connected and just before inserting our watchpoint, we have the ravenscar-thread layer which built the list of threads by extracting some info from inferior memory, giving us the following two threads: (gdb) info threads Id Target Id Frame 1 Thread 0 "0Q@" (Ravenscar task) foo () at /[...]/foo.adb:5 * 2 Thread 0x24618 (Ravenscar task) foo () at /[...]/foo.adb:5 The first thread is the only thread QEMU told GDB about. The second one is a thread that the ravenscar-thread added. QEMU has now way to know about those threads, since they are really embedded inside the program; that's why we have the ravenscar layer, which uses inside-knowledge to extract the list of threads. Next, we insert a watchpoint, which applies to all threads. No problem so far. Then, we continue; meaning that GDB sends a Z2 packet to QEMU to get the watchpoint inserted, then a vCont to resume the program's execution. The program hits the watchpoints, and thererfore QEMU reports it back: Packet received: T05thread:01;watch:000022c4; Since QEMU knows about one thread and one thread only, it stands to reason that it would say that the event applies to thread:01, which is our first thread in the "info threads" listing. That thread has a ptid of {42000, lwp=1, tid=0}. This is where Pedro's change kicks in: Seeing this event, and having determined that the event was reported for thread 01, and therefore ptid {42000, lwp=1, tid=0}, it saves the watchpoint-hit event info in the private area of that thread/ptid. Once this is done, remote.c's event-wait layer returns. Enter the ravenscar-thread layer of the event-wait, which does a little dance to delegate the wait to underlying layers with ptids that those layers know about, and then when the target_beneath's to_wait is done, tries to figure out which thread is now the active thread. The code looks like this: 1. inferior_ptid = base_ptid; 2. beneath->to_wait (beneath, base_ptid, status, 0); 3. [...] 4. ravenscar_update_inferior_ptid (); 5. 6. return inferior_ptid; Line 1 is where we reset inferior_ptid to the ptid that the target_beneath layer knows about, allowing us to then call its to_wait implementation (line 2). And then, upon return, we call ravenscar_update_inferior_ptid, which reads inferior memory to determine which thread is actually active, setting inferior_ptid accordingly. Then we return that inferior_ptid (which, again, neither QEMU and therefore nor the remote.c layer knows about). Upon return, we eventually arrive to the part where we try to handle the inferior event: we discover that we got a SIGTRAP and, as part of its handling, we call watchpoints_triggered, which calls target_stopped_by_watchpoint, which eventually remote_stopped_by_watchpoint, where Pedro's change kicks in again: struct thread_info *thread = inferior_thread (); return (thread->priv != NULL && thread->priv->stop_reason == TARGET_STOPPED_BY_WATCHPOINT); Because the ravenscar-thread layer changed the inferior_ptid to the ptid of the active thread, inferior_thread now returns the private data of that thread. This is not the thread that QEMU reported the watchpoint-hit on, and thus, the function returns "no watchpoint hit, mister". Hence GDB not understanding the SIGTRAP, thus reporting it verbatim. The way we chose to fix the issue is by making sure that the ravenscar-thread layer doesn't let the remote layer be called with inferior_ptid being set to a thread that the remote layer does not know about. gdb/ChangeLog: * ravenscar-thread.c (ravenscar_stopped_by_sw_breakpoint) (ravenscar_stopped_by_hw_breakpoint, ravenscar_stopped_by_watchpoint) (ravenscar_stopped_data_address, ravenscar_core_of_thread): New functions. (init_ravenscar_thread_ops): Set the to_stopped_by_sw_breakpoint, to_stopped_by_hw_breakpoint, to_stopped_by_watchpoint, to_stopped_data_address and to_core_of_thread fields of ravenscar_ops. -
H.J. Lu authored
Check in the object file generated from the older assembler as a compressed file. PR binutils/22451 * testsuite/binutils-all/x86-64/objects.exp: New file. * testsuite/binutils-all/x86-64/pr22451.o.bz2: Likewise.
-
Ulrich Weigand authored
Current versions of GCC support switching the format used for "long double" to either IBM double double or IEEE-128. The resulting binary is marked via different setting of the Tag_GNU_Power_ABI_FP GNU attribute. This patch checks this attribute to detect the format of the default "long double" type and sets GDB's notion of the format accordingly. The patch also adds support for the "__ibm128" type, which always uses IBM double double format independent of the format used for "long double". A new test case verifies that all three types, "long double", "__float128", and "__ibm128" are correctly detected in all three compiler settings, the default setting, -mabi=ieeelongdouble, and -mabi=ibmlongdouble. gdb/ChangeLog: 2017-11-21 Ulrich Weigand <uweigand@de.ibm.com> * ppc-tdep.h (enum powerpc_long_double_abi): New data type. (struct gdbarch_tdep): New member long_double_abi. * rs6000-tdep.c (rs6000_gdbarch_init): Initialize long_double_abi member of tdep struct based on Tag_GNU_Power_ABI_FP attribute. * ppc-linux-tdep.c (ppc_linux_init_abi): Install long double data format depending on long_double_abi tdep member. (ppc_floatformat_for_type): Handle __ibm128 type. gdb/testsuite/ChangeLog: 2017-11-21 Ulrich Weigand <uweigand@de.ibm.com> * gdb.arch/ppc-longdouble.exp: New file. * gdb.arch/ppc-longdouble.c: Likewise.
-
Pedro Alves authored
This new testcase has a test that fails like this here: $1 = (<data variable, no debug info> *) 0x60208c <some_minsym> (gdb) FAIL: gdb.ada/minsyms.exp: print &some_minsym The problem is that the testcase hardcodes an expected address for the "some_minsym" variable, which obviously isn't stable. Fix that by expecting $hex instead. gdb/testsuite/ChangeLog: 2017-11-21 Pedro Alves <palves@redhat.com> * gdb.ada/minsyms.exp: Accept any address for 'some_minsym'.
-
Nick Clifton authored
PR 22419 * emultempl/v850elf.em (v850_create_output_section_statements): New function. Generate an error if attempting to convert the format of the output file. * testsuite/ld-unique/pr21529.d: Skip for the V850. * testsuite/ld-elf/pr21884.d: Skip for the V850.
-
claziss authored
2017-11-21 Claudiu Zissulescu <claziss@synopsys.com> * testsuite/binutils-all/arc/objdump.exp: Update pattern matching expression.
-
claziss authored
opcodes/ 2017-11-21 Claudiu Zissulescu <claziss@synopsys.com> * arc-dis.c (print_insn_arc): Pretty print pc-relative offsets. * arc-opc.c (SIMM21_A16_5): Make it pc-relative. gas/ 2017-11-21 Claudiu Zissulescu <claziss@synopsys.com> * testsuite/gas/arc/b.d : Update test. * testsuite/gas/arc/bl.d: Likewise. * testsuite/gas/arc/jli-1.d: Likewise. * testsuite/gas/arc/lp.d: Likewise. * testsuite/gas/arc/pcl-relocs.d: Likewise. * testsuite/gas/arc/pcrel-relocs.d: Likewise. * testsuite/gas/arc/pic-relocs.d: Likewise. * testsuite/gas/arc/plt-relocs.d: Likewise. * testsuite/gas/arc/pseudos.d: Likewise. * testsuite/gas/arc/relax-avoid2.d: Likewise. * testsuite/gas/arc/relax-avoid3.d: Likewise. * testsuite/gas/arc/relax-b.d: Likewise. * testsuite/gas/arc/tls-relocs.d: Likewise. * testsuite/gas/arc/relax-add01.d: Likewise. * testsuite/gas/arc/relax-add04.d: Likewise. * testsuite/gas/arc/relax-ld01.d: Likewise. * testsuite/gas/arc/relax-sub01.d: Likewise. * testsuite/gas/arc/relax-sub02.d: Likewise. * testsuite/gas/arc/relax-sub04.d: Likewise. * testsuite/gas/arc/pcl-print.s: New file. * testsuite/gas/arc/pcl-print.d: Likewise. * testsuite/gas/arc/nps400-12.d: Likewise. ld/ 2017-11-21 Claudiu Zissulescu <claziss@synopsys.com> * testsuite/ld-arc/jli-simple.d: Update test.
-
Nick Clifton authored
* dwarf.c (dwo_name, dwo_dir, dwo_id, dwo_id_len): New variables. (read_and_display_attr_value): Record dwo variables if requested. (display_augmentation_data): Rename to display_data and make generic. (load_dwo_file): New function. Loads a separate dwarf object file. (load_separate_debug_file): Add reporting and loading of separate dwarf objet files. * readelf.c (process_section_headers): Add do_debug_links to list of flags requiring a debug dump. (display_debug_section): Tidy up code. * doc/debug.options.texi: Add note that dwo links will also be followed. * testsuite/binutils-all/debuglink.s: Tidy code. * testsuite/binutils-all/dwo.s: New test file. * testsuite/binutils-all/readelf.wk2: New file - expected output from readelf. * testsuite/binutils-all/readelf.exp: Run the new test.
-
Simon Marchi authored
Fix: /Users/simark/src/binutils-gdb/gdb/darwin-nat.c:2404:3: error: no matching function for call to 'add_setshow_boolean_cmd' add_setshow_boolean_cmd ("mach-exceptions", class_support, ^~~~~~~~~~~~~~~~~~~~~~~ gdb/ChangeLog: * darwin-nat.c (set_enable_mach_exceptions): Constify parameter. -
Alan Modra authored
A followup to PR22443. * elf-bfd.h (elf_symbol_from): Check for NULL symbol bfd. * elfcode.h (elf_slurp_reloc_table_from_section): Add FIXME comment.
-
Alan Modra authored
* config/tc-xtensa.c (finish_vinsn): Avoid multiple ngettext calls in error message.
-
Pedro Alves authored
Here we want to find where we'd insert "after", so we want std::lower_bound, not std::upper_bound. gdb/ChangeLog: 2017-11-21 Pedro Alves <palves@redhat.com> * dwarf2read.c (mapped_index::find_name_components_bounds) <completion mode, upper bound>: Use std::lower_bound instead of std::upper_bound. (test_mapped_index_find_name_component_bounds): Remove incorrect "t1_fund" from expected symbols.
-
Pedro Alves authored
This commit factors out the name-components-vector building and bounds searching out of dw2_expand_symtabs_matching_symbol into separate functions, and adds unit tests that: - expose both the latent bug mentioned in the previous commit, and also, - for completeness exercise the 0xff character handling fixed in the previous commit more directly. The actual fix for the now-exposed bug is left for the following patch. gdb/ChangeLog: 2017-11-21 Pedro Alves <palves@redhat.com> * dwarf2read.c (mapped_index::name_components_casing): New field. (mapped_index) <build_name_components, find_name_components_bounds): Declare new methods. (mapped_index::find_name_components_bounds) (mapped_index::build_name_components): New methods, factored out from dw2_expand_symtabs_matching_symbol. (check_find_bounds_finds) (test_mapped_index_find_name_component_bounds): New. (run_test): Rename to ... (test_dw2_expand_symtabs_matching_symbol): ... this. (run_test): Reimplement.
-
Pedro Alves authored
The find-upper-bound-for-completion algorithm in the name components accelerator table in dwarf2read.c increments a char in a string, and asserts that it's not incrementing a 0xff char, but that's incorrect. First, we shouldn't be calling gdb_assert on input. Then, if "char" is signed, comparing a caracther with "0xff" will never yield true, which is caught by Clang with: error: comparison of constant 255 with expression of type '....' (aka 'char') is always true [-Werror,-Wtautological-constant-out-of-range-compare] gdb_assert (after.back () != 0xff); ~~~~~~~~~~~~~ ^ ~~~~ And then, 0xff is a valid character on non-UTF-8/ASCII character sets. E.g., it's 'ÿ' in Latin1. While GCC nor Clang support !ASCII && !UTF-8 characters in identifiers (GCC supports UTF-8 characters only via UCNs, see https://gcc.gnu.org/onlinedocs/cpp/Character-sets.html), but other compilers might (Visual Studio?), so it doesn't hurt to handle it correctly. Testing is covered by extending the dw2_expand_symtabs_matching unit tests with relevant cases. However, without further changes, the unit tests still fail... The problem is that cp-name-parser.y assumes that identifiers are ASCII (via ISALPHA/ISALNUM). This commit fixes that too, so that we can unit test the dwarf2read.c changes. (The regular C/C++ lexer in c-lang.y needs a similar treatment, but I'm leaving that for another patch.) While doing this, I noticed a thinko in the computation of the upper bound for completion in dw2_expand_symtabs_matching_symbol. We're using std::upper_bound but we should use std::lower_bound. I extended the unit test with a case that I thought would expose it, this one: + /* These are used to check that the increment-last-char in the + matching algorithm for completion doesn't match "t1_fund" when + completing "t1_func". */ + "t1_func", + "t1_func1", + "t1_fund", + "t1_fund1", The algorithm actually returns "t1_fund1" as lower bound, so "t1_fund" matches incorrectly. But turns out the problem is masked because later here: for (;lower != upper; ++lower) { const char *qualified = index.symbol_name_at (lower->idx); if (!lookup_name_matcher.matches (qualified) the lookup_name_matcher.matches check above filters out "t1_fund" because that doesn't start with "t1_func". I'll fix the latent bug in follow up patches, after factoring things out a bit in a way that allows unit testing the relevant code more directly. gdb/ChangeLog: 2017-11-21 Pedro Alves <palves@redhat.com> * cp-name-parser.y (cp_ident_is_alpha, cp_ident_is_alnum): New. (symbol_end): Use cp_ident_is_alnum. (yylex): Use cp_ident_is_alpha and cp_ident_is_alnum. * dwarf2read.c (make_sort_after_prefix_name): New function. (dw2_expand_symtabs_matching_symbol): Use it. (test_symbols): Add more symbols. (run_test): Add tests.
-
GDB Administrator authored
-
- 20 Nov, 2017 16 commits
-
-
Pedro Alves authored
The gdb.base/whatis-ptype-typedefs.exp testcase has several tests that fail on 32-bit architectures. E.g., on 'x86-64 -m32', I see: ... FAIL: gdb.base/whatis-ptype-typedefs.exp: lang=c: cast: whatis (float_typedef) v_uchar_array_t_struct_typedef (invalid) FAIL: gdb.base/whatis-ptype-typedefs.exp: lang=c: cast: ptype (float_typedef) v_uchar_array_t_struct_typedef (invalid) ... gdb.log: (gdb) whatis (float_typedef) v_uchar_array_t_struct_typedef type = float_typedef (gdb) FAIL: gdb.base/whatis-ptype-typedefs.exp: lang=c: cast: whatis (float_typedef) v_uchar_array_t_struct_typedef (invalid) As Simon explained [1], the issue boils down to the fact that on 64-bit, this is an invalid cast: (gdb) p (float_typedef) v_uchar_array_t_struct_typedef Invalid cast. while on 32 bits it is valid: (gdb) p (float_typedef) v_uchar_array_t_struct_typedef $1 = 1.16251721e-41 The expression basically tries to cast an array (which decays to a pointer) to a float. The cast works on 32 bits because a float and a pointer are of the same size, and value_cast works in that case: ~~~ More general than a C cast: accepts any two types of the same length, and if ARG2 is an lvalue it can be cast into anything at all. */ ~~~ On 64 bits, they are not the same size, so it ends throwing the "Invalid cast" error. The testcase is expecting the invalid cast behavior, thus the FAILs. A point of these tests was to cover as many code paths in value_cast as possible, as a sort of documentation of the current behavior: # The main idea here is testing all the different paths in the # value casting code in GDB (value_cast), making sure typedefs are # preserved. ... # We try all combinations, even those that don't parse, or are # invalid, to catch the case of a regression making them # inadvertently valid. For example, these convertions are # invalid: ... In that spirit, this commit makes the testcase adjust itself depending on size of floats and pointers, and also test floats of different sizes. Passes cleanly on x86-64 GNU/Linux both -m64/-m32. [1] - https://sourceware.org/ml/gdb-patches/2017-11/msg00382.html gdb/ChangeLog: 2017-11-20 Pedro Alves <palves@redhat.com> * gdb.base/whatis-ptype-typedefs.c (double_typedef) (long_double_typedef): New typedefs. Use DEF on double and long double. * gdb.base/whatis-ptype-typedefs.exp: Add double and long double cases. (run_tests): New 'float_ptr_same_size', 'double_ptr_same_size', and 'long_double_ptr_same_size' locals. Use them to decide whether cast from array/function to float is valid/invalid. -
Nick Clifton authored
PR 22450 gas * elf-properties.c (_bfd_elf_link_setup_gnu_properties): Skip objects without a GNU_PROPERTY note section when looking for a bfd onto which notes can be accumulated. ld * testsuite/ld-elf/elf.exp: Add --defsym ALIGN=2|3 to assembler command line depending upon the size of the target address space. * testsuite/ld-elf/pr22450.s: New test file. * testsuite/ld-elf/pr22450.d: New test driver. * testsuite/config/default.exp: Add note that LD_CLASS refers to the size of the host linker not the size of the target linker.
-
Alan Modra authored
Some x86_64 targets pad sections with nops. * testsuite/gas/i386/x86-64-reg-bad.l: Accept trailing padding.
-
Alan Modra authored
Setting SHF_GROUP unconditionally on rel/rela sections associated with SHF_GROUP sections fails badly with objcopy/strip and ld -r if the input file SHT_GROUP section didn't specify the rel/rela sections. This patch rearranges where SHF_GROUP is set for rel/rela sections. PR 22451 PR 22460 * elf.c (_bfd_elf_init_reloc_shdr): Delete "sec_hdr" parameter and leave rel_hdr->sh_flags zero. Update calls. (bfd_elf_set_group_contents): Check input rel/rela SHF_GROUP flag when !gas before adding rel/rela section to group. Set output rel/rela SHF_GROUP flags.
-
Simon Marchi authored
Replace with for_each_thread. gdb/gdbserver/ChangeLog: * linux-low.c (kill_one_lwp_callback): Return void, take argument directly, don't filter on pid. (linux_kill): Use for_each_thread.
-
Simon Marchi authored
Replace with find_thread. gdb/gdbserver/ChangeLog: * linux-low.c (need_step_over_p): Return bool, remove dummy argument. (linux_resume, proceed_all_lwps): Use find_thread.
-
Simon Marchi authored
Replace with find_thread. Instead of setting the flag in the callback, make the callback return true/false, and check the result against NULL in the caller. gdb/gdbserver/ChangeLog: * linux-low.c (resume_status_pending_p): Return bool, remove flag_p argument. (linux_resume): Use find_thread.
-
Simon Marchi authored
Replace it with for_each_thread. gdb/gdbserver/ChangeLog: * linux-low.c (struct thread_resume_array): Remove. (linux_set_resume_request): Return void, take arguments directly. (linux_resume): Use for_each_thread.
-
Simon Marchi authored
Simply replace with find_thread. gdb/gdbserver/ChangeLog: * linux-low.c (stuck_in_jump_pad_callback): Change prototype, return bool, remove data argument. (linux_stabilize_threads): Use find_thread.
-
Simon Marchi authored
Replace with for_each_thread. I inlined unsuspend_one_lwp in unsuspend_all_lwps, since it is very simple. gdb/gdbserver/ChangeLog: * linux-low.c (unsuspend_one_lwp): Remove. (unsuspend_all_lwps): Use for_each_thread, inline code from unsuspend_one_lwp.
-
Simon Marchi authored
Replace find_inferior with find_thread. Since it may be useful in the future, I added another overload to find_thread which filters based on a ptid (using ptid_t::matches), so now iterate_over_lwps doesn't have to do the filtering itself. iterate_over_lwps_filter is removed and inlined into iterate_over_lwps. gdb/gdbserver/ChangeLog: * gdbthread.h (find_thread): Add overload with ptid_t filter. * linux-low.c (struct iterate_over_lwps_args): Remove. (iterate_over_lwps_filter): Remove. (iterate_over_lwps): Use find_thread.
-
Simon Marchi authored
Replace with for_each_thread, and inline code from reset_lwp_ptrace_options_callback. gdb/gdbserver/ChangeLog: * linux-low.c (reset_lwp_ptrace_options_callback): Remove. (linux_handle_new_gdb_connection): Use for_each_thread, inline code from reset_lwp_ptrace_options_callback.
-
Simon Marchi authored
Replace two usages with the overload of for_each_thread that filters on pid. It allows to simplify the callback a little bit. gdb/gdbserver/ChangeLog: * linux-arm-low.c (struct update_registers_data): Remove. (update_registers_callback): Return void, take arguments directly, don't check thread's pid. (arm_insert_point, arm_remove_point): Use for_each_thread.
-
Simon Marchi authored
Replace with for_each_thread. gdb/gdbserver/ChangeLog: * win32-low.c (continue_one_thread): Return void, take argument directly. (child_continue): Use for_each_thread.
-
Simon Marchi authored
Straightforward replacement of find_inferior with the overload of for_each_thread that filters on pid. I am able to build-test this patch, but not run it. gdb/gdbserver/ChangeLog: * win32-i386-low.c (update_debug_registers_callback): Rename to ... (update_debug_registers): ... this, return void, remove pid_p arg. (x86_dr_low_set_addr, x86_dr_low_set_control): Use for_each_thread.
-
Cary Coutant authored
-