It doesn't make sense to request an "unlimited" dcache. You want to
configure the cache with specific lines and length of lines.
It doesn't actually work anyway:
(gdb) set dcache line-size 0
Invalid dcache line size: 4294967295 (must be power of 2).
(gdb) set dcache size 0
(gdb) show dcache size
Number of dcache lines is unlimited.
(gdb) info dcache
Dcache 4294967295 lines of 64 bytes each.
No data cache available.
The code already has guards in place to forbid 0s:
static void
set_dcache_size (char *args, int from_tty,
struct cmd_list_element *c)
{
if (dcache_size == 0)
{
dcache_size = DCACHE_DEFAULT_SIZE;
error (_("Dcache size must be greater than 0."));
}
if (last_cache)
dcache_invalidate (last_cache);
}
static void
set_dcache_line_size (char *args, int from_tty,
struct cmd_list_element *c)
{
if (dcache_line_size < 2
|| (dcache_line_size & (dcache_line_size - 1)) != 0)
{
unsigned d = dcache_line_size;
dcache_line_size = DCACHE_DEFAULT_LINE_SIZE;
error (_("Invalid dcache line size: %u (must be power of 2)."), d);
}
if (last_cache)
dcache_invalidate (last_cache);
}
So we now get:
(gdb) set dcache line-size 0
Invalid dcache line size: 0 (must be power of 2).
(gdb) set dcache size 0
Dcache size must be greater than 0.
gdb/
2013-03-26 Pedro Alves <palves@redhat.com>
* dcache.c (_initialize_dcache): Make the "set dcache line-size"
and "set dcache size" commands zuinteger instead of uinteger.
Being a uinteger means you revert back to having GDB decide the
version. It makes no sense to have an "unlimited" version.
(gdb) show cris-version
The current CRIS version is 0.
(gdb) set cris-version 0
(gdb) show cris-version
The current CRIS version is unlimited.
(gdb)
gdb/
2013-03-26 Pedro Alves <palves@redhat.com>
* cris-tdep.c (_initialize_cris_tdep): Make the "set cris-version"
command zuinteger instead of uinteger.
Being a uinteger means you can't disable debug output after enabling it...
(gdb) show debug coff_pe_read
Coff PE read debugging is 0.
(gdb) set debug coff_pe_read 0
(gdb) show debug coff_pe_read
Coff PE read debugging is unlimited.
(gdb)
gdb/
2013-03-26 Pedro Alves <palves@redhat.com>
* coff-pe-read.c (_initialize_coff_pe_read): Make the command
zuinteger instead of uinteger.
When I tried running the btrace tests, I noticed something odd in the gdb.log file:
(gdb) run
Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.btrace/btrace22343.x
Breakpoint 1, main () at /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.btrace/btrace22343.c:1
1 /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.btrace/btrace22343.c: No such file or directory.
^^^^^^^^^^^^^^^^^^^^^^^^^
(gdb) record btrace
Target does not support branch tracing.
(gdb) testcase ../../../src/gdb/testsuite/gdb.btrace/enable.exp completed in 0 seconds
I knew that the btrace tests on my machine weren't supposed to work,
but still, that error made me wonder if the test had something broken,
and waste a few minutes looking up where that is coming from.
The issue is that the btrace detection deletes the source file right
after compiling it, and before GDB has a chance to open it. It's
really harmless, but I'd rather spare others from going through the
same exercise.
We now get the regular:
(gdb) run
Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.btrace/btrace24210.x
...
Breakpoint 1, main () at /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.btrace/btrace24210.c:1
1 int main(void) { return 0; }
...
gdb/testsuite/
2013-03-26 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (skip_btrace_tests): Delay deleting the source file
until after GDB has run.
While the commands are uinteger, the target interfaces are limited to
INT_MAX. Don't let the user request more than we can handle.
gdb/
2013-03-26 Pedro Alves <palves@redhat.com>
* record.c (record_insn_history_size_setshow_var)
(record_call_history_size_setshow_var): New globals.
(command_size_to_target_size): New function.
(cmd_record_insn_history, cmd_record_call_history): Use
command_size_to_target_size instead of cast.
(validate_history_size, set_record_insn_history_size)
(set_record_call_history_size): New functions.
(_initialize_record): Install set_record_insn_history_size and
set_record_call_history_size as "set" hooks of "set record
instruction-history-size" and "set record
function-call-history-size".
There's no need to put the majority of the logic into the 3rd arg of the
AC_ARG_ENABLE. Coupled with the lack of indentation, it makes it hard to
follow, error prone to update, and duplicates code (with the 4th arg).
So pull the logic out of the 3rd arg and outside of the AC_ARG_ENABLE
macro. This allows us to gut the 4th arg entirely, merge with the code
that followed the macro, and fix bugs related to the new dv-sockser in
the process.
Hopefully building the various sims with the default sim-hardware
settings, as well as with explicit --{dis,en}able-sim-hardware flags,
should all just work now.
Ref: http://www.sourceware.org/ml/gdb-patches/2002-08/msg00486.html
We've long since imported a newer readline, no need to use the old
compatibility variable anymore.
Tested on x86_64 Fedora 17.
gdb/
2013-03-26 Pedro Alves <palves@redhat.com>
* top.c (gdb_rl_operate_and_get_next): Replace max_input_history
use with history_max_entries use. Remove FIXME note.
2013-03-26 Douglas B Rupp <rupp@gnat.com>
* config/tc-ia64.c (emit_one_bundle): Move last_slot adjustment
after fixup.
gas/testsuite/
2013-03-26 Douglas B Rupp <rupp@adacore.com
* gas/ia64/ia64.exp: Add new test reloc-mlx
* gas/ia64/reloc-mlx.[sd]: New test for X-unit reloc.
* gas/ia64/pcrel.d: Fix output for X-unit reloc.
Reading symbols from /bin/true...(no debugging symbols found)...done.
(gdb) b _start
Function "_start" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (_start) pending.
(gdb) r
Starting program: /bin/true
Breakpoint 1, 0x00000039a0400af0 in _start () from /lib64/ld-linux-x86-64.so.2
(gdb) rec b
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /bin/true
Breakpoint 1, 0x00000039a0400af0 in _start () from /lib64/ld-linux-x86-64.so.2
(gdb) rec b
gdb/record-btrace.c:154: internal-error: record_btrace_open:
Assertion `record_btrace_thread_observer == NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
gdb/
* record-btrace.c (record_btrace_close): Call
record_btrace_auto_disable.
testsuite/
* gdb.btrace/enable.exp: Add regression test.
* c-exp.y (exp): Add new productions for destructors after '.' and
'->'.
(write_destructor_name): New function.
gdb/testsuite
* gdb.cp/m-static.exp: Add destructor-printing tests.
usual common symbols as well as for dynamic. Add poldbfd param.
Save old bfd. Adjust callers.
(_bfd_elf_add_default_symbol): Add poldbfd param. Pass "section"
and "value" by value, not pointer. Adjust caller.
(elf_link_add_object_symbols): Combine undef_bfd and old_bfd vars.
Delete code to set same. Use old_bfd and old_alignment from
_bfd_elf_merge_symbol instead. Add default symbol before
alignment and size checks. Wrap overlong lines.
(_bfd_elf_init_reloc_shdr): Delete.
* elf.c (_bfd_elf_init_reloc_shdr): Make static.
* elf64-x86-64.c (elf_x86_64_merge_symbol): Trim parameters to
just what is needed.
* elflink.c (_bfd_elf_merge_symbol): Update bed->merge_symbol call.
* configure.ac: Fail if dv-sockser.o not available.
Error when --disable-sim-hardware is specified.
* tconfig.in: Conditionalize use of dv_sockser_install.
* configure: Regenerated.
* config.in: Regenerated.
* configure.ac: Address use of dv-sockser.o.
* tconfig.in: Conditionalize use of dv_sockser_install.
* configure: Regenerated.
* config.in: Regenerated.
* acinclude.m4: Add SIM_DV_SOCKSER_O which is empty on hosts
which do not support dv-sockser.o. Add always as option to
first argument to SIM_AC_OPTION_HARDWARE. Fail if hardware
is always required to be enabled by simulator.
windows-nat.c (windows_get_absolute_argv0): New function.
windows-nat.h: Add its prototype.
main.c (get_init_files): Use filename_ncmp instead of strncmp.
Use IS_DIR_SEPARATOR instead of looking for a character inside
SLASH_STRING. Include filenames.h.
(captured_main) [__MINGW32__]: Make argv[0] absolute, so that
relocate_gdb_directory works when passed gdb_program_name.
Include windows-nat.h.
* elflink.c (elf_link_add_object_symbols): Don't set def_regular
or ref_regular for BFD_PLUGIN owned syms, or have them affect
def_dynamic/ref_dynamic.
(_bfd_elf_fix_symbol_flags): Don't set def_regular for BFD_PLUGIN
owned syms.
* exceptions.h (enum errors): New entry TARGET_CLOSE_ERROR.
* remote.c (trace_error): Remove the special handling of '2'.
(readchar) <SERIAL_EOF>
(readchar) <SERIAL_ERROR>
(getpkt_or_notif_sane_1): Use TARGET_CLOSE_ERROR for them.
(remote_get_trace_status): Call throw_exception if EX is
TARGET_CLOSE_ERROR.
* utils.c (perror_with_name): Rename to ...
(throw_perror_with_name): ... here. New parameter errcode, describe it
in the function comment.
(perror_with_name): New function wrapper.
* utils.h (enum errors): New stub declaration.
(throw_perror_with_name): New declaration.
gdb/testsuite/
* gdb.server/server-kill.c: New file.
* gdb.server/server-kill.exp: New file.
The range validation added by
http://sourceware.org/ml/gdb-patches/2013-03/msg00767.html
Changes things to allow setting the command to INT_MAX or UINT_MAX
directly, with signed and unsigned commands respectively. However,
that went a little bit too far, as in the cases of var_integer and
var_uinteger, those values are actually implementation detail. It's
better to not expose them in the interface, and have users assume
those values mean "unlimited" too, so to be safer to expand the range
of the commands in the future if we want to. Yes, it's pedantic, and
it's not likely users actually will do this, but MI frontends and
Python scripts might.
gdb/
2013-03-22 Pedro Alves <palves@redhat.com>
Yao Qi <yao@codesourcery.com>
Mark Kettenis <kettenis@gnu.org>
* cli/cli-setshow.c (do_set_command) <var_uinteger>:
Don't let the user set the value to UINT_MAX directly.
<var_integer>: Don't let the user set the value to INT_MAX
directly.
The range validation added by
http://sourceware.org/ml/gdb-patches/2013-03/msg00767.html
Changes things to allow setting the command to INT_MAX or UINT_MAX
directly, with signed and unsigned commands respectively. However,
that went a little bit too far, as in the cases of var_integer and
var_uinteger, those values are actually implementation detail. It's
better to not expose them in the interface, and have users assume
those values mean "unlimited" too, so to be safer to expand the range
of the commands in the future if we want to. Yes, it's pedantic, and
it's not likely users actually will do this, but MI frontends and
Python scripts might.
gdb/
2013-03-22 Pedro Alves <palves@redhat.com>
Yao Qi <yao@codesourcery.com>
Mark Kettenis <kettenis@gnu.org>
* cli/cli-setshow.c (do_set_command) <var_uinteger>:
Don't let the user set the value to UINT_MAX directly.
<var_integer>: Don't let the user set the value to INT_MAX
directly.
