This changes the probes to be independent of the program space.
After this, when a probe's address is needed, it is determined by
applying offsets at the point of use.
This introduces a bound_probe object, similar to bound minimal
symbols. Objects of this type are used when it's necessary to pass a
probe and its corresponding objfile.
This removes the backlink from probe to objfile, which was primarily
used to fetch the architecture to use.
This adds a get_probe_address function which calls a probe method to
compute the probe's relocated address. Similarly, it adds an objfile
parameter to the semaphore methods so they can do the relocation
properly as well.
2014-03-03 Tom Tromey <tromey@redhat.com>
* break-catch-throw.c (fetch_probe_arguments): Use bound probes.
* breakpoint.c (create_longjmp_master_breakpoint): Use
get_probe_address.
(add_location_to_breakpoint, bkpt_probe_insert_location)
(bkpt_probe_remove_location): Update.
* breakpoint.h (struct bp_location) <probe>: Now a bound_probe.
* elfread.c (elf_symfile_relocate_probe): Remove.
(elf_probe_fns): Update.
(insert_exception_resume_breakpoint): Change type of "probe"
parameter to bound_probe.
(check_exception_resume): Update.
* objfiles.c (objfile_relocate1): Don't relocate probes.
* probe.c (bound_probe_s): New typedef.
(parse_probes): Use get_probe_address. Set sal's objfile.
(find_probe_by_pc): Return a bound_probe.
(collect_probes): Return a VEC(bound_probe_s).
(compare_probes): Update.
(gen_ui_out_table_header_info): Change type of "probes"
parameter. Update.
(info_probes_for_ops): Update.
(get_probe_address): New function.
(probe_safe_evaluate_at_pc): Update.
* probe.h (struct probe_ops) <get_probe_address>: New field.
<set_semaphore, clear_semaphore>: Add objfile parameter.
(struct probe) <objfile>: Remove field.
<arch>: New field.
<address>: Update comment.
(struct bound_probe): New.
(find_probe_by_pc): Return a bound_probe.
(get_probe_address): Declare.
* solib-svr4.c (struct probe_and_action) <address>: New field.
(hash_probe_and_action, equal_probe_and_action): Update.
(register_solib_event_probe): Add address parameter.
(solib_event_probe_at): Update.
(svr4_create_probe_breakpoints): Add objfile parameter. Use
get_probe_address.
* stap-probe.c (struct stap_probe) <sem_addr>: Update comment.
(stap_get_probe_address): New function.
(stap_can_evaluate_probe_arguments, compute_probe_arg)
(compile_probe_arg): Update.
(stap_set_semaphore, stap_clear_semaphore): Compute semaphore's
address.
(handle_stap_probe): Don't relocate the probe.
(stap_relocate): Remove.
(stap_gen_info_probes_table_values): Update.
(stap_probe_ops): Remove stap_relocate.
* symfile-debug.c (debug_sym_relocate_probe): Remove.
(debug_sym_probe_fns): Update.
* symfile.h (struct sym_probe_fns) <sym_relocate_probe>: Remove.
* symtab.c (init_sal): Use memset.
* symtab.h (struct symtab_and_line) <objfile>: New field.
* tracepoint.c (start_tracing, stop_tracing): Update.
This fixes up a few mildly erroneous comments in probe.h.
2014-03-03 Tom Tromey <tromey@redhat.com>
* probe.h (parse_probes, find_probe_by_pc)
(find_probes_in_objfile): Fix comments.
OpenBSD 5.2 and later have a proper threads implementation based on
kernel threads. Debugging support is provided through additional
ptrace(2) requests, so this diff extends the generic code in
inf-ptrace.c with OpenBSD-specific code to discover additional threads.
gdb/ChangeLog:
* obsd-nat.h: New file.
* obsd-nat.c: New file.
* Makefile.in (HFILES_NO_SRCDIR): Add obsd-nat.h.
(ALLDEPFILES): Add obsd-nat.c.
This patch constifies ui_out_impl in struct ui_out, and various
instances of ui_out_impl.
This removes a couple of FIXME comments (near cli_ui_out_impl and
mi_ui_out_impl) that did not make sense to me.
Tested by rebuilding.
2014-02-28 Tom Tromey <tromey@redhat.com>
* cli-out.c (cli_ui_out_impl): Now const. Remove comment.
* cli-out.h (cli_ui_out_impl): Now const.
* mi/mi-out.c (mi_ui_out_impl): Now const. Remove comment.
* ui-out.c (struct ui_out) <impl>: Now const.
(default_ui_out_impl): Now const.
(ui_out_new): Make 'impl' parameter const.
* ui-out.h (ui_out_new): Update.
GCC 4.2.1 complains about first_l_name may be used uninitialized, and my brain
agrees.
gdb/ChangeLog:
* solib-svr4.c (svr4_read_so_list): Initialize first_l_name to 0.
runtest gdb.base/corefile.exp
==23174== ERROR: AddressSanitizer: heap-use-after-free on address 0x604400008c88 at pc 0x68f0be bp 0x7fffae9d7490 sp
0x7fffae9d7480
READ of size 8 at 0x604400008c88 thread T0
#0 0x68f0bd in svr4_read_so_list (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0x68f0bd)
#1 0x68f64e in svr4_current_sos_direct (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0x68f64e)
#2 0x68f757 in svr4_current_sos (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0x68f757)
#3 0xcebbff in update_solib_list (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0xcebbff)
0x604400008c88 is located 8 bytes inside of 1104-byte region [0x604400008c80,0x6044000090d0)
freed by thread T0 here:
#0 0x7f52677500f9 (/lib64/libasan.so.0+0x160f9)
#1 0xd2c68a in xfree (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0xd2c68a)
#2 0xceb364 in free_so (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0xceb364)
#3 0xca59f8 in do_free_so (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0xca59f8)
#4 0x93432a in do_my_cleanups (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0x93432a)
#5 0x934406 in do_cleanups (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0x934406)
#6 0x68efa9 in svr4_read_so_list (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0x68efa9)
I did not notice it during my review in:
Re: [PATCH v2] Skip vDSO when reading SO list (PR 8882)
https://sourceware.org/ml/gdb-patches/2013-09/msg00888.html
gdb/
2014-02-27 Jan Kratochvil <jan.kratochvil@redhat.com>
Additional PR 8882 fix.
* solib-svr4.c (svr4_read_so_list): Change first to first_l_name.
Message-ID: <20140226220918.GA10431@host2.jankratochvil.net>
Just a small optimization. No need to block/unblock signals if we're
not going to call sigsuspend.
gdb/
2014-02-27 Pedro Alves <palves@redhat.com>
* nat/linux-waitpid.c (my_waitpid): Only block signals if WNOHANG
isn't set.
So that gdbserver's Linux backend can use it too.
gdb/
2014-02-27 Pedro Alves <palves@redhat.com>
PR 12702
* linux-nat.c (status_to_str): Moved to nat/linux-waitpid.c.
* nat/linux-waitpid.c: Include string.h.
(status_to_str): Moved here and made extern.
* nat/linux-waitpid.h (status_to_str): New declaration.
Necessary to fix parsing auxv entries from core files on systems that use
the layout specified by ELF instead of the incompatible variant used by Linux.
gdb/Changelog:
* gdbarch.sh (auxv_parse): New.
* gdbarch.h: Regenerated.
* gdbarch.c: Regenerated.
* auxv.c (target_auxv_parse): Call gdbarch_parse_auxv if provided.
Starting with DWARF version 4, the description of the DW_AT_high_pc
attribute was amended to say:
if it is of class constant, the value is an unsigned integer offset
which when added to the low PC gives the address of the first
location past the last instruction associated with the entity.
A change was made in Apr 27th, 2012 to reflect that change:
| commit 91da14142c
| Author: Mark Wielaard <mjw@redhat.com>
| Date: Fri Apr 27 18:55:19 2012 +0000
|
| * dwarf2read.c (dwarf2_get_pc_bounds): Check DW_AT_high_pc form to
| see whether it is an address or a constant offset from DW_AT_low_pc.
| (dwarf2_record_block_ranges): Likewise.
| (read_partial_die): Likewise.
Unfortunately, this new interpretation is now used regardless of
the CU's DWARF version. It turns out that one of WindRiver's compilers
(FTR: Diabdata 4.4) is generating DWARF version 2 info with
DW_AT_high_pc attributes improperly using the data4 form. Because of
that, we miscompute all high PCs incorrectly. This leads to a lot of
symtabs having overlapping ranges, which in turn causes havoc in
pc-to-symtab-and-line translations.
One visible effect is when inserting a breakpoint on a given function:
(gdb) b world
Breakpoint 1 at 0x4005c4
The source location of the breakpoint is missing. The output should be:
(gdb) b world
Breakpoint 1 at 0x4005c8: file dw2-rel-hi-pc-world.c, line 24.
What happens in this case is that the pc-to-SAL translation first
starts be trying to find the symtab associated to our PC using
each symtab's ranges. Because of the high_pc miscomputation,
many symtabs end up matching, and the heuristic trying to select
the most probable one unfortunately returns one that is unrelated
(it really had no change in this case to do any better). Once we
have the wrong symtab, the start searching the associated linetable,
where the addresses are correct, thus finding no match, and therefore
no SAL.
This patch is an attempt at handling the situation as gracefully
as we can, without guarantees. It introduces a new function
"attr_value_as_address" which uses the correct accessor for getting
the value of a given attribute. It then adjust the code throughout
this unit to use this function instead of assuming that addresses always
have the DW_FORM_addr format.
It also fixes the original issue of miscomputing the high_pc
by limiting the new interpretation of constant form DW_AT_high_pc
attributes to units using DWARF version 4 or later.
gdb/ChangeLog:
* dwarf2read.c (attr_value_as_address): New function.
(dwarf2_find_base_address, read_call_site_scope): Use
attr_value_as_address in place of DW_ADDR.
(dwarf2_get_pc_bounds): Use attr_value_as_address to get
the low and high addresses. Slight rework of the handling
of the high pc being a constant form, and limit it to
DWARF verson 4 or higher.
(dwarf2_record_block_ranges): Likewise.
(read_partial_die): Likewise.
(new_symbol_full): Use attr_value_as_address in place of DW_ADDR.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dw2-abs-hi-pc-hello-dbg.S: New file.
* gdb.dwarf2/dw2-abs-hi-pc-hello.c: New file.
* gdb.dwarf2/dw2-abs-hi-pc-world-dbg.S: New file.
* gdb.dwarf2/dw2-abs-hi-pc-world.c: New file.
* gdb.dwarf2/dw2-abs-hi-pc.c: New file.
* gdb.dwarf2/dw2-abs-hi-pc.exp: New file.
Tested on x86_64-linux.
Right now the "file" command will discard the exec_bfd and then
possibly open a new one.
If this ends up reopening the same file, it can cause needless work by
gdb -- destroying all the per-BFD data just to re-read it again.
This patch changes the code to hold a reference to the old exec_bfd
while opening the new one.
The possible downside of this is a higher peak memory use.
2014-02-26 Tom Tromey <tromey@redhat.com>
* exec.c (exec_file_attach): Hold a reference to exec_bfd.
If minimal symbols have already been read into a per-BFD object, then
a symbol reader can skip re-reading them. This changes the ELF reader
to do so.
We only skip the work if the file is ELF+DWARF. If it has stabs or
mdebug sections, then I think extra information is computed during the
minsym creation pass; and so we must still repeat it. Eventually even
this will go away, once all symbol types have switched to being
progspace-independent. In the meantime this has no negative effect --
it is just a missing optimization for a small set of users.
This change also required a somewhat non-obvious change to the OBJSTAT
accounting code. If a symbol reader skips re-reading minimal symbols,
then the corresponding OBJSTAT will not be updated. This leads to a
test failure in gdb.base/maint.exp.
To fix this, I've moved the needed stat field out of objfile and into
the per-BFD object.
2014-02-26 Tom Tromey <tromey@redhat.com>
* elfread.c (elf_read_minimal_symbols): Return early if
minimal symbols have already been read. Add "ei" parameter.
(elf_symfile_read): Call elf_read_minimal_symbols earlier.
* minsyms.c (prim_record_minimal_symbol_full): Update.
* objfiles.h (struct objstats) <n_minsyms>: Move...
(struct objfile_per_bfd_storage) <n_minsyms>: ... here.
* symmisc.c (print_objfile_statistics): Update.
This is just a simple refactoring in elfread.c to split out the
minsym-reading code into its own function.
2014-02-26 Tom Tromey <tromey@redhat.com>
* elfread.c (elf_read_minimal_symbols): New function, from
elf_symfile_read.
(elf_symfile_read): Call it.
Now that minimal symbols are independent of the program space, we can
move them to the per-BFD object. This lets us save memory in the
multi-inferior case; and, once the symbol readers are updated, time.
The other prerequisite for this move is that all the objects referred
to by the minimal symbols have a lifetime at least as long as the
per-BFD object. I think this is satisfied partially by this patch
(moving the copied names there) and partially by earlier patches
moving the demangled name hash.
This patch contains a bit of logic to avoid creating new minimal
symbols if they have already been read for a given BFD. This allows
us to avoid trying to update all the symbol readers for this
condition. At first glance this may seem like a hack, but some symbol
readers mix psym and minsym reading, and would require logic just like
this regardless -- and it is simpler and less error-prone to just do
the work in a central spot.
2014-02-26 Tom Tromey <tromey@redhat.com>
* minsyms.c (lookup_minimal_symbol, iterate_over_minimal_symbols)
(lookup_minimal_symbol_text, lookup_minimal_symbol_by_pc_name)
(lookup_minimal_symbol_solib_trampoline)
(lookup_minimal_symbol_by_pc_section_1)
(lookup_minimal_symbol_and_objfile): Update.
(prim_record_minimal_symbol_full): Use the per-BFD obstack.
Don't allocate a minimal symbol if minsyms have already been read.
(build_minimal_symbol_hash_tables): Update.
(install_minimal_symbols): Do nothing if minsyms already read.
Use the per-BFD obstack.
(terminate_minimal_symbol_table): Use the per-BFD obstack.
* objfiles.c (allocate_objfile): Call
terminate_minimal_symbol_table later.
(have_minimal_symbols): Update.
* objfiles.h (struct objfile_per_bfd_storage) <msymbols,
minimal_symbol_count, msymbol_hash, msymbol_demangled_hash>:
Move from struct objfile.
<minsyms_read>: New field.
(struct objfile) <msymbols, minimal_symbol_count,
msymbol_hash, msymbol_demangled_hash>: Move.
(ALL_OBJFILE_MSYMBOLS): Update.
* symfile.c (read_symbols): Set minsyms_read.
(reread_symbols): Update.
* symmisc.c (dump_objfile, dump_msymbols): Update.
This removes the runtime offsets from minsyms. Instead, these offsets
will now be applied whenever the minsym's address is computed.
This patch redefines MSYMBOL_VALUE_ADDRESS to actually use the offsets
from the given objfile. Then, it updates all the symbol readers,
changing them so that they do not add in the section offset when
creating the symbol.
This change also lets us remove relocation of minsyms from
objfile_relocate1 and also msymbols_sort.
2014-02-26 Tom Tromey <tromey@redhat.com>
* minsyms.c (msymbols_sort): Remove.
* minsyms.h (msymbols_sort): Remove.
* objfiles.c (objfile_relocate1): Don't relocate minsyms.
* symtab.h (MSYMBOL_VALUE_ADDRESS): Use objfile offsets.
* elfread.c (elf_symtab_read): Don't add section offsets.
* xcoffread.c (record_minimal_symbol): Don't add section offset
to minimal symbol address.
* somread.c (text_offset, data_offset): Remove.
(som_symtab_read): Don't add section offsets to minimal symbol
addresses.
* coff-pe-read.c (add_pe_forwarded_sym, read_pe_exported_syms):
Don't add section offsets to minimal symbols.
* coffread.c (coff_symtab_read): Don't add section offsets
to minimal symbol addresses.
* machoread.c (macho_symtab_add_minsym): Don't add section offset
to minimal symbol addresses.
* mipsread.c (read_alphacoff_dynamic_symtab): Don't add
section offset to minimal symbol addresses.
* mdebugread.c (parse_partial_symbols): Don't add section
offset to minimal symbol addresses.
* dbxread.c (read_dbx_dynamic_symtab): Don't add section
offset to minimal symbol addresses.
This changes MSYMBOL_VALUE_ADDRESS to be an rvalue. In a later patch
we change this macro to compute its value; this patch introduces a
setter to make the break a bit cleaner.
2014-02-26 Tom Tromey <tromey@redhat.com>
* minsyms.c (prim_record_minimal_symbol_full): Use
SET_MSYMBOL_VALUE_ADDRESS.
* objfiles.c (objfile_relocate1): Use SET_MSYMBOL_VALUE_ADDRESS.
* sh64-tdep.c (sh64_elf_make_msymbol_special): Use
SET_MSYMBOL_VALUE_ADDRESS.
* symtab.h (MSYMBOL_VALUE_ADDRESS): Expand to an rvalue.
(SET_MSYMBOL_VALUE_ADDRESS): New macro.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
[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.
