aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2014-02-26introduce minimal_symbol_upper_boundTom Tromey5-51/+83
This introduces minimal_symbol_upper_bound and changes various bits of code to use it. Since this function is intimately tied to the implementation of minimal symbol tables, I believe it belongs in minsyms.c. The new function is extracted from find_pc_partial_function_gnu_ifunc. This isn't a "clean" move because the old function interleaved the caching and the computation; but this doesn't make sense for the new code. 2014-02-26 Tom Tromey <tromey@redhat.com> * blockframe.c (find_pc_partial_function_gnu_ifunc): Use bound minimal symbols. Move code that knows about minsym table layout... * minsyms.c (minimal_symbol_upper_bound): ... here. New function. * minsyms.h (minimal_symbol_upper_bound): Declare. * objc-lang.c (find_objc_msgsend): Use bound minimal symbols, minimal_symbol_upper_bound.
2014-02-26[Python] Make regexp collection printers work with typedefs as well.Joel Brobecker6-0/+121
Consider the following type for which we would like to provide a pretty-printer and manage it via RegexpCollectionPrettyPrinter: typedef long time_t; Currently, this does not work because this framework only considers the type's tag name: typename = gdb.types.get_basic_type(val.type).tag if not typename: return None This patch extends it to use the type's name if the basic type does not have a tag name, thus allowing the framework to also work with typedefs like the above. gdb/ChangeLog: * python/lib/gdb/printing.py (RegexpCollectionPrettyPrinter): Use the type's name if its basic type does not have a tag. gdb/testsuite/ChangeLog: * testsuite/gdb.python/py-pp-re-notag.c: New file. * testsuite/gdb.python/py-pp-re-notag.ex: New file. * testsuite/gdb.python/py-pp-re-notag.p: New file.
2014-02-26Add comment in dwarf2read.c::read_subrange_typeJoel Brobecker2-0/+11
This comment explains why we sometimes sign-extend the range type bounds when we normally shouldn't have to. gdb/ChangeLog: * dwarf2read.c (read_subrange_type): Add comment.
2014-02-26DWARF: Set enum type "flag_enum" and "unsigned" flags at type creation.Joel Brobecker5-16/+197
Consider the following Ada code: -- An array whose index is an enumeration type with 128 enumerators. type Enum_T is (Enum_000, Enum_001, [...], Enum_128); type Table is array (Enum_T) of Boolean; When the compiler is configured to generate pure DWARF debugging info, trying to print type Table's description yields: ptype pck.table type = array (enum_000 .. -128) of boolean The expected output was: ptype pck.table type = array (enum_000 .. enum_128) of boolean The DWARF debugging info for our array looks like this: <1><44>: Abbrev Number: 5 (DW_TAG_array_type) <45> DW_AT_name : pck__table <50> DW_AT_type : <0x28> <2><54>: Abbrev Number: 6 (DW_TAG_subrange_type) <55> DW_AT_type : <0x5c> <59> DW_AT_lower_bound : 0 <5a> DW_AT_upper_bound : 128 The array index type is, by construction with the DWARF standard, a subrange of our enumeration type, defined as follow: <2><5b>: Abbrev Number: 0 <1><5c>: Abbrev Number: 7 (DW_TAG_enumeration_type) <5d> DW_AT_name : pck__enum_t <69> DW_AT_byte_size : 1 <2><6b>: Abbrev Number: 8 (DW_TAG_enumerator) <6c> DW_AT_name : pck__enum_000 <7a> DW_AT_const_value : 0 [etc] Therefore, while processing these DIEs, the array index type ends up being a TYPE_CODE_RANGE whose target type is our enumeration type. But the problem is that we read the upper bound as a negative value (-128), which is then used as is by the type printer to print the array upper bound. This negative value explains the "-128" in the output. To understand why the range type's upper bound is read as a negative value, one needs to look at how it is determined, in read_subrange_type: orig_base_type = die_type (die, cu); base_type = check_typedef (orig_base_type); [... high is first correctly read as 128, but then ...] if (!TYPE_UNSIGNED (base_type) && (high & negative_mask)) high |= negative_mask; The negative_mask is applied, here, because BASE_TYPE->FLAG_UNSIGNED is not set. And the reason for that is because the base_type was only partially constructed during the call to die_type. While the enum is constructed on the fly by read_enumeration_type, its flag_unsigned flag is only set later on, while creating the symbols corresponding to the enum type's enumerators (see process_enumeration_scope), after we've already finished creating our range type - and therefore too late. My first naive attempt at fixing this problem consisted in extracting the part in process_enumeration_scope which processes all enumerators, to generate the associated symbols, but more importantly set the type's various flags when necessary. However, this does not always work well, because we're still in the subrange_type's scope, and it might be different from the scope where the enumeration type is defined. So, instead, what this patch does to fix the issue is to extract from process_enumeration_scope the part that determines whether the enumeration type should have the flag_unsigned and/or the flag_flag_enum flags set. It turns out that, aside from the code implementing the loop, this part is fairly independent of the symbol creation. With that part extracted, we can then use it at the end of our enumeration type creation, to produce a type which should now no longer need any adjustment. Once the enumeration type produced is correctly marked as unsigned, the subrange type's upper bound is then correctly read as an unsigned value, therefore giving us an upper bound of 128 instead of -128. gdb/ChangeLog: * dwarf2read.c (update_enumeration_type_from_children): New function, mostly extracted from process_structure_scope. (read_enumeration_type): Call update_enumeration_type_from_children. (process_enumeration_scope): Do not set THIS_TYPE's flag_unsigned and flag_flag_enum fields. gdb/testsuite/ChangeLog: * gdb.dwarf2/arr-subrange.c, gdb.dwarf2/arr-subrange.exp: New files.
2014-02-26Mention PR breakpoints/16292 in corresponding ChangeLog entry.Pedro Alves1-0/+1
2014-02-26bsd-uthread.c: Don't install a to_xfer_partial methodPedro Alves2-16/+6
Whatever the comment about deprecated_xfer_memory referred to, deprecated_xfer_memory is gone now. There's no need to install a target method that just delegates, as that's what the default delegator does already. Tested by building an --enable-targets=all gdb on x86_64 Fedora 17. gdb/ 2014-02-26 Pedro Alves <palves@redhat.com> * bsd-uthread.c (bsd_uthread_xfer_partial): Delete function. (bsd_uthread_target): Don't install bsd_uthread_xfer_partial as to_xfer_partial method.
2014-02-26eliminate target_ops->deprecated_xfer_memoryPedro Alves3-148/+12
As no target uses it anymore, it can finally go away. After removing the deprecated_xfer_memory handling from default_xfer_partial, we can delete the latter, because the only thing it does is delegate to the target beneath unconditionally, which is what the delegator installed by target-delegates.c will do for us if no to_xfer_partial method is installed. This was the last user of de_fault, so that goes away too. Tested on x86_64 Fedora 17. gdb/ 2014-02-26 Pedro Alves <palves@redhat.com> * target.c (complete_target_initialization): Don't install default_xfer_partial as to_xfer_partial hook. (nomemory): Delete. (update_current_target): Don't INHERIT nor de_fault deprecated_xfer_memory. Delete de_fault macro. (default_xfer_partial, deprecated_debug_xfer_memory): Delete. (setup_target_debug): Don't install a deprecated_xfer_memory hook. * target.h (struct target_ops) <deprecated_xfer_memory>: Delete field.
2014-02-26go32-nat.c: Don't install a deprecated_xfer_memory methodPedro Alves2-20/+63
This removes yet another instance of a deprecated_xfer_memory user. Unfortunately djgpp's write_child function takes a non-const buffer pointer, while GDB's xfer_partial api passes a const pointer. To be const-correct, we need to copy that buffer to a non-const buffer, and pass the copy to write_child. This is actually what target.c:default_xfer_partial itself does, when calling into the ops->deprecated_xfer_memory hook. Tested by cross-building djgpp gdb, on x86-64 Fedora 17. gdb/ 2014-02-26 Pedro Alves <palves@redhat.com> * go32-nat.c (my_write_child): New function. (go32_xfer_memory): Rewrite as to_xfer_partial helper. (go32_xfer_partial): New function. (init_go32_ops): Don't install a deprecated_xfer_memory hook. Instead install a to_xfer_partial hook.
2014-02-26nto-procfs.c: Don't install a deprecated_xfer_memory methodPedro Alves2-24/+42
This removes yet another instance of a deprecated_xfer_memory user. Completely untested. gdb/ 2014-02-26 Pedro Alves <palves@redhat.com> * nto-procfs.c (procfs_xfer_memory): Adjust interface as a to_xfer_partial helper. Rewrite. (procfs_xfer_partial): New function. (init_procfs_ops): Don't install a deprecated_xfer_memory hook. Install a to_xfer_partial hook.
2014-02-26remote-m32r-sdi.c: Don't install a deprecated_xfer_memory methodPedro Alves2-18/+50
This removes yet another instance of a deprecated_xfer_memory user. Tested by building a --enable-targets=all gdb, on x86-64 Fedora 17. gdb/ 2014-02-26 Pedro Alves <palves@redhat.com> * remote-m32r-sdi.c (send_data): Constify 'buf' parameter. (m32r_xfer_memory): Adjust as a to_xfer_partial helper. (m32r_xfer_partial): New function. (init_m32r_ops): Don't install a deprecated_xfer_memory hook. Install a to_xfer_partial hook.
2014-02-26remote-mips.c: Don't install a deprecated_xfer_memory methodPedro Alves2-24/+49
This removes another yet instance of a deprecated_xfer_memory user. Tested by building a --enable-targets=all gdb, on x86-64 Fedora 17. gdb/ 2014-02-26 Pedro Alves <palves@redhat.com> * remote-mips.c (mips_xfer_memory): Adjust as to_xfer_partial helper. (mips_xfer_partial): New function. (_initialize_remote_mips): Don't install a deprecated_xfer_memory hook. Install a to_xfer_partial hook.
2014-02-26DWARF: Add array DW_AT_bit_stride and DW_AT_byte_stride supportJoel Brobecker7-6/+187
Consider the following declarations in Ada... type Item is range -32 .. 31; for Item'Size use 6; type Table is array (Natural range 0 .. 4) of Item; pragma Pack (Table); ... which declare a packed array whose elements are 6 bits long. The debugger currently does not notice that the array is packed, and thus prints values of this type incorrectly. This can be seen in the "ptype" output: (gdb) ptype table type = array (0 .. 4) of foo.item Normally, the debugger should print: (gdb) ptype table type = array (0 .. 4) of foo.item <packed: 6-bit elements> The debugging information for this array looks like this: .uleb128 0xf # (DIE (0x15c) DW_TAG_array_type) .long .LASF9 # DW_AT_name: "pck__table" .byte 0x6 # DW_AT_bit_stride .long 0x1a9 # DW_AT_type .uleb128 0x10 # (DIE (0x16a) DW_TAG_subrange_type) .long 0x3b # DW_AT_type .byte 0 # DW_AT_lower_bound .byte 0x4 # DW_AT_upper_bound .byte 0 # end of children of DIE 0x15c The interesting part is the DW_AT_bit_stride attribute, which tells the size of the array elements is 6 bits, rather than the normal element type's size. This patch adds support for this attribute by first creating gdbtypes.c::create_array_type_with_stride, which is an enhanced version of create_array_type taking an extra parameter as the stride. The old create_array_type can then be re-implemented very simply by calling the new create_array_type_with_stride. We can then use this new function from dwarf2read, to create arrays with or without stride. gdb/ChangeLog: * gdbtypes.h (create_array_type_with_stride): Add declaration. * gdbtypes.c (create_array_type_with_stride): New function, renaming create_array_type, but with an added parameter called "bit_stride". (create_array_type): Re-implement using create_array_type_with_stride. * dwarf2read.c (read_array_type): Add support for DW_AT_byte_stride and DW_AT_bit_stride attributes. gdb/testsuite/ChangeLog: * gdb.dwarf2/arr-stride.c: New file. * gdb.dwarf2/arr-stride.exp: New file. The test, relying purely on generating an assembly file, only verifies the type description of our array. But I was also able to verify manually that the debugger print values of these types correctly as well (which was not the case prior to this patch).
2014-02-26Multiple Ada task-specific breakpoints at the same address.Pedro Alves4-8/+41
With the test changed as in the patch, against current mainline, we get: (gdb) PASS: gdb.ada/tasks.exp: info tasks before inserting breakpoint break break_me task 1 Breakpoint 2 at 0x4030b0: file /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb, line 27. (gdb) PASS: gdb.ada/tasks.exp: break break_me task 1 break break_me task 3 Note: breakpoint 2 also set at pc 0x4030b0. Breakpoint 3 at 0x4030b0: file /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb, line 27. (gdb) PASS: gdb.ada/tasks.exp: break break_me task 3 continue Continuing. [Switching to Thread 0x7ffff7dc7700 (LWP 27133)] Breakpoint 2, foo.break_me () at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb:27 27 null; (gdb) FAIL: gdb.ada/tasks.exp: continue to breakpoint info tasks ID TID P-ID Pri State Name 1 63b010 48 Waiting on RV with 3 main_task 2 63bd80 1 48 Accept or Select Term task_list(1) * 3 63f510 1 48 Accepting RV with 1 task_list(2) 4 642ca0 1 48 Accept or Select Term task_list(3) (gdb) PASS: gdb.ada/tasks.exp: info tasks after hitting breakpoint The breakpoint that caused a stop is breakpoint 3, but GDB end up reporting (and running breakpoint commands of) "Breakpoint 2" instead. The issue is that the bpstat_check_breakpoint_conditions logic of "wrong thread" is missing the "wrong task" check. This is usually harmless, because the thread hop code in infrun.c code that handles wrong-task-hitting-breakpoint does check for task-specific breakpoints (within breakpoint_thread_match): /* Check if a regular breakpoint has been hit before checking for a potential single step breakpoint. Otherwise, GDB will not see this breakpoint hit when stepping onto breakpoints. */ if (regular_breakpoint_inserted_here_p (aspace, stop_pc)) { if (!breakpoint_thread_match (aspace, stop_pc, ecs->ptid)) thread_hop_needed = 1; } IOW, usually, when one only has a task specific breakpoint at a given address, things work correctly. Put another task-specific or non-task-specific breakpoint there, and things break. A patch that eliminates the special thread hop code in infrun.c is what exposed this, as after that GDB solely relies on bpstat_check_breakpoint_conditions to know whether the right or wrong task hit a breakpoint. IOW, given the latent bug, Ada task-specific breakpoints become non-task-specific, and that is caught by the testsuite, as: break break_me task 3 Breakpoint 2 at 0x4030b0: file /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb, line 27. (gdb) PASS: gdb.ada/tasks.exp: break break_me task 3 continue Continuing. [Switching to Thread 0x7ffff7fcb700 (LWP 17122)] Breakpoint 2, foo.break_me () at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb:27 27 null; (gdb) PASS: gdb.ada/tasks.exp: continue to breakpoint info tasks ID TID P-ID Pri State Name 1 63b010 48 Waiting on RV with 2 main_task * 2 63bd80 1 48 Accepting RV with 1 task_list(1) 3 63f510 1 48 Accept or Select Term task_list(2) 4 642ca0 1 48 Accept or Select Term task_list(3) (gdb) FAIL: gdb.ada/tasks.exp: info tasks after hitting breakpoint It was after seeing this that I thought of how to expose the bug with current mainline. Tested on x86_64 Fedora 17. gdb/ 2014-02-26 Pedro Alves <palves@redhat.com> * breakpoint.c (bpstat_check_breakpoint_conditions): Handle task-specific breakpoints. gdb/testsuite/ 2014-02-26 Pedro Alves <palves@redhat.com> * gdb.ada/tasks.exp: Set a task-specific breakpoint at break_me that won't ever trigger. Make sure that GDB reports the correct breakpoint that caused the stop.
2014-02-26Resolve PR ld/16569 by emitting (and comparing) unmangled names, unlessDan Mick2-9/+31
demangling has specifically been requested.
2014-02-25Re-implement ia64-linux-nat.c::ia64_linux_xfer_partialPedro Alves2-12/+28
[description of this patch and ChangeLog entry by Joel Brobecker] The recent implementation was questionable, and if it worked, it was only by chance because the requested length is large enough that only one read was sufficient. Note that the implementation before that also made that assumption, in the form of only handling TARGET_OBJECT_UNWIND_TABLE xfer requests when offset was zero. gdb/ChangeLog: * ia64-linux-nat.c (ia64_linux_xfer_partial): Reimplement handling of object == TARGET_OBJECT_UNWIND_TABLE.
2014-02-25Annotate comments for Doxygen.Stan Shebs2-64/+72
2014-02-26daily updateAlan Modra1-1/+1
2014-02-25PR gdb/16626Jan Kratochvil2-2/+5
gdb/testsuite/ 2014-02-25 Jan Kratochvil <jan.kratochvil@redhat.com> PR gdb/16626 * gdb.base/auto-load.exp: Fix out-of-srctree run. Message-ID: <87k3cjt3jl.fsf@fleche.redhat.com>
2014-02-25remove target_ignoreTom Tromey3-10/+5
This removes target_ignore, which isn't used any more. 2014-02-25 Tom Tromey <tromey@redhat.com> * target.h (target_ignore): Don't declare. * target.c (target_ignore): Remove.
2014-02-25PR gdb/16626Jan Kratochvil6-3/+96
Fix auto-load 7.7 regression, the regression affects any loading from /usr/share/gdb/auto-load . 5b2bf9471f1499bee578fcd60c05afe85794e280 is the first bad commit commit 5b2bf9471f1499bee578fcd60c05afe85794e280 Author: Doug Evans <xdje42@gmail.com> Date: Fri Nov 29 21:29:26 2013 -0800 Move .debug_gdb_script processing to auto-load.c. Simplify handling of auto-loaded objfile scripts. Fedora 20 x86_64 $ gdb -q /usr/lib64/libgobject-2.0.so Reading symbols from /usr/lib64/libglib-2.0.so.0.3800.2...Reading symbols from /usr/lib/debug/usr/lib64/libglib-2.0.so.0.3800.2.debug...done. done. (gdb) _ Fedora Rawhide x86_64 $ gdb -q /usr/lib64/libgobject-2.0.so Reading symbols from /usr/lib64/libglib-2.0.so...Reading symbols from /usr/lib/debug/usr/lib64/libglib-2.0.so.0.3990.0.debug...done. done. warning: File "/usr/lib64/libglib-2.0.so.0.3990.0-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load:/usr/bin/mono-gdb.py". To enable execution of this file add add-auto-load-safe-path /usr/lib64/libglib-2.0.so.0.3990.0-gdb.py line to your configuration file "/home/jkratoch/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/jkratoch/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" (gdb) _ That is it tries to load "forbidden" /usr/lib64/libglib-2.0.so.0.3990.0-gdb.py but it should load instead /usr/share/gdb/auto-load/usr/lib64/libglib-2.0.so.0.3990.0-gdb.py* Although that is also not exactly this way, there does not exist any /usr/lib64/libglib-2.0.so.0.3990.0-gdb.py despite regressed GDB says so. gdb/ 2014-02-24 Jan Kratochvil <jan.kratochvil@redhat.com> PR gdb/16626 * auto-load.c (auto_load_objfile_script_1): Change filename to debugfile. gdb/testsuite/ 2014-02-24 Jan Kratochvil <jan.kratochvil@redhat.com> PR gdb/16626 * gdb.base/auto-load-script: New file. * gdb.base/auto-load.c: New file. * gdb.base/auto-load.exp: New file. Message-ID: <20140223212400.GA8831@host2.jankratochvil.net>
2014-02-25Fix dw2-icycle.exp -fsanitize=address GDB crash.Jan Kratochvil2-10/+5
binutils readelf -wi: <4><a2>: Abbrev Number: 26 (DW_TAG_inlined_subroutine) <a3> DW_AT_abstract_origin: <0x5a> <a7> DW_AT_low_pc : 0x400590 <ab> DW_AT_high_pc : 0x4 <af> DW_AT_call_file : 1 <b0> DW_AT_call_line : 20 <b1> DW_AT_sibling : <0xb8> <2><b8>: Abbrev Number: 35 (DW_TAG_inlined_subroutine) <b9> DW_AT_abstract_origin: <0x5a> <bd> DW_AT_low_pc : 0x400590 <c1> DW_AT_high_pc : 0x4 <c5> DW_AT_call_file : 1 <c6> DW_AT_call_line : 29 <b1> DW_AT_sibling points to the next DIE - but that DIE is 2 levels upwards - definitely not a sibling. This confuses GDB up to a crash: ==32143== ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6024000198ac at pc 0xb4d104 bp 0x7fff63e96e70 sp 0x7fff63e96e60 READ of size 1 at 0x6024000198ac thread T0 #0 0xb4d103 in read_unsigned_leb128 (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0xb4d103) #1 0xb15f3c in peek_die_abbrev (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0xb15f3c) #2 0xb46185 in load_partial_dies (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0xb46185) #3 0xb103fb in process_psymtab_comp_unit_reader (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0xb103fb) #4 0xb0d2a9 in init_cutu_and_read_dies (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0xb0d2a9) #5 0xb1115f in process_psymtab_comp_unit (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0xb1115f) #6 0xb1235f in dwarf2_build_psymtabs_hard (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0xb1235f) #7 0xb05536 in dwarf2_build_psymtabs (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0xb05536) #8 0x86d5a5 in read_psyms (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0x86d5a5) #9 0x9b1c37 in require_partial_symbols (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0x9b1c37) #10 0x9bf2d0 in read_symbols (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0x9bf2d0) #11 0x9c014c in syms_from_objfile_1 (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0x9c014c) gdb/testsuite/ 2014-02-25 Jan Kratochvil <jan.kratochvil@redhat.com> Fix dw2-icycle.exp -fsanitize=address GDB crash. * gdb.dwarf2/dw2-icycle.S: Remove all DW_AT_sibling. Message-ID: <20140224201011.GA28926@host2.jankratochvil.net>
2014-02-25Remove bogus vcvtps2ph variant.Ilya Tocar3-20/+6
We currently support version of vcvtps2ph with sae and only 1 register operand. This version is encoded as if missing operand was equal to ymm0. I didn't found any references to this variant in http://download-software.intel.com/sites/default/files/managed/50/1a/319433-018.pdf This patch removes it. opcodes/ * i386-opc.tbl: Remove wrong variant of vcvtps2ph * i386-tbl.h: Regenerate.
2014-02-25Adjust ia64_linux_xfer_partial following to_xfer_partial API change.Joel Brobecker2-5/+29
ia64-linux-nat.c no longer compiles because ia64_linux_xfer_partial no longer matches the to_xfer_partial prototype. This patch fixes the problem by adjusting it accordingly. gdb/ChangeLog: * ia64-linux-nat.c (ia64_linux_xfer_partial): Add function documentation. Adjust prototype to match the target_ops to_xfer_partial method. Adjust implementation accordingly.
2014-02-25Fix a format issue of ChangeLog.Hui Zhu1-1/+1
2014-02-252014-02-25 Hui Zhu <hui@codesourcery.com>Hui Zhu2-1/+6
* target.h (target_ops): Fix TARGET_DEFAULT_RETURN of to_traceframe_info.
2014-02-25Use 16-bit integer type for rl78 register pairs.Kevin Buettner2-6/+82
This patch changes rl78-tdep.c so that a 16-bit type is used for register pairs instead of a pointer type as was previously the case. This will cause these register pairs to be displayed as integers instead of as a data address with a 0xf0000 ORed in. E.g. registers ax, bc, de, and hl might now be displayed like this: (gdb) info registers ax bc de hl ax 0x6 6 bc 0x0 0 de 0x10c3 4291 hl 0x108d 423 Whereas, before, they were displayed as follows: (gdb) info registers ax bc de hl ax 0xf0006 0xf0006 bc 0xf0000 0xf0000 de 0xf10c3 0xf10c3 hl 0xf108d 0xf108d These pairs are 16 bit quantities and should be displayed as such. This change also affects the way that the banked register pairs are displayed. Within GDB, the banked register pairs are named bank0_rp0, bank0_rp1, .., bank3_rp2, bank3_rp3. However, these register pairs need to be used as addresses in DWARF expressions. I have added 16 pseudo registers corresponding to banked register pairs. These new pseudo registers are all hidden from the user and have a pointer type. Values from these registers are intended to be used in DWARF expressions. Therefore, rl78_dwarf_reg_to_regnum() has been adjusted to return these new pseudo register numbers. I had a much simpler patch which only changed the types, but it showed a number of regressions due to integer values from the banked register pairs being used as part of an address expression. This current patch shows no regressions and now displays values of register pairs correctly. * rl78-tdep.c ( RL78_BANK0_RP0_PTR_REGNUM, RL78_BANK0_RP1_PTR_REGNUM) (RL78_BANK0_RP2_PTR_REGNUM, RL78_BANK0_RP3_PTR_REGNUM) (RL78_BANK1_RP0_PTR_REGNUM, RL78_BANK1_RP1_PTR_REGNUM) (RL78_BANK1_RP2_PTR_REGNUM, RL78_BANK1_RP3_PTR_REGNUM) (RL78_BANK2_RP0_PTR_REGNUM, RL78_BANK2_RP1_PTR_REGNUM) (RL78_BANK2_RP2_PTR_REGNUM, RL78_BANK2_RP3_PTR_REGNUM) (RL78_BANK3_RP0_PTR_REGNUM, RL78_BANK3_RP1_PTR_REGNUM) (RL78_BANK3_RP2_PTR_REGNUM, RL78_BANK3_RP3_PTR_REGNUM): New constants. (rl78_register_type): Use a data pointer type for SP and new pseudo registers mentioned above. Use a 16 bit integer type for all other register pairs. (rl78_register_name, rl78_g10_register_name): Update for new pseudo registers. (rl78_pseudo_register_read): Likewise. (rl78_pseudo_register_write): Likewise. (rl78_dwarf_reg_to_regnum): Return register numbers representing to the newly added pseudo registers.
2014-02-25daily updateAlan Modra1-1/+1
2014-02-24 * value.c (record_latest_value): Fix comment.Doug Evans3-15/+11
* printcmd.c (print_command_1): Remove code to handle -1 return from record_latest_value.
2014-02-24lib/gdb.exp (run_on_host): Log error output if program fails.Doug Evans2-0/+5
2014-02-24procfs.c: Don't install a deprecated_xfer_memory methodPedro Alves2-46/+36
This removes yet another instance of a deprecated_xfer_memory user, and fixes a nasty regression as a side-effect: (gdb) start Temporary breakpoint 1 at 0x19070: file simple_main.adb, line 4. Starting program: /[...]/simple_main Warning: Cannot insert breakpoint 1. Cannot access memory at address 0x19070 Cannot insert breakpoint -3. Temporarily disabling shared library breakpoints: breakpoint #-3 The regression was introduced by the to_xfer_partial transition to return a status enum. procfs_xfer_partial was updated but not the case where object is TARGET_OBJECT_MEMORY. As result, procfs_xfer_partial was returning the length xfered rather than the status, and the xfered buffer was left uninitialized. gdb/ 2014-02-19 Pedro Alves <palves@redhat.com> * procfs.c (procfs_target): Don't install procfs_xfer_memory as deprecated_xfer_memory hook. (procfs_xfer_partial): Call procfs_xfer_memory instead of the deprecated_xfer_memory target hook. (procfs_xfer_memory): Adjust interface as a to_xfer_partial helper.
2014-02-24Fix a GDB assert failure on windowsYuanhui Zhang2-1/+7
A GDB internal error is found on native mingw32 target. (gdb) run ../../binutils-gdb/gdb/target.c:1483: internal-error: target_xfer_partial: Assertion `*xfered_len > 0' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) This error was introduced by the following snippet in commit 9b409511d07fe375284701af34909fb539029caf > @@ -2536,27 +2538,30 @@ windows_xfer_shared_libraries (struct target_ops *ops, > } > > obstack_free (&obstack, NULL); > - return len; > + *xfered_len = (ULONGEST) len; > + return TARGET_XFER_OK; > } In the original code, len is returned, which could be 0, but after that commit, only TARGET_XFER_OK is returned, which is wrong. If len is 0, TARGET_XFER_EOF should be returned. (it is 0 in enum target_xfer_status declaration). gdb: 2014-02-24 Yuanhui Zhang <asmwarrior@gmail.com> * windows-nat.c (windows_xfer_shared_libraries): Return TARGET_XFER_EOF if LEN is zero to fix an assert failure when requested object is TARGET_OBJECT_LIBRARIES.
2014-02-24Rename TARGET_XFER_E_UNAVAILABLE to TARGET_XFER_UNAVAILABLEYao Qi8-18/+32
Nowadays, TARGET_XFER_E_UNAVAILABLE isn't regarded as an error in to_xfer_partial interface, so _E_ looks odd. This patch is to replace TARGET_XFER_E_UNAVAILABLE with TARGET_XFER_UNAVAILABLE, and change its value from -2 to 2. Since there is no comparison on the value of 'enum target_xfer_status', so it should be safe. gdb: 2014-02-24 Yao Qi <yao@codesourcery.com> * target.h (enum target_xfer_status) <TARGET_XFER_E_UNAVAILABLE>: Rename it to ... <TARGET_XFER_UNAVAILABLE>: ... it with setting value 2 explicitly. New. * corefile.c (memory_error_message): User updated. * exec.c (section_table_read_available_memory): Likewise. * record-btrace.c (record_btrace_xfer_partial): Likewise. * target.c (target_xfer_status_to_string): Likewise. (raw_memory_xfer_partial): Likewise. (memory_xfer_partial_1, target_xfer_partial): Likewise. * valops.c (read_value_memory): Likewise. * exec.h: Update comments.
2014-02-24Tweak target_xfer_status_to_stringYao Qi3-5/+14
This patch tweaks target_xfer_status_to_string on comments and argument name. gdb: 2014-02-24 Yao Qi <yao@codesourcery.com> * target.c (target_xfer_status_to_string): Rename argument err to status. * target.h (target_xfer_status_to_string): Update declaration. Replace target_xfer_error_to_string with target_xfer_status_to_string in comment.
2014-02-24Unbreak mips native buildYao Qi2-2/+7
When I build mips native gdb today, I get the follow error, ../../../git/gdb/mips-linux-nat.c: In function '_initialize_mips_linux_nat': ../../../git/gdb/mips-linux-nat.c:792:15: error: assignment from incompatible pointer type [-Werror] cc1: all warnings being treated as errors It looks an oversight of recent target_ops delegation patches. This patch is to fix the build error. gdb: 2014-02-24 Yao Qi <yao@codesourcery.com> * mips-linux-nat.c (super_close): Update its type. (mips_linux_close): Pass 'self' to super_close.
2014-02-24Remove TARGET_XFER_STATUS_ERROR_PYao Qi4-13/+11
This patch removes macro TARGET_XFER_STATUS_ERROR_P, as Pedro pointed out during patches review that TARGET_XFER_STATUS_ERROR_P tends to be unnecessary. gdb: 2014-02-24 Yao Qi <yao@codesourcery.com> * target.h (TARGET_XFER_STATUS_ERROR_P): Remove. * corefile.c (read_memory): Adjusted. * target.c (target_write_with_progress): Adjusted.
2014-02-24daily updateAlan Modra1-1/+1
2014-02-23Revert previous tweaksYao Qi3-18/+20
As we migrate to the new to_xfer_partial interface, some of previous tweaks become unnecessary, we don't have to check traceframe is selected in each target implementation, so this patch below is reverted. [PATCH] Send qXfer:traceframe-info:read when traceframe is selected. https://sourceware.org/ml/gdb-patches/2013-10/msg00752.html Third, to_traceframe_info is only called when traceframe is selected, that means it is only called when target is remote, tfile or ctf, so this patch can be partially reverted, https://sourceware.org/ml/gdb-patches/2013-04/msg00000.html gdb: 2014-02-23 Yao Qi <yao@codesourcery.com> Revert two patches: 2013-10-25 Yao Qi <yao@codesourcery.com> * remote.c (remote_traceframe_info): Return early if traceframe is not selected. 2013-07-19 Yao Qi <yao@codesourcery.com> * target.c (update_current_target): Change the default action of 'to_traceframe_info' from tcomplain to return_zero. * target.h (struct target_ops) <to_traceframe_info>: Add more comments.
2014-02-23Adjust read_value_memory to use to_xfer_partialYao Qi4-85/+38
As the new to_xfer_partial implementations are done in ctf and tfile targets, read_value_memory can be simplified a lot. Call target_xfer_partial in a loop, check return value, and set bytes unavailable when necessary. gdb: 2014-02-23 Yao Qi <yao@codesourcery.com> * valops.c (read_value_memory): Rewrite it. Call target_xfer_partial in a loop. * exec.h (section_table_available_memory): Remove declaration. Move comments to ... * exec.c (section_table_available_memory): ... here. Make it static.
2014-02-23Use new to_xfer_partial interface in ctf and tfile targetYao Qi5-4/+85
This patch adjust both ctf and tfile target implementation of to_xfer_partial, to return TARGET_XFER_E_UNAVAILABLE and set *XFERED_LEN if data is unavailable. Note that some code on xfer in exec.c can be shared, but we can do it in a separate pass later. gdb: 2014-02-23 Yao Qi <yao@codesourcery.com> * exec.c (section_table_read_available_memory): New function. * exec.h (section_table_read_available_memory): Declare. * ctf.c (ctf_xfer_partial): Call section_table_read_available_memory. * tracefile-tfile.c (tfile_xfer_partial): Likewise.
2014-02-23Share code on to_xfer_partial for tfile and ctf targetYao Qi6-76/+67
In the to_xfer_partial implementations of ctf and tfile, the code on reading from read-only sections is duplicated. This patch moves it to a separate function exec_read_partial_read_only. gdb: 2014-02-23 Yao Qi <yao@codesourcery.com> * ctf.c (ctf_xfer_partial): Move code to ... * exec.c (exec_read_partial_read_only): ... it. New function. * tracefile-tfile.c (tfile_xfer_partial): Likewise. * tracefile.c: Include "exec.h". * exec.h (exec_read_partial_read_only): Declare.
2014-02-23Let tracefile has_memory and has_all_memory.Yao Qi3-14/+29
At present, tfile target thinks it has memory but ctf doesn't. This is an oversight when I added ctf target support. This patch moves the implementations of to_has_all_memory and to_has_memory to upper layer. After this change, both tfile and ctf target think they have memory. gdb: 2014-02-23 Yao Qi <yao@codesourcery.com> * tracefile-tfile.c (tfile_has_all_memory): Remove. (tfile_has_memory): Remove. (init_tfile_ops): Don't set fields to_has_all_memory and to_has_memory of tfile_ops. * tracefile.c (tracefile_has_all_memory): New function. (tracefile_has_memory): New function. (init_tracefile_ops): Initialize fields to_has_all_memory and to_has_memory of 'ops'.
2014-02-23Share some code between ctf and tfile target.Yao Qi5-82/+77
This patch move the duplicated code between tfile and ctf targets into file tracefile.c. The common part of target_ops fields are set in init_tracefile_ops. gdb: 2014-02-23 Yao Qi <yao@codesourcery.com> * ctf.c (ctf_has_stack, ctf_has_registers): Remove. (ctf_thread_alive, ctf_get_trace_status): Remove. (init_ctf_ops): Don't set some fields of ctf_ops. Call init_tracefile_ops. * tracefile-tfile.c (tfile_get_trace_status): Remove. (tfile_has_stack, tfile_has_registers): Remove. (tfile_thread_alive): Remove. (init_tfile_ops): Don't set some fields of tfile_ops. Call init_tracefile_ops. * tracefile.c (tracefile_has_stack): New function. (tracefile_has_registers): New function. (tracefile_thread_alive): New function. (tracefile_get_trace_status): New function. (init_tracefile_ops): New function. * tracefile.h (init_tracefile_ops): Declare.
2014-02-23Move tfile target to tracefile-tfile.cYao Qi3-815/+854
This patch moves tfile target related code from tracepoint.c to tracefile-tfile.c. gdb: 2014-02-23 Yao Qi <yao@codesourcery.com> * tracepoint.c (TFILE_PID): Move it to tracefile-tfile.c. (O_LARGEFILE): Likewise. (tfile_ops): Likewise. (TRACE_HEADER_SIZE): Likewise. (trace_fd, trace_frames_offset, cur_offset): Likewise. (cur_data_size): Likewise. (tfile_read, tfile_open, tfile_interp_line): Likewise. (tfile_close, tfile_files_info): Likewise. (tfile_get_trace_status): Likewise. (tfile_get_tracepoint_status): Likewise. (tfile_get_traceframe_address): Likewise. (tfile_trace_find, match_blocktype): Likewise. (traceframe_walk_blocks, traceframe_find_block_type): Likewise. (tfile_fetch_registers, tfile_xfer_partial): Likewise. (tfile_get_trace_state_variable_value): Likewise. (tfile_has_all_memory, tfile_has_memory): Likewise. (tfile_has_stack, tfile_has_registers): Likewise. (tfile_thread_alive, build_traceframe_info): Likewise. (tfile_traceframe_info, init_tfile_ops): Likewise. (_initialize_tracepoint): Don't call init_tfile_ops and add_target_with_completer. * tracefile-tfile.c: Include regcache.h, inferior.h, gdbthread.h, exec.h, completer.h and filenames.h. (_initialize_tracefile_tfile): New function.
2014-02-23Move trace file writer out of tracepoint.cYao Qi8-777/+874
This patch is a refactor which moves trace file writer related code out of tracepoint.c, which has 6k LOC. It moves general trace file writer to a new file tracefile.c and moves tfile specific writer to tracefile-tfile.c. gdb: 2014-02-23 Yao Qi <yao@codesourcery.com> * Makefile.in (REMOTE_OBS): Append tracefile.o and tracefile-tfile.o. (HFILES_NO_SRCDIR): Add tracefile.h. * ctf.c: Include "tracefile.h". * tracefile.h: New file. * tracefile.c: New file * tracefile-tfile.c: New file. * tracepoint.c: Include "tracefile.h". (free_uploaded_tps, free_uploaded_tsvs): Remove declarations. (stop_reason_names): Add const. (trace_file_writer_xfree): Move it to tracefile.c. (trace_save, trace_save_command, trace_save_tfile): Likewise. (trace_save_ctf): Likewise. (struct tfile_trace_file_writer): Move it to tracefile-tfile.c. (tfile_target_save, tfile_dtor, tfile_start): Likewise. (tfile_write_header, tfile_write_regblock_type): Likewise. (tfile_write_status, tfile_write_uploaded_tsv): Likewise. (tfile_write_uploaded_tp, tfile_write_definition_end): Likewise. (tfile_write_raw_data, tfile_end): Likewise. (tfile_trace_file_writer_new): Likewise. (free_uploaded_tp): Make it extern. (free_uploaded_tsv): Make it extern. (_initialize_tracepoint): Move code to register command 'tsave' to tracefile.c. * tracepoint.h (stop_reason_names): Declare. (struct trace_frame_write_ops): Move it to tracefile.h. (struct trace_file_write_ops): Likewise. (struct trace_file_writer): Likewise. (free_uploaded_tsvs, free_uploaded_tps): Declare.
2014-02-23daily updateAlan Modra1-1/+1
2014-02-22daily updateAlan Modra1-1/+1
2014-02-21Fix crash on process name "(sd-pam)" (PR 16594).Jan Kratochvil3-17/+27
info os processes -fsanitize=address error https://sourceware.org/bugzilla/show_bug.cgi?id=16594 info os processes ================================================================= ==5795== ERROR: AddressSanitizer: heap-use-after-free on address 0x600600214974 at pc 0x757a92 bp 0x7fff95dd9f00 sp 0x7fff95dd9ef0 READ of size 4 at 0x600600214974 thread T0 #0 0x757a91 in get_cores_used_by_process (.../gdb/gdb+0x757a91) At least Fedora 20 has process(es): 6678 ? Ss 0:00 /usr/lib/systemd/systemd --user 6680 ? S 0:00 \_ (sd-pam) and GDB "info os processes" crashes on it as /proc/6680/stat contains: 6680 ((sd-pam)) S 6678 6678 6678 0 -1 1077961024 33 0 0 0 0 0 0 0 20 0 1 0 18568 73768960 120 18446744073709551615 1 1 0 0 0 0 0 4096 0 18446744073709551615 0 0 17 6 0 0 0 0 0 0 0 0 0 0 0 0 0 and GDB fails to find the proper end of the process name "((sd-pam))". Therefore it reads core number off-by-one (it reads 17 instead of 6) and overruns the array. (1) Make the process name parsing more foolproof. (2) Do not trust the parsed number from /proc/PID/stat and verify it against the array size. I noticed that 'ps' gets this right, so I've peeked at its sources, and it just looks for the first ')' starting at the end. https://gitorious.org/procps/procps/source/dc072aced7250fed9b01fb05f0d672678752a63e:proc/readproc.c Look for stat2proc. Given ps does that, I believe the kernel won't ever be changed in a way that would break it. So it sounds like could do strrchr from the end of stat just as well without worry, which is simpler. gdb/ 2014-02-21 Jan Kratochvil <jan.kratochvil@redhat.com> PR gdb/16594 * common/linux-osdata.c (linux_common_core_of_thread): Find the end of process name. (get_cores_used_by_process): New parameter num_cores, use it. (linux_xfer_osdata_processes): Pass num_cores to it. * linux-tdep.c (linux_info_proc, linux_fill_prpsinfo): Find the end of process name. Message-ID: <20140217212826.GA15080@host2.jankratochvil.net>
2014-02-21Add support for CPUID PREFETCHWT1Ilya Tocar23-3882/+3995
Latest AVX512 spec http://download-software.intel.com/sites/default/files/managed/50/1a/319433-018.pdf Has CPUID PREFETCHWT1 for prefetchwt1 instruction, which we list as AVX512PF. This patch introduces CPUID PREFETCHWT1. gas/ * config/tc-i386.c (cpu_arch): Add .prefetchwt1. * doc/c-i386.texi: Document .prefetchwt1/prefetchwt1. opcodes/ * i386-gen.c (cpu_flag_init): Add CPU_PREFETCHWT1_FLAGS/ (cpu_flags): Add CpuPREFETCHWT1. * i386-init.h: Regenerate. * i386-opc.h (CpuPREFETCHWT1): New. (i386_cpu_flags): Add cpuprefetchwt1. * i386-opc.tbl: Cahnge CPU of prefetchwt1 from CpuAVX512PF to CpuPREFETCHWT1. * i386-tbl.h: Regenerate. gas/testsuite * gas/i386/avx512pf-intel.d: Remove prefetchwt1. * gas/i386/avx512pf.s: Ditto. * gas/i386/avx512pf.d: Ditto. * gas/i386/x86-64-avx512pf-intel.d: Ditto. * gas/i386/x86-64-avx512pf.s: Ditto. * gas/i386/x86-64-avx512pf.d: Ditto. * gas/i386/prefetchwt1-intel.d: New file. * gas/i386/prefetchwt1.s: Ditto. * gas/i386/prefetchwt1.d: Ditto. * gas/i386/x86-64-prefetchwt1-intel.d: Ditto. * gas/i386/x86-64-prefetchwt1.s: Ditto. * gas/i386/x86-64-prefetchwt1.d: Ditto.
2014-02-21Fix length arg in call to breakpoint_xfer_memory.Andreas Krebbel2-1/+6
The patch "return target_xfer_status in to_xfer_partial" caused a regression in various s390(x) test cases, because memory_xfer_partial filled only the first byte of the read buffer from a breakpoint shadow: https://sourceware.org/ml/gdb-patches/2014-01/msg01071.html This patch fixes the regression.
2014-02-21Rename test.Pedro Alves3-0/+8
I realized that the name of this test only made sense when considering the old (never committed) implementation of the fix that came along with the test originally, that forced a schedlock while a step-resume (to get over the signal handler) was inserted. The final solution that went into the tree does not force that locking. So this renames it to something more descriptive. gdb/testsuite/ 2014-02-21 Pedro Alves <palves@redhat.com> * gdb.threads/step-after-sr-lock.c: Rename to ... * gdb.threads/signal-while-stepping-over-bp-other-thread.c: ... this. * gdb.threads/step-after-sr-lock.exp: Rename to ... * gdb.threads/signal-while-stepping-over-bp-other-thread.exp: ... this.
generated by cgit v1.1 at 2024-12-16 17:58:34 +0000