This patch adds support for disassembly of blocks with non-contiguous
ranges. These blocks are printed as follows:
(gdb) disassemble foo
Dump of assembler code for function foo:
Address range 0x401136 to 0x401151:
0x0000000000401136 <+0>: push %rbp
0x0000000000401137 <+1>: mov %rsp,%rbp
0x000000000040113a <+4>: callq 0x401134 <bar>
0x000000000040113f <+9>: mov 0x2eef(%rip),%eax # 0x404034 <e>
0x0000000000401145 <+15>: test %eax,%eax
0x0000000000401147 <+17>: je 0x40114e <foo+24>
0x0000000000401149 <+19>: callq 0x401128 <foo+4294967282>
0x000000000040114e <+24>: nop
0x000000000040114f <+25>: pop %rbp
0x0000000000401150 <+26>: retq
Address range 0x401128 to 0x401134:
0x0000000000401128 <+-14>: push %rbp
0x0000000000401129 <+-13>: mov %rsp,%rbp
0x000000000040112c <+-10>: callq 0x401126 <baz>
0x0000000000401131 <+-5>: nop
0x0000000000401132 <+-4>: pop %rbp
0x0000000000401133 <+-3>: retq
End of assembler dump.
This is an actual dump from the test case that I constructed for
this work. The ranges are printed in the order encountered in the
debug info. For the above example, note that the second range occupies
lower addresses than the first range.
Functions with contiguous ranges are still printed as follows:
(gdb) disassemble main
Dump of assembler code for function main:
0x0000000000401151 <+0>: push %rbp
0x0000000000401152 <+1>: mov %rsp,%rbp
0x0000000000401155 <+4>: callq 0x401136 <foo>
0x000000000040115a <+9>: mov $0x0,%eax
0x000000000040115f <+14>: pop %rbp
0x0000000000401160 <+15>: retq
End of assembler dump.
gdb/ChangeLog:
* cli/cli-cmds.c (block.h): Include.
(print_disassembly): Handle printing of non-contiguous blocks.
(disassemble_current_function): Likewise.
(disassemble_command): Likewise.
This change adds an optional output parameter BLOCK to
find_pc_partial_function. If BLOCK is non-null, then *BLOCK will be
set to the address of the block corresponding to the function symbol
if such a symbol was found during lookup. Otherwise it's set to the
NULL value. Callers may wish to use the block information to
determine whether the block contains any non-contiguous ranges. The
caller may also iterate over or examine those ranges.
When I first started looking at the broken stepping behavior associated
with functions w/ non-contiguous ranges, I found that I could "fix"
the problem by disabling the find_pc_partial_function cache. It would
sometimes happen that the PC passed in would be between the low and
high cache values, but would be in some other function that happens to
be placed in between the ranges for the cached function. This caused
incorrect values to be returned.
So dealing with this cache turns out to be very important for fixing
this problem. I explored three different ways of dealing with the
cache.
My first approach was to clear the cache when a block was encountered
with more than one range. This would cause the non-cache pathway to
be executed on the next call to find_pc_partial_function.
Another approach, which I suspect is slightly faster, checks to see
whether the PC is within one of the ranges associated with the cached
block. If so, then the cached values can be used. It falls back to
the original behavior if there is no cached block.
The current approach, suggested by Simon Marchi, is to restrict the
low/high pc values recorded for the cache to the beginning and end of
the range containing the PC value under consideration. This allows us
to retain the simple (and fast) test for determining whether the
memoized (cached) values apply to the PC passed to
find_pc_partial_function.
Another choice that had to be made regards setting *ADDRESS and
*ENDADDR. There are three possibilities which might make sense:
1) *ADDRESS and *ENDADDR represent the lowest and highest address
of the function.
2) *ADDRESS and *ENDADDR are set to the start and end address of
the range containing the entry pc.
3) *ADDRESS and *ENDADDR are set to the start and end address of
the range in which PC is found.
An earlier version of this patch implemented option #1. I found out
that it's not very useful though and, in fact, returns results that
are incorrect when used in the context of determining the start and
end of the function for doing prologue analysis. While debugging a
function in which the entry pc was in the second range (of a function
containing two non-contiguous ranges), I noticed that
amd64_skip_prologue called find_pc_partial_function - the returned
start address was set to the beginning of the first range. This is
incorrect for this function. What was also interesting was that this
first invocation of find_pc_partial_function correctly set the cache
for the PC on which it had been invoked, but a slightly later call
from skip_prologue_using_sal could not use this cached value because
it was now being used to lookup the very lowest address of the
function - which is in a range not containing the entry pc.
Option #2 is attractive as it would provide a desirable result
when used in the context of prologue analysis. However, many callers,
including some which do prologue analysis want the condition
*ADDRESS <= PC < *ENDADDR to hold. This will not be the case when
find_pc_partial_function is called on a PC that's in a non-entry-pc
range. A later patch to this series adds
find_function_entry_range_from_pc as a wrapper of
find_pc_partial_function.
Option #3 causes the *ADDRESS <= PC < *ENDADDR property to hold. If
find_pc_partial_function is called with a PC that's within entry pc's
range, then it will correctly return the limits of that range. So, if
the result of a minsym search is passed to find_pc_partial_function
to find the limits, then correct results will be achieved. Returned
limits (for prologue analysis) won't be correct when PC is within some
other (non-entry-pc) range. I don't yet know how big of a problem
this might be; I'm guessing that it won't be a serious problem - if a
compiler generates functions which have non-contiguous ranges, then it
also probably generates DWARF2 CFI which makes a lot of the old
prologue analysis moot.
I've implemented option #3 for this version of the patch. I don't see
any regressions for x86-64. Moreover, I don't expect to see
regressions for other targets either simply because
find_pc_partial_function behaves the same as it did before for the
contiguous address range case. That said, there may be some
adjustments needed if GDB encounters a function requiring prologue
analysis which occupies non-contiguous ranges.
gdb/ChangeLog:
* symtab.h (find_pc_partial_function): Add new parameter `block'.
* blockframe.c (cache_pc_function_block): New static global.
(clear_pc_function_cache): Clear cache_pc_function_block.
(find_pc_partial_function): Move comment to symtab.h. Add
support for non-contiguous blocks.
This change sets BLOCK_RANGES for the block under consideration by
calling make_blockranges(). This action is performed in
dwarf2_record_block_ranges().
It should be noted that dwarf2_record_block_ranges() already does some
recording of the range via a call to record_block_range(). The ranges
recorded in that fashion end up in the address map associated with the
blockvector for the compilation unit's symtab. Given an address, the
addrmap provides a fast way of finding the block containing that
address. The address map does not, however, provide a convenient way
of determining which address ranges make up a particular block.
While reading a set of ranges, a vector of pairs is used to collect
the starting and ending addresses for each range in the block. Once
all of the ranges for a block have been collected, make_blockranges()
is called to fill in BLOCK_RANGES for the block.
The ranges are stored for the block in the order that they're read
from the debug info. For DWARF, the starting address of the first
range of the block will be the entry pc in cases where DW_AT_entry_pc
is not present. (Well, that would ideally be the case. At the moment
DW_AT_entry_pc is not being handled.)
gdb/ChangeLog:
* dwarf2read.c (dwarf2_record_block_ranges): Fill in BLOCK_RANGES
for block.
This patch does the following:
- Introduces a block range data structure which is accessed via
a new field in struct block.
- Defines several macros for accessing block ranges.
- Defines a new function, make_blockrange, which is responsible for
creating the new data structure.
It should be noted that some support for non-contiguous ranges already
existed in GDB in the form of blockvector addrmaps. This support
allowed GDB to quickly find a block containing a particular address
even when the block consists of non-contiguous addresses. See
find_block_in_blockvector() in block.c, dwarf2_record_block_ranges()
in dwarf2read.c, and record_block_range() in buildsym.c.
Addrmaps do not provide a convenient way to examine address ranges
associated with a particular block. This data structure (and its
interface) is set up for quickly finding the value (which in this case
is a block) associated with a particular address. The interface
does not include a method for doing a reverse mapping from blocks to
addresses. A linear time mapping might be attempted via use of the
addrmap's foreach method, but this is not as straightforward as it
might first appear due to the fact that blocks corresponding to inline
function instances and lexical blocks w/ variables end up getting
interspersed in in the set of transitions.
Note: If this approach is deemed to be too expensive in terms of
space, an alternate approach might be to attempt the linear time
mapping noted above. find_pc_partial_function() needs to be able to
quickly know whether there are discontiguous ranges, so a flag for
this property would have to be added to struct block. Also integral
to this set of changes is the concept of an "entry pc" which might be
different from the block's start address. An entry_pc field would
also need to be added to struct block. This does not result in any
space savings in struct block though since the space for the flag and
entry_pc use more space than the blockranges struct pointer that I've
added. There would, however, be some space savings due to the fact
that the new data structures that I've added for this patch would not
need to be allocated. (I happen to like the approach I've come up
with, but I wanted to mention another possibility just in case someone
does not.)
gdb/ChangeLog:
* block.h (blockrange, blockranges): New struct declarations.
(struct block): Add new field named `ranges'.
(BLOCK_RANGES, BLOCK_NRANGES, BLOCK_RANGE, BLOCK_CONTIGUOUS_P)
(BLOCK_RANGE_START, BLOCK_RANGE_END, BLOCK_ENTRY_PC): New
macros for accessing ranges in struct block.
(make_blockranges): New declaration.
block.c (make_blockranges): New function.
PR 23460
* plugin.c (struct plugin_list_entry): New structure.
(plugin_list): New variable.
(try_load_plugin): Place opened plugins on a list. Ensure that
the refcount in the dynamic loader is kept at 1.
When reading symbols from the vector of oso files on Mac OS X
Darwin, a previous commit introduce a change in the loop and add
an increment at each loop iteration whereas this incrementation is
not needed since the increment or set of the loop control variable
is already done in the loop.
gdb/ChangeLog:
* machoread.c (macho_symfile_read_all_oso): Remove uneeded
incrementation.
Change-Id: I3a5a6deb4e9d834ee7d4217a62d90c2ffb7241bc
The "-fPIC" and "-mcmodel=small" parts of these messages isn't always
true, so lets dispense with that and just report the type of stub
causing trouble.
* elf64-ppc.c (ppc64_elf_relocate_section): Revise "call lacks
nop" error message.
localentry:1 is a valid encoding, so display it. The patch also bails
out of get_ppc64_symbol_other when st_other bits besides the three
used for localentry offsets are set, to avoid hiding any such values.
* readelf.c (get_ppc64_symbol_other): Return NULL if st_other
field contains unrecognised or reserved values. Handle
localentry:1 value.
PR 23061
* coffgen.c (coff_pointerize_aux): Add table_end parameter. Use
it to prevent walking off the end of the table.
(coff_get_normalized_symtab): Pass internal_end pointer to
coff_pointerize_aux.
This patch makes read_program_headers_from_bfd return a gdb::byte_vector
instead of a plain pointer.
gdb/ChangeLog:
* solib-svr4.c (read_program_headers_from_bfd): Return
gdb::optional<gdb::byte_vector>.
(svr4_exec_displacement): Adjust.
While reading a recent patch, I found this spot where a gdb::byte_vector
could be used instead of an allocated buffer returned as a plain
pointer.
gdb/ChangeLog:
* solib-svr4.c (read_program_header): Return
gdb::optional<gdb::byte_vector>, remove p_sect_size param.
(find_program_interpreter): Return
gdb::optional<gdb::byte_vector>.
(scan_dyntag_auxv): Adjust.
(enable_break): Adjust.
(svr4_exec_displacement): Adjust.
Commit
c12a508 ("Add client_state struct.")
inadvertently changed the default behavior of GDBserver wrt address
randomization. The old disable_randomization global variable was
initialized to 1, whereas the corresponding field in the client_state
structure is initialized to 0.
This fixes
make check TESTS="gdb.base/jit-simple.exp" RUNTESTFLAGS="--target_board=native-gdbserver"
make check TESTS="gdb.base/execl-update-breakpoints.exp" RUNTESTFLAGS="--target_board=native-gdbserver"
Note that the execl-update-breakpoints.exp would only fail on systems
where the toolchain emits position-independent executables by default
(otherwise the main executable position is never randomized, so the
value of disable_randomization didn't matter).
gdb/gdbserver/ChangeLog:
PR gdb/23374
PR gdb/23375
* server.h (struct client_state) <disable_randomization>:
Initialize to 1.
I noticed that the child_terminal_save_inferior function was not used
since the commit f6ac5f3d63 ("Convert struct target_ops to C++"). I
was able to make a little test program to illustrate the problem (see
test case).
I think we're just missing the override of the terminal_save_inferior
method in inf_child_target (along with the other terminal-related
methods).
Instead of creating a new test, I thought that gdb.base/term.exp was a
good candidate for testing that gdb restores properly the inferior's
terminal settings.
gdb/ChangeLog:
* inf-child.h (inf_child_target) <terminal_save_inferior>: New.
* inf-child.c (inf_child_target::terminal_save_inferior): New.
gdb/testsuite/ChangeLog:
* gdb.base/term.exp: Compare terminal settings with values from
the inferior.
* gdb.base/term.c: Get and set terminal settings.
Most usages of xstrvprintf in GDB can be replaced with string_vprintf,
removing some manual memory management.
gdb/ChangeLog:
* guile/scm-string.c (gdbscm_scm_from_printf): Use
string_vprintf.
* guile/scm-utils.c (gdbscm_printf): Likewise.
* serial.c (serial_printf): Likewise.
* xml-support.c (gdb_xml_parser::vdebug): Likewise.
When printing frames on an MI channel also print the frame
architecture like in:
(gdb)
-stack-list-frames 3 3
^done,stack=
[frame={level="3",addr="0x000107a4",func="foo",
file="recursive2.c",fullname="/home/foo/bar/recursive2.c",
line="14",arch="i386:x86_64"}]
(gdb)
This is useful for MI clients that need to know the architecture in
order to perform further analysis, for example to use their own
disassembler to analyze machine code.
gdb/Changelog:
2018-08-22 Jan Vrany <jan.vrany@fit.cvut.cz>
* stack.c (print_frame): Print frame architecture when printing on
an MI output.
* NEWS: Mention new "arch" attribute in frame output.
gdb/testsuite/Changelog
2018-08-22 Jan Vrany <jan.vrany@fit.cvut.cz>
* lib/mi-support.exp (mi_expect_stop): Update regexp to
accommodate new "arch" field in frame output.
* gdb.mi/mi-return.exp: Likewise.
* gdb.mi/mi-stack.exp: Likewise.
* gdb.mi/mi-syn-frame.exp: Likewise.
* gdb.mi/user-selected-context-sync.exp: Likewise.
gdb/doc/Changelog
2018-08-22 Jan Vrany <jan.vrany@fit.cvut.cz>
* gdb.texinfo (The -stack-list-frames Command): Update description
to mention "arch".
Update MI examples throughout the document to contain "arch" in
frame output.
* elf-hppa.h (elf_hppa_fake_sections): Use SHT_PARISC_UNWIND as
the section type of the .PARISC.unwind section on 64-bit binaries
and SHT_PROGBITS for 32-bit binaries. Add a comment about it.
Add comment about the sh_entsize value.
Fixes a bogus out of range error:
Number of section headers: 0 (210016)
Section header string table index: 1 <corrupt: out of range>
Caused due to e_shnum remaining as zero rather than being updated to
the value from section_header[0].sh_info at the point where we range
check e_shstrndx.
* readelf.c (process_file_header): Assign updated values from
section_header[0] fields to e_phnum, e_shnum and e_shstrndx
during printing of header. Correct e_shstrndx range check.
Remove unnecessary casts and use %u rather than %ld for
unsigned int header fields. Don't print a random %lx when
reporting an unknown EI_VERSION.
* bfd/elf32-s12z.c: (opru18_reloc): New function.
* bfd/elf32-s12z.c: (elf_s12z_howto_table): Adjust Howto according to new knowledge.
* include/elf/s12z.h: Rename R_S12Z_UKNWN_3 to R_S12Z_EXT18.
A complication with the Guile code is that we have two types of
exceptions to consider: GDB/C++ exceptions, and Guile/SJLJ exceptions.
Because Guile exceptions are SJLJ based, we must make sure to not have
live local variables of types with non-trivial dtors when a Guile
exception is thrown, because the dtors won't be run when a Guile
exceptions is thrown.
gdbscm_parse_function_args currently violates this:
void
gdbscm_parse_function_args (const char *func_name,
int beginning_arg_pos,
const SCM *keywords,
const char *format, ...)
{
...
/* Keep track of malloc'd strings. We need to free them upon error. */
std::vector<char *> allocated_strings;
...
for (char *ptr : allocated_strings)
xfree (ptr);
gdbscm_throw (status); /// dtor of "allocated_strings" is not run!
}
This commit fixes the above making using of gdbscm_wrap.
It would be nice if we had a way to make it impossible to write such
code. PR guile/23429 has an idea for that, if someone's interested.
gdb/ChangeLog:
2018-08-21 Pedro Alves <palves@redhat.com>
* guile/scm-utils.c (gdbscm_parse_function_args_1): New, factored
out from gdbscm_parse_function_args.
(gdbscm_parse_function_args): Rework to use gdbscm_wrap and
gdbscm_parse_function_args_1.
* config/tc-z80.c: Correct treatment of undocumented instruction
sli/sll.
(emit_mr): Add argument unportable.
(emit_bit): Adapt call to emit_mr.
(emit_mr_z80): New function.
(emit_mr_unportable): New function.
(instab[]): Replace emit_mr with emit_mr_z80 or emit_mr_unportable
as appropriate.
Bug 17816 pointed out a useless use of the ternary operator:
case 0x0: sd.reg = (size == 1 ? &st->r0 : &st->r0); break;
I believe that this is right. If size is 1, the instruction refers to
part of r0, while if size is 2, the instruction refers to the whole of
r0.
gdb/ChangeLog:
PR gdb/17816
* m32c-tdep.c (m32c_decode_srcdest4): Remove unnecessary ternary
operator.
Most optional operands to powerpc instructions use a default value of
zero, but there are a few exceptions. Those have been handled by
PPC_OPERAND_OPTIONAL_VALUE and an entry in the powerpc_operands table
for the default value, smuggled in the shift field. This patch
changes that to using the operand extract function to provide non-zero
defaults.
I've also moved the code determining whether optional operands are
provided or omitted, to the point the first optional operand is seen,
and allowed for the possibility of optional base register operands
in a future patch.
The patch does change the error you get on invalid assembly like
ld 3,4
You'll now see "missing operand" rather than
"syntax error; end of line, expected `('".
gas/
* config/tc-ppc.c (md_assemble): Delay counting of optional
operands until one is encountered. Allow for the possibility
of optional base regs, ie. PPC_OPERAND_PARENS. Call
ppc_optional_operand_value with extra args.
include/
* opcode/ppc.h (struct powerpc_operand): Correct "insert" comment.
Mention use of "extract" function to provide default value.
(PPC_OPERAND_OPTIONAL_VALUE): Delete.
(ppc_optional_operand_value): Rewrite to use extract function.
opcodes/
* ppc-dis.c (operand_value_powerpc): Init "invalid".
(skip_optional_operands): Count optional operands, and update
ppc_optional_operand_value call.
* ppc-opc.c (extract_dxdn): Remove ATTRIBUTE_UNUSED from used arg.
(extract_vlensi): Likewise.
(extract_fxm): Return default value for missing optional operand.
(extract_ls, extract_raq, extract_tbr): Likewise.
(insert_sxl, extract_sxl): New functions.
(insert_esync, extract_esync): Remove Power9 handling and simplify.
(powerpc_operands <FXM4, TBR>): Delete PPC_OPERAND_OPTIONAL_VALUE
flag and extra entry.
(powerpc_operands <SXL>): Likewise, and use insert_sxl and
extract_sxl.
These take up far too many lines in the files. This patch introduces
a replacement for the HOWTO macro that simplifies the relow howto
initialization. Apart from the two relocs mentioned in the ChangeLog,
no relocation howto is changed.
* elf64-ppc.c (HOW): Define.
(ONES): Delete.
(ppc64_elf_howto_raw): Use HOW to initialize entries.
* elf32-ppc.c (HOW): Define.
(ppc_elf_howto_raw): Use HOW to initialize entries, updating
R_PPC_VLE_REL15 and R_PPC_VLE_REL24 to use bitpos=0.
This patch uses bitfields in reloc_howto_struct, reducing its size
from 80 to 40 bytes on 64-bit hosts and from 52 to 32 bytes on 32-bit
hosts (with a 32-bit bfd_vma). I've also added a new "negate" field
rather than making the encoded "size" field do double duty as both
a size and a flag.
There was just one use of an encoded size of 8, which according to
bfd_get_reloc_size meant 16 bytes, in vms-alpha.c ALPHA_R_LINKAGE.
See git commit c3d8e071bf adding ALPHA_R_LINKAGE and git commit
8612a388f7 decoding size 8 in bfd_get_reloc_size. Since no other part
of BFD handles 16 byte relocs, I've removed that encoding and special
cased the ALPHA_R_LINKAGE size in vms-alpha.c.
* reloc.c (reloc_howto_type): Typedef.
(bfd_symbol): Delete forward declaration.
(struct reloc_howto_struct): Add "negate" field. Make "size",
"bitsize", "rightshift", "bitpos", "complain_on_overflow",
"pc_relative", "partial_inplace", and "pcrel_offset" bitfields.
Rearrange for better packing. Revise comments.
(HOWTO): Map to rearranged reloc_howto_struct.
(bfd_get_reloc_size): Delete now unused cases.
(read_reloc, write_reloc): Likewise.
(apply_reloc, _bfd_relocate_contents): Test howto->negate
rather than howto->size < 0 for negated relocation values.
* coff-rs6000.c (xcoff_complain_overflow_bitfield_func): Avoid
signed/unsigned warning.
(xcoff_ppc_relocate_section): Delete "condition is always false"
code.
* coff64-rs6000.c (xcoff64_ppc_relocate_section): Likewise.
* cpu-ns32k.c (do_ns32k_reloc): Adjust to suit reloc_howto_struct
changes.
* vms-alpha.c (_bfd_vms_write_etir, alpha_vms_slurp_relocs): Use
size 16 for ALPHA_R_LINKAGE.
(alpha_howto_table <ALPHA_R_LINKAGE>): Set encoded size and
bitsize to zero.
* bfd-in.h (reloc_howto_type): Delete.
* bfd-in2.h: Regenerate.
NEWHOWTO was promised way back in 1991 (git commit e568362218).
I doubt it's ever going to be implemented. This patch removes it,
and tidies some reloc howtos. I was going to make some changes to
reloc_howto_struct, so I think it's important that all relocs howtos
are initialized with HOWTO.
* reloc.c (HOWTO): Revise comment.
(NEWHOWTO, HOWTO_PREPARE): Delete.
* coff-arm.c (coff_arm_reloc_type_lookup): Replace const struc
reloc_howto_struct with reloc_howto_type.
* ns32knetbsd.c (MY_bfd_reloc_type_lookup): Likewise.
* vms-alpha.c (alpha_vms_bfd_reloc_type_lookup): Likewise.
* elf-hppa.h (HOW): Define.
(elf_hppa_howto_table): Use it to simplify this table, correcting
name of R_PARISC_LTOFF16WF, R_PARISC_LTOFF_FPTR64, and
R_PARISC_LTOFF_FPTR16DF.
* elf32-mep.c (MEPREL): Use HOWTO.
* bfd-in2.h: Regenerate.
When it can be done at compile time.
* mmo.c (valid_mmo_symbol_character_set): Initialize and make
array const.
(mmo_init): Don't init valid_mmo_symbol_character_set.
Kevin Buettner
Jim Wilson
Zenith423
Xavier Roirand
Alan Modra
H.J. Lu
Nick Clifton
GDB Administrator
Simon Marchi
Simon Marchi
Jan Vrany
Helge Deller
Rafeal Auler
Alan Hayward
John Darrington
Pedro Alves
mephi42
Arnold Metselaar
L. Simon
Andreas Schwab