To reproduce the problem, simply try the following with any program:
(gdb) maintenance agent-eval 1.0
Critical error handler: process [...] terminated due to access violation
(this is on Windows; on GNU/Linux, the libc copes better)
The problem is quite simple: gen_expr is given an expression that
contains an unrecognized operator (OP_DOUBLE in this case). When that
happens, it tries to report an error with a string image of the operator
in the error message. Conversion of the opcode into a string is done
using op_string which, despite its name, probably is not what the author
was looking for. This function returns NULL for a lot of the opcodes,
thus triggering the crash.
There is a function that corresponds to what we are looking for:
expprint.c:op_name. It was static, though, so I made it non-static,
and used it from ax-gdb.c:gen_expr.
gdb/ChangeLog:
* expression.h (op_name): Add declaration.
* expprint.c (op_name): Remove declaration. Make non-static.
* ax-gdb.c (gen_expr): Use op_name instead of op_string.
* gdb.base/auxv.c (func2): setrlimit to infinity to enable core dumps.
* gdb.base/auxv.exp: Try to compile it with -DUSE_RLIMIT first.
(generate native core dump): Make the test unsupported if core cannot
be generated.
Code cleanup.
* python/py-auto-load.c (source_section_scripts): New variable back_to.
Turn fclose and xfree calls into make_cleanup_fclose and make_cleanup
with xfree.
(auto_load_objfile_script): Turn fclose into make_cleanup_fclose.
* NEWS: Describe new options --init-command=FILE, -ix and
--init-eval-command=COMMAND, -iex.
* main.c (struct cmdarg): New enum items CMDARG_INIT_FILE and
CMDARG_INIT_COMMAND.
(captured_main): New enum items OPT_IX and OPT_IEX. Add
"init-command", "init-eval-command", "ix" and "iex" to the variable
long_options. Handle OPT_IX and OPT_IEX. Process them from CMDARG_VEC.
New comment for CMDARG_FILE and CMDARG_COMMAND processing.
(print_gdb_help): Describe --init-command=FILE, -ix and
--init-eval-command=COMMAND, -iex.
gdb/doc/
* gdb.texinfo (File Options): Describe --init-command=FILE, -ix and
--init-eval-command=COMMAND, -iex.
(Startup): Describe -iex and -ix. Simplify the example
for "set auto-load-scripts off".
gdb/testsuite/
* gdb.gdb/selftest.exp (do_steps_and_nexts): New entry
for cmdarg_vec = NULL. Remove entries for cmdsize = 1, cmdarg = and
ncmd = 0. New entry for VEC_cleanup cmdarg_s.
Code cleanup.
* main.c (struct cmdarg): Move it here from main. Add more comments.
(cmdarg_s, VEC (cmdarg_s)): New.
(main): Move struct cmdarg from here. New variables cmdarg_vec and
cmdarg_p. Remove variables cmdsize and ncmd and their initialization.
Install cleanup for cmdarg_vec. Update filling for options 'x' and
'X'. Replace cmdarg processing by cmdarg_vec processing. Remove xfree
of CMDARG.
Jan Kratochvil <jan.kratochvil@redhat.com>
* server.c (cont_thread, general_thread): Add describing comments.
(start_inferior): Clear `cont_thread'.
(handle_v_cont): Don't set `cont_thread' if resuming all threads
of a process.
PR symtab/13777
* dwarf2read.c (process_full_comp_unit): Set LOCATIONS_VALID only for
GCC >=4.5.
gdb/testsuite/
PR symtab/13777
* gdb.dwarf2/dw2-skip-prologue.S (DW_AT_producer): Set it to 4.5.0.
Consider the following declaration:
type Small is new Integer range 0 .. 2 ** 4 - 1;
type Simple_Array is array (1 .. 4) of Small;
pragma Pack (Simple_Array);
SA : Simple_Array := (1, 2, 3, 4);
Trying to change the value of one of the elements in the packed array
causes the debugger to crash:
(gdb) set sa(3) := 9
[1] 4880 segmentation fault gdb -q foo
The circumstances leading to the crash are as follow:
. ada_evaluate_subexp creates a value corresponding to "sa(3)".
. ada_evaluate_subexp then tries to assign 9 to this value, and
for this calls value_assign (via ada_value_assign).
. Because the array is packed, the destination value is 3 bits long,
and as a result, value_assign uses the parent to determine that
element byte address and offset:
| if (value_bitsize (toval))
| {
| struct value *parent = value_parent (toval);
|
| changed_addr = value_address (parent) + value_offset (toval);
The destination value (corresponding to "sa(3)") was incorrectly created
by ada-lang.c:ada_value_primitive_packed_val, because the "parent" was
left as NULL. So, when we try to dereference it to get the parent address,
GDB crashed.
The first part of the fix therefore consists in setting that field.
This required the addition of a new "setter" in value.[hc]. It fixes
the crash, but is still not sufficient for the assignment to actually
work.
The second part of the problem came from the fact that value_assign
seems to expect the "child"'s address to be equal to the parent's address,
with the difference being the offset. Unfortunately, this requirement was
not followed by ada_value_primitive_packed_val, so the second part of
the fix consisted in fixing that.
Still, this was not sufficient, because it caused a regression when
trying to perform an aggregate assignment of a packed array of packed
record. The key element here is the nesting of packed entities.
Looking at the way ada_value_primitive_packed_val creates the value
of each sub-component, one can see that the value's offset is set
to the offset compared to the start of the parent. This was meant to
match what value_primitive_field does as well.
So, with our array of records, if the record offset was 2, and if
the field we're interested in that record is at offset 1, the record
value's offset would be set to 2, and the field value's offset would
be set to 1. But the address for both values would be left to the
array's address. This is where things start breaking down, because
the value_address function for our field value would return the
address of the array + 1, instead of + 3.
This is what causes the final issue, here, because ada-lang.c's
value_assign_to_component needs to compute the offset of the
subcomponent compared to the top-level aggregate's start address
(the array in our case). And it does so by subtracting the array's
address from the sub-component's address. When you have two levels
of packed components, and the mid-level component is at an offset of
the top-level component, things didn't work, because the component's
address was miscomputed (the parent's offset is missing).
The fix consists is fixing value_address to match the work done by
value_primitive_field (where we ignore the parent's offset).
gdb/ChangeLog:
* value.h (set_value_parent): Add declaration.
* value.c (set_value_parent): New function.
(value_address): If VALUE->PARENT is not NULL, then use it as
the base address instead of VALUE->LOCATION.address.
* ada-lang.c (ada_value_primitive_packed_val): Keep V's address
the same as OBJ's address. Adjust V's offset accordingly.
Set V's parent.
gdb/testsuite/ChangeLog:
* gdb.ada/set_pckd_arr_elt: New testcase.
PR breakpoints/10738
* dwarf2read.c (use_deprecated_index_sections): New global.
(struct partial_die_info): New member may_be_inlined.
(read_partial_die): Set may_be_inlined where appropriate.
(add_partial_subprogram): Add partial symbols for partial
DIEs that may be inlined.
(new_symbol_full): Add inlined subroutines to the current
scope.
(write_psymtabs_to_index): Bump version number.
(dwarf2_read_index): Read only version 6 indices unless
use_deprecated_index_sections is set.
* linespec.c (symbol_and_data_callback): New structure.
(iterate_inline_only): New function.
(iterate_over_all_matching_symtabs): New argument
"include_inline". If nonzero, also call the callback for
symbols representing inlined subroutines.
(lookup_prefix_sym): Pass extra argument to the above.
(find_function_symbols): Likewise.
(add_matching_symbols_to_info): Likewise.
* NEWS: Mention that GDB can now set breakpoints on inlined
functions.
gdb/doc:
PR breakpoints/10738
* gdb.texinfo (Inline Functions): Remove the now-unnecessary @item
stating that GDB cannot set breakpoints on inlined functions.
(Mode Options): Document --use-deprecated-index-sections.
(Index Section Format): Document new index section version format.
gdb/testsuite:
PR breakpoints/10738
* gdb.opt/inline-break.exp: New file.
* gdb.opt/inline-break.c: Likewise.
* gdb.dwarf2/inline-break.exp: Likewise.
* gdb.dwarf2/inline-break.S: Likewise.
* gdb.base/annota1.exp: Cope with old .gdb_index warnings.
* gdb.base/async-shell.exp: Likewise.
* lib/mi-support.exp (library_loaded_re): Likewise.
(arm_register_g_packet_guesses): New function.
(arm_gdbarch_init): Don't force a target description with
registers when the executable is detected as M-profile. Instead
set gdbarch->tdep->is_m. Register `g' packet guesses.
(_initialize_arm_tdep): Initialize the new target description.
* features/arm-with-m-fpa-layout.xml: New description.
* features/arm-with-m-fpa-layout.c: New, generated.
When debugging on Windows with GDBserver, the debugger starts
failing after hitting a breakpoint. For instance:
(gdb) b foo
Breakpoint 1 at 0x40177e: file foo.adb, line 5.
(gdb) cont
Continuing.
Breakpoint 1, foo () at foo.adb:5
5 Put_Line ("Hello World."); -- STOP
(gdb) n
Program received signal SIGSEGV, Segmentation fault.
0x00401782 in foo () at foo.adb:5
5 Put_Line ("Hello World."); -- STOP
There are two issues:
1. While trying to re-insert a breakpoint that is still inserted
in memory, insert_bp_location wipes out the breakpoint location's
shadow_contents. As a consequence, we cannot restore the proper
instruction when removing the breakpoint anymore. That's why
the inferior's behavior changes when trying to resume after
the breakpoint was hit.
2. mem-break.c:default_memory_insert_breakpoint passes a breakpoint
location's shadow_contents as the buffer for a memory read.
This reveals a limitation of the various memory-read target
functions. This patch documents this limitation and adjust
the two calls that seem to hit that limitation.
gdb/ChangeLog:
* breakpoint.c (breakpoint_xfer_memory): Add assertion.
Update function description.
(insert_bp_location): Do not wipe bl->target_info out.
* mem-break.c: #include "gdb_string.h".
(default_memory_insert_breakpoint): Do not call target_read_memory
with a pointer to the breakpoint's shadow_contents buffer. Use
a local buffer instead.
* m32r-tdep.c (m32r_memory_insert_breakpoint): Ditto.
Fix double prompt of 'interpreter-exec mi'.
* mi/mi-interp.c (mi_execute_command_input_handler): New prototype.
(mi_interpreter_resume): use it.
(mi_execute_command_input_handler): New function.
* mi/mi-main.c (mi_execute_command): Move prompt printing to
mi_execute_command_input_handler.
gdb/testsuite/
* gdb.mi/mi2-prompt.exp: New file.
This patch fixes a problem when using gdb + gdbserver, and trying
to break on a function when one of the (enum) parameters is equal
to a certain value, and the size of that enum is 1 byte.
(gdb) break mixed.adb:15 if light = green
Breakpoint 2 at 0x402d5a: file mixed.adb, line 15.
(gdb) cont
Continuing.
[Inferior 1 (process 9742) exited normally]
The debugger should have stopped once when our function was call
with light set to green.
Here is what happens: Because we're using a recent GDBserver,
GDB hands off the evaluation of the condition to GDBserver, by
providing it in the Z0 packet. This is what GDB sends:
$Z0,402d5a,1;X13,26000622100223ff1c16100219162022011327#cf
I decoded the condition as follow:
260006 reg 6 -> push
2210 const8 0x10 -> push
02 add (stack now has 1 element equal to reg6 + 16)
23ff1c const16 0xff1c
1610 ext 16 (sign extend 16 bits)
02 add (stack now has 1 element equal to reg6 + 16 - 228)
19 ref32: Pop as addr, push 32bit value at addr.
1620 ext 32 (sign extend 32 bits)
2201 const8 0x01
13 equal
27 end
The beginning of the agent expression can be explained by the address
of symbol "light":
(gdb) info addr light
Symbol "light" is a variable at frame base reg $rbp offset 16+-228.
However, the mistake is the "ext 32" operation (extend 32 bits),
because our variable is *not* 32bits, only 8:
(gdb) print light'size
$5 = 8
But the reason why GDB decides to use a 32bit extension is because
it overrides the symbol's type with a plain integer type in
ax-gdb.c:gen_usual_unary...
/* If the value is an enum or a bool, call it an integer. */
case TYPE_CODE_ENUM:
case TYPE_CODE_BOOL:
value->type = builtin_type (exp->gdbarch)->builtin_int;
break;
... before calling require_rvalue. And of course, that causes the
generator to generate a sizeof(int) extension of the result.
One way to fix this would be to use an integer type of the correct
size, but I do not understand why this is necessary. The two routines
that use that information to generate the opcode down the line are
gen_fetch (for a memory value), or gen_extend (for a register value).
And they both have handling of enums and bools.
So the fix we elected to implement was simply to remove that code.
gdb/ChangeLog:
* ax-gdb.c (gen_usual_unary): Remove special handling of
enum and bool types.
