So far elinos.py was assuming that the whole ELinOS environment was
around to find the system libraries; if some environment variables
were missing, the script would just abort.
This was a bit extreme. It is possible to do better than that: to get
the core system libraries, one doesn't need to have a full environment
but just the path to the CDK. The path to kernel project is only
needed for the optional Xenomai libs.
gdb/ChangeLog:
* system-gdbinit/elinos.py (get_elinos_environment): Return an
incomplete dictionnary instead of None in case of missing
environment variables.
(elinos_init): in case of an incomplete environment, best
effort to load system libraries instead of abort.
When building the program with the shared GNAT runtime, the debugger
is unable to insert Ada exception catchpoints until that runtime
has been mapped to memory. In other words, we expect the user to start
the program first, before attempting to insert that catchpoint.
The detection mechanism that tries to provide some useful tips to
the user fails when the program itself contains a trampoline symbol
matching the symbol that the catchpoint is trying to use. This
results in the following error message:
(gdb) catch exception
Your Ada runtime appears to be missing some debugging information.
Cannot insert Ada exception catchpoint in this configuration.
Instead, we expected the following error message:
(gdb) catch exception
Unable to insert catchpoint. Try to start the program first.
gdb/ChangeLog:
* ada-lang.c (ada_has_this_exception_support): Ignore
mst_solib_trampoline minimal symbols.
* i386-darwin-nat.c (darwin_complete_target): Install methods for
hardware watchpoint.
(i386_darwin_dr_set): Support 32 and 64 bit states.
(i386_darwin_dr_get): Likewise.
(i386_darwin_dr_set_control): Make static.
(i386_darwin_dr_set_addr, i386_darwin_dr_get_addr)
(i386_darwin_dr_get_status, i386_darwin_dr_get_control): Likewise.
It is possible to have a build of glibc where SYS_perf_event_open is not
defined (because when the glibc was compiled, the syscall did not exist),
but have newer kernel headers installed so that linux/perf_event.h is
available. In this setup, you get a build failure:
./common/linux-btrace.c: In function 'kernel_supports_btrace':
./common/linux-btrace.c:316:23: error: 'SYS_perf_event_open' undeclared (first use in this function)
Update the ifdef check to also see if the syscall is available.
URL: https://bugs.gentoo.org/473522
Reported-by: William Throwe <wtt6@cornell.edu>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
(dwp_file): Split loaded_cutus into loaded_cus, loaded_tus.
All uses updated.
(dwarf2_section_empty_p): Rename arg from "info" to "section".
(dwarf2_read_section): Delete unused local "header". Add section
name to error message.
(create_dwo_in_dwp): Tweak comment.
(MAX_NR_DWO_SECTIONS): Combine count of .debug_macro + .debug_macinfo.
(get_section_bfd_owner, get_section_bfd_section): New functions.
(get_section_name, get_section_file_name): New functions.
(get_section_id, get_section_flags): New functions.
(*): Use new functions to access section fields.
(lookup_dwo_unit_in_dwp): Renamed from lookup_dwo_in_dwp. Remove
arg "htab". All callers updated.
(create_debug_types_hash_table): Remove redundant copy of
abbrev_section.
(create_dwo_in_dwp): Tweak comments.
(read_str_index): Tweak comment. Record dwarf form name in static
local.
I tried debugging a remote Windows program on Linux host, and pointed the
sysroot to "/some/path/" rather than "remote:", and I found GDB couldn't
find the dlls in the sysroot. If the dll name is
"C:/Windows/system32/ntdll.dll", I end up with the sysroot+in_pathname
concatenated this way:
(top-gdb) p temp_pathname
$1 = 0x228b690 "/some/pathC:/Windows/system32/ntdll.dll"
^^
That is, a directory separator is missing. This is a regression.
The problem is that solib_find decides that since the target path has
a drive spec, a separator is not necessary, which is clearly wrong in
this case. That check was added in
<https://sourceware.org/ml/gdb-patches/2013-06/msg00028.html>, to
handle the case of sysroot being "remote:". This patch fixes that
original issue in a different way. Instead of checking whether the
path has a drive spec, check whether the sysroot is "remote:". The
patch adds a table that helps visualize the cases that need a
separator. I also confirmed the original issue is still handled as
expected. That is, that "set sysroot remote:" still does the right
thing.
remote_filename_p returns true if the filename is prefixed with
"remote:". In this case, we need to check whether the filename is
exactly "remote:". I thought of different ways or either changing
remote_filename_p or adding another convenience function to remote.c
to avoid exposing the "remote:" prefix out of remote.c. But all
attempts turned out adding lot of over needless complication. So the
patch just exposes the prefix behind a new macro, which allows using a
straighforward strcmp.
gdb/
2013-09-27 Pedro Alves <palves@redhat.com>
* remote.h (REMOTE_SYSROOT_PREFIX): New define.
(remote_filename_p): Add comment.
* remote.c (remote_filename_p): Adjust to use
REMOTE_SYSROOT_PREFIX.
* solib.c (solib_find): When deciding whether we need to add a
directory separator, check whether the sysroot is "remote:"
instead of checking whether the patch has a drive spec. Add
comments.
I noticed these fields aren't really necessary -- if the T stop reply
indicated any we have any special event, the fallthrough doesn't
really do anything.
Tested on x86_64 Fedora 17 w/ local gdbserver, and also confirmed
"catch load" against a Windows gdbserver running under Wine, which
exercises TARGET_WAITKIND_LOADED, still works as expected.
gdb/
2013-09-27 Pedro Alves <palves@redhat.com>
* remote.c (struct stop_reply) <solibs_changed, replay_event>:
Delete fields.
(remote_parse_stop_reply): Adjust, setting event->ws.kind
directly.
AMD64_R15_REGNUM when a register index is expected.
* amd64-windows-tdep.c (amd64_windows_dummy_call_integer_regs):
Substitute in array.
* amd64-tdep.c (amd64_dwarf_regmap): Ditto.
(amd64_push_arguments): Substitute in integer_regnum array.
* NEWS: Mention "set debug symfile".
* Makefile.in (SFILES): Add symfile-debug.c.
(COMMON_OBS): Add symfile-debug.o.
* elfread.c (elf_symfile_read): Use objfile_set_sym_fns to set the
objfile's symbol functions.
* objfiles.h (objfile_set_sym_fns): Declare.
* symfile-debug.c: New file.
* symfile.c (syms_from_objfile_1): Use objfile_set_sym_fns to set the
objfile's symbol functions.
(reread_symbols): Ditto.
All uses updated.
(add_symtab_fns): Update prototype.
* symfile.c (sym_fns_ptr): Delete. Replace with ...
(registered_sym_fns): ... this.
(symtab_fns): Update.
(add_symtab_fns): New arg "flavour". All callers updated.
(find_sym_fns): Rewrite to use new sym_fns registry.
2013-09-25 Andreas Arnez <arnez@linux.vnet.ibm.com>
PR shlibs/8882
* solib-svr4.c (svr4_read_so_list): Skip the vDSO when reading
link map entries.
testsuite/ChangeLog:
2013-09-25 Andreas Arnez <arnez@linux.vnet.ibm.com>
PR shlibs/8882
* gdb.base/corefile.exp: Add a check to assure warning-free
core-file load.
This is no longer useful, as it was introduced to reuse the funcall
handling code in amd64-tdep.c in the context of x64-windows. But
we have since then changed the implementations to be completely
independent of each other.
This reverts the non-windows-specific part of the change called:
amd64: Integer parameters in function calls on Windows
(the x64-windows portion has already been reverted)
gdb/ChangeLog:
Revert:
* i386-tdep.h (enum amd64_reg_class): New, moved here from
amd64-tdep.c.
(struct gdbarch_tdep): Add fields call_dummy_num_integer_regs,
call_dummy_integer_regs, and classify.
* amd64-tdep.h (amd64_classify): Add declaration.
* amd64-tdep.c (amd64_dummy_call_integer_regs): New static constant.
(amd64_reg_class): Delete, moved to i386-tdep.h.
(amd64_classify): Make non-static. Move declaration to amd64-tdep.h.
Replace call to amd64_classify by call to tdep->classify.
(amd64_push_arguments): Get the list of registers to use for
passing integer parameters from the gdbarch tdep structure,
rather than using a hardcoded one. Replace calls to amd64_classify
by calls to tdep->classify.
(amd64_push_dummy_call): Get the register number used for
the "hidden" argument from tdep->call_dummy_integer_regs.
(amd64_init_abi): Initialize tdep->call_dummy_num_integer_regs
and tdep->call_dummy_integer_regs. Set tdep->classify.
This is no longer useful, as it was introduced to reuse the funcall
handling code in amd64-tdep.c in the context of x64-windows. But
we have since then changed the implementations to be completely
independent of each other.
This reverts the non-windows-specific part of the change called:
amd64-windows: memory args passed by pointer during function calls.
(the x64-windows portion has already been reverted)
gdb/ChangeLog:
Revert:
* i386-tdep.h (gdbarch_tdep): Add field memory_args_by_pointer.
* amd64-tdep.c (amd64_push_arguments): Add handling of architectures
where tdep->memory_args_by_pointer is non-zero.
This is no longer useful, as it was introduced to reuse the funcall
handling code in amd64-tdep.c in the context of x64-windows. But
we have since then changed the implementations to be completely
independent of each other.
This reverts the non-windows-specific part of the change called:
amd64-windows: 32 bytes allocated on stack by caller for integer
parameter regs
(the x64-windows portion has already been reverted)
gdb/ChangeLog:
Revert:
* i386-tdep.h (struct gdbarch_tdep): Add new field
integer_param_regs_saved_in_caller_frame.
* amd64-tdep.c (amd64_push_dummy_call): Allocate some memory on
stack if tdep->integer_param_regs_saved_in_caller_frame is set.
This patch provides a standalone implementation of function calls
on amd64-windows, instead of providing some bits and pieces hooking
into the function call implementation meant for sysV (in amd64-tdep).
It makes better sense to do it this way, because the two ABIs are
actually very different; for instance, the concept of argument
classification, which is so central in the sysV ABI and drove the
the implementation in amd64-tdep, makes no sense for Windows. It
is therefore better for the Windows implementation to be completely
separate, rather than rely on adaptations of the sysV implementation.
gdb/ChangeLog:
* amd64-tdep.c: #include "value.h"
(amd64_windows_classify): Delete.
(amd64_windows_passed_by_integer_register)
(amd64_windows_passed_by_xmm_register)
(amd64_windows_passed_by_pointer)
(amd64_windows_adjust_args_passed_by_pointer)
(amd64_windows_store_arg_in_reg, amd64_windows_push_arguments)
(amd64_windows_push_dummy_call): New functions.
(amd64_windows_init_abi): Remove setting of
tdep->call_dummy_num_integer_regs, tdep->call_dummy_integer_regs,
tdep->classify, tdep->memory_args_by_pointer and
tdep->integer_param_regs_saved_in_caller_frame.
Add call to set_gdbarch_push_dummy_call.
gdb/
2013-09-24 Jan Kratochvil <jan.kratochvil@redhat.com>
* dwarf2read.c (open_and_init_dwp_file): Try open_dwp_file also with
objfile->original_name.
gdb/testsuite/
2013-09-24 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.dwarf2/dwp-symlink.c: New file.
* gdb.dwarf2/dwp-symlink.exp: New file.
gdb/
2013-09-24 Jan Kratochvil <jan.kratochvil@redhat.com>
Pass down original filename for objfile.
* coffread.c (coff_symfile_read): Update symbol_file_add_separate call.
* elfread.c (elf_symfile_read): Likewise.
* jit.c (jit_object_close_impl): Update allocate_objfile call, no
longer set ORIGINAL_NAME.
(jit_bfd_try_read_symtab): Update symbol_file_add_from_bfd call.
* jv-lang.c (get_dynamics_objfile): Update allocate_objfile call.
* machoread.c (macho_add_oso_symfile): Add parameter name. Update
symbol_file_add_from_bfd call.
(macho_symfile_read_all_oso): Update two macho_add_oso_symfile calls.
(macho_check_dsym): Add parameter filenamep. Change function comment.
Set *filenamep.
(macho_symfile_read): New variable dsym_filename. Update
macho_check_dsym call. Use it for symbol_file_add_separate.
* objfiles.c (allocate_objfile): Add parameter name. New comment for
it. Use it for objfile->original_name.
(objfile_name): Return OBFD's filename, if available.
* objfiles.h (allocate_objfile): Add new parameter name.
* solib.c (solib_read_symbols): Update symbol_file_add_from_bfd call.
* symfile-mem.c (symbol_file_add_from_memory): Update
symbol_file_add_from_bfd call.
* symfile.c (read_symbols): Update symbol_file_add_separate call, new
comment for it.
(symbol_file_add_with_addrs): New parameter name, add function comment
for it. Remove variable name. Update allocate_objfile call.
(symbol_file_add_separate): New parameter name, add function comment
for it. Update symbol_file_add_with_addrs call.
(symbol_file_add_from_bfd): New parameter name. Update
symbol_file_add_with_addrs call.
(symbol_file_add): Update symbol_file_add_from_bfd call.
(reread_symbols): New variable original_name. Save
objfile->original_name by it.
* symfile.h (symbol_file_add_from_bfd, symbol_file_add_separate): Add
second parameter.
The recent change to make GDB auto-delete thread-specific breakpoints
when the corresponding thread is deleted
(https://sourceware.org/ml/gdb-patches/2013-09/msg00038.html) caused
gdb.base/nextoverexit.exp to regress.
Breakpoint 1, main () at .../gdb/testsuite/gdb.base/nextoverexit.c:21
21 exit (0);
(gdb) next
[Inferior 1 (process 25208) exited normally]
Thread-specific breakpoint -5 deleted - thread 1 is gone.
Thread-specific breakpoint -6 deleted - thread 1 is gone.
Thread-specific breakpoint -7 deleted - thread 1 is gone.
Thread-specific breakpoint 0 deleted - thread 1 is gone.
(gdb) FAIL: gdb.base/nextoverexit.exp: next over exit (the program exited)
We shouldn't be seeing this for internal or momentary breakpoints. In
fact, we shouldn't even be trying to delete them, as whatever created
them will take care or it, and therefore it's dangerous to delete them
behind the creator's back.
I thought it'd still be good to tag thread-specific internal/momentary
breakpoints such that we'll no longer try to keep them insert in the
target, as they'll cause stops and thread hops in other threads, so I
tried disabling them instead. That caused a problem when following a
child fork, and detaching from the parent, as we try to reset the
step-resume etc. breakpoints to the new child's thread
(breakpoint_re_set_thread), after the parent thread is already gone
(and the breakpoints are marked disabled). I fixed that by
re-enabling internal/momentary breakpoints there, but, that didn't
feel super safe either (maybe we'd need a new flag in struct
breakpoint instead, to tag the thread-specific breakpoint as "not to
be inserted"). It felt like I was heading down a design rat hole,
and, other things will usually delete internal/momentary breakpoints
soon enough, so I left that little optimization for some other day.
So, internal/momentary breakpoints are no longer deleted/disabled at
all, and we end up with a one-liner fix.
Tested on x86_64 Fedora 17.
gdb/
2013-09-19 Pedro Alves <palves@redhat.com>
* breakpoint.c (remove_threaded_breakpoints): Skip non-user
breakpoints.
This removes another instance of a deprecated_xfer_memory user.
gdb/
2013-09-19 Pedro Alves <palves@redhat.com>
Thomas Schwinge <thomas@codesourcery.com>
Yue Lu <hacklu.newborn@gmail.com>
* gnu-nat.c (gnu_read_inferior, gnu_write_inferior): Make static.
Take a gdb_byte pointer instead of a char pointer.
* gnu-nat.c (gnu_xfer_memory): Adjust interface as
gnu_xfer_partial helper.
(gnu_xfer_partial): New function.
(gnu_target): Don't install a deprecated_xfer_memory hook.
Install a to_xfer_partial hook.
gdb/
2013-09-19 Jan Kratochvil <jan.kratochvil@redhat.com>
Constification.
* main.c (captured_main): Replace catch_command_errors by
catch_command_errors_const. Twice.
* symfile.c (symbol_file_add_main_1): Make args parameter const.
(symbol_file_add): Make name parameter const.
(symbol_file_add_main, symbol_file_add_main_1): Make args parameter const.
(symfile_bfd_open): Make name parameter const, rename it to cname. Add
variable name. Change their usage accordingly.
* symfile.h (symbol_file_add, symfile_bfd_open): Make first parameter
const.
(symbol_file_add_main): Make args parameter const.
Ulrich Weigand <uweigand@de.ibm.com>
* xcoffread.c (struct coff_symbol): Use CORE_ADDR as type
of c_value member.
(read_xcoff_symtab): Use CORE_ADDR as type of fcn_start_addr.
2013-09-18 Pedro Alves <palves@redhat.com>
Yue Lu <hacklu.newborn@gmail.com>
* gnu-nat.c (inf_validate_procs, gnu_wait, gnu_resume)
(gnu_create_inferior)
(gnu_attach, gnu_thread_alive, gnu_pid_to_str, cur_thread)
(set_sig_thread_cmd): Use the lwpid field of ptids to
store/extract thread ids instead of the tid field.
* i386gnu-nat.c (gnu_fetch_registers): Adjust.
instead of ptid_t.tid.
In preparation for reusing gnu-nat.c in gdbserver, switch to storing
thread ids in the lwpid field of ptid_t rather than in the tid
field. The Hurd's thread model is 1:1, so it doesn't feel wrong
anyway.
gdb/
2013-09-18 Pedro Alves <palves@redhat.com>
* gnu-nat.c (inf_validate_procs, gnu_wait, gnu_resume)
(gnu_create_inferior)
(gnu_attach, gnu_thread_alive, gnu_pid_to_str, cur_thread)
(set_sig_thread_cmd): Use the lwpid field of ptids to
store/extract thread ids instead of the tid field.
* i386gnu-nat.c (gnu_fetch_registers): Adjust.
https://sourceware.org/ml/gdb-patches/2013-08/msg00170.html
gdb/ChangeLog
* infcmd.c (default_print_one_register_info): Add detection of
optimized out values.
(default_print_registers_info): Switch to using
get_frame_register_value.
gdb/testsuite/ChangeLog
* gdb.dwarf2/dw2-reg-undefined.exp: Change pattern for info
register to "<optimized out>", and also print the registers.
Skip the test on Cygwin too.
2013-09-18 Pedro Alves <palves@redhat.com>
PR server/15967
* gdb.server/wrapper.exp: Also return unsupported for Cygwin, and
change text.
By inspection, I noticed that when I made the gnu-nat use
ptid(pid,0,tid) to represent a thread, instead of using ptid(tid,0,0),
in <https://sourceware.org/ml/gdb-patches/2008-08/msg00175.html>, I
introduced a bug.
The change was:
else
{
- int tid = PIDGET (thread_id_to_pid (atoi (args)));
+ int tid = ptid_get_tid (thread_id_to_pid (atoi (args)));
if (tid < 0)
error (_("Thread ID %s not known. Use the \"info threads\" command to\n"
"see the IDs of currently known threads."), args);
and thread_id_to_pid does:
ptid_t
thread_id_to_pid (int num)
{
struct thread_info *thread = find_thread_id (num);
if (thread)
return thread->ptid;
else
return pid_to_ptid (-1);
}
(pid_to_ptid (-1) is the same as minus_one_ptid.)
So before, we were really looking at the pid, where thread_id_to_pid
stores the -1.
The right fix is to compare the whole ptid to minus_one_ptid, of
course.
Completely untested, but I think it's obvious enough, so I went ahead
and put it in.
gdb/
2013-09-18 Pedro Alves <palves@redhat.com>
* gnu-nat.c (set_sig_thread_cmd): Compare the thread's ptid to
minus_one_ptid instead of looking at the ptid's tid field and
comparing that to -1.
