for internal variables.
(last_was_structop): New static variable.
(COMPLETE): New token.
(field_exp): New rule to group all '.' suffix handling.
Add mark_struct_expression calls when approriate to be able
to correctly find fields for completion.
(yylex): Adapt to handle field completion and set INTVAR when
required.
Wide_Characters and Wide_Wide_Characters are incorrectly printed.
Consider for instance:
Medium : Wide_Character := Wide_Character'Val(16#dead#);
Trying to print the value of this variable yields:
(gdb) p medium
$1 = 57005 '["ad"]'
The integer value is correct (57005 = 0xdead), but the character
representation is not, it should be:
$1 = 57005 '["dead"]'
Same for Wide_Wide_Characters.
There were two issues:
(a) The first issue was in ada-valprint, where we were assuming
that character types were 1 byte long;
(b) The second problem was in c-valprint, where we were down-casting
the integer value of the character to type `unsigned char',
causing use to lose all but the lowest byte.
gdb/ChangeLog:
* ada-valprint. (ada_printchar): Use the correct type length
in call to ada_emit_char.
* c-valprint.c (c_val_print): Remove cast in call to LA_PRINT_CHAR.
gdb/ChangeLog:
* ia64-hpux-nat.c (ia64_hpux_fetch_register): Remove trailing
new-line at end of warning message.
(ia64_hpux_store_register): Remove trailing new-line at end of
error message.
* ia64-hpux-tdep.c: Rephrase comment.
* solib-ia64-hpux.c (struct dld_info): Change type of field
dld_flags from "long long" to ULONGEST.
This function is unused, and the default formatting routine does
just fine, I think. On pa-hpux:
[New process 12565, lwp 2513]
[New process 12565, lwp 2514]
So this patch deletes it.
gdb/ChangeLog:
* hpux-thread.c (hpux_pid_to_str): Delete.
This fixes the printing of Wide_Wide_String objects. For instance,
consider:
My_WWS : Wide_Wide_String := " helo";
Before this patch is applied, GDB prints:
(gdb) print my_wws
$1 = " ["00"]h["00"]e"
gdb/ChangeLog:
* ada-valprint.c (ada_emit_char): Remove strange code.
Check that c is <= UCHAR_MAX before passing it to isascii.
(char_at): Do not assume that TYPE_LEN is either 1 or 2.
When interactive-mode is not auto, GDB always uses that setting to
determine whether to act as if the input stream is a terminal or not.
However, this setting should only be honored if the input stream is
the standard input stream. Otherwise, we run into trouble while
source-ing a GDB script, as shown below (on x86_64-linux):
% cat script
print 1
print 2
% gdb -q
(gdb) set interactive-mode on
(gdb) source script
(gdb) print 3
$1 = 3
The lack of output and the fact that the "print 3" command returned
a value saved in $1 (as opposed to $3) indicates that the script was
not even evaluated at all.
gdb/ChangeLog:
* top.c (input_from_terminal_p): Restrict the use of interactive_mode
to the case where instream is stdin.
gdb/testsuite/ChangeLog:
* gdb.base/interact.exp: New testcase.
We have two stacks to deal with on ia64, when making a function call.
The first is the usual stack frame, and the second is the register
stack frame. On ia64-linux, the register frame is setup by adjusting
the BSP register. Unfortunately for us, the HP-UX kernel does not allow
the debugger to change the value of the BSP.
To work around that limitation, the method I am using here is to push
some assembly code on the stack. This assembly code contains, among
other things, a call to the alloc insn, which sets up our frame for us.
An extensive comment in ia64-hpux-tdep.c explains the entire procedure.
Despite this approach, most of the code in ia64-tdep.c which sets up
the function call is still applicable - and only a few things need
to be done differently: For instance, instead of changing the BSP,
we do nothing. We store the parameters at a different location, etc.
So this patch also adjusts the inf-call code in ia64-tdep.c to make it
a little more extensible: I create a new ia64_infcall_ops structure
which allows an ABI to define how the few things that need to be
differentiated.
Another element that turned out to be necessary but is more of a detail
is that the computation of the linkage pointer needs to be handled
specially for symbols inside shared libraries. This is especially
visible when calling malloc, which happens everytime memory needs to
be allocated in inferior memory... The special treatment included
again the necessity to use some routines only available on the host.
So another target object TARGET_OBJECT_HPUX_SOLIB_GOT was created for
that purpose.
gdb/ChangeLog:
* ia64-tdep.h (struct regcache): Forward declare.
(struct ia64_infcall_ops): New struct type.
(struct gdbarch_tdep): New fields "find_global_pointer_from_solib"
and "infcall_ops".
* ia64-tdep.c (ia64_find_global_pointer_from_dynamic_section):
Renames ia64_find_global_pointer.
(ia64_find_global_pointer, ia64_allocate_new_rse_frame)
(ia64_store_argument_in_slot, ia64_set_function_addr: New function.
(ia64_push_dummy_call): Adjust to use the new tdep ia64_infocall_ops
methods.
(ia64_infcall_ops): New static global constant.
(ia64_gdbarch_init): Set tdep->infcall_ops.
* ia64-hpux-nat.c (ia64_hpux_xfer_solib_got): New function.
(ia64_hpux_xfer_partial): Add TARGET_OBJECT_HPUX_SOLIB_GOT handing.
* ia64-hpux-tdep.c: Include "regcache.h", "gdbcore.h" and "inferior.h".
(ia64_hpux_dummy_code): New static global constant.
(ia64_hpux_push_dummy_code, ia64_hpux_allocate_new_rse_frame)
(ia64_hpux_store_argument_in_slot, ia64_hpux_set_function_addr)
(ia64_hpux_dummy_id, ia64_hpux_find_global_pointer_from_solib):
New function.
(ia64_hpux_infcall_ops): New static global constant.
(ia64_hpux_init_abi): Install gdbarch and tdep methods needed
for inferior function calls to work properly on ia64-hpux.
This fixes unwinding from a thread that is stopped inside a system call.
This can be seen when switching to a thread that is stopped doing a
pthread_cond_wait, for instance...
The comments inside the code should explain what is happening in our
case (the HP-UX exception in the case of system calls): Under certain
circumstances (program stopped inside syscall), the offset to apply to
the current BSP in order to compute the previous BSP is not the usual
CFM & 0x7f.
We parts in this patch:
1. Figuring out that we are stopped inside a syscal: This requires
a TT_LWP_RUREGS ttrace call, which is not directly possible from
ia64-tdep.c. So use defined a new TARGET_OBJECT_HPUX_UREGS object
to request it from the -nat side.
2. Add a gdbarch_tdep method that allows us to change the default
behavior on ia64-hpux, permitting us to have a different "size of
register frame" in that one particular case.
gdb/ChangeLog:
* target.h (enum target_object): Add TARGET_OBJECT_HPUX_UREGS.
* ia64-tdep.h (struct frame_info): forward declaration.
(struct gdbarch_tdep): Add field size_of_register_frame.
* ia64-tdep.c (ia64_access_reg): Use tdep->size_of_register_frame
to determine the size of the register frame.
(ia64_size_of_register_frame): New function.
(ia64_gdbarch_init): Set tdep->size_of_register_frame.
* ia64-hpux-tdep.c: Include "target.h" and "frame.h".
(IA64_HPUX_UREG_REASON): New macro.
(ia64_hpux_stopped_in_syscall, ia64_hpux_size_of_register_frame):
New functions.
(ia64_hpux_init_abi): Set tdep->size_of_register_frame.
* ia64-hpux-nat.c (ia64_hpux_xfer_uregs): New function.
(ia64_hpux_xfer_partial): Add handling of TARGET_OBJECT_HPUX_UREGS
objects.
When attaching to a process, the ttrace interface was creating a ptid
with a null LWP, because it did not have it yet. This LWP was then
set as soon as we received our first event from our inferior, during
our first wait. Similarly, the allocation of the thread private info
was also defered.
This works on PA/HP-UX, because we immediately perform a wait to pop
the event triggered by the attach. We can use that event to extract
the thread's LWP. But this does not work for IA64/HP-UX, because
the attach no longer triggers an event, and thus a wait should NOT
be performed (such a wait would simply block indefinitely).
It is actually possible, however, to determine the thread's LWP.
This change therefore adjusts the attach code to create a thread with
the correct LWP set, as well as with its private info allocated.
Same thing for all the other threads.
gdb/ChangeLog:
[ttrace] Compute thread list immediately after attach.
* inf_ttrace_attach (inf_ttrace_create_threads_after_attach):
New subprogram.
(inf_ttrace_attach): Use it.
This is something that I am seeing on ia64-hpux while trying to
backtrace from a thread that's doing a wait:
(gdb) task 2
[Switching to task 2]
0x9fffffffef52f590 in __ksleep () from /[...]/libc.so.1
(gdb) bt
#0 0x9fffffffef52f590 in __ksleep () from /[...]/libc.so.1
#1 0x9fffffffef73c870 in __sleep_1x1 () from /[...]/libpthread.so.1
#2 0x9fffffffef738fe0 in __mxn_sleep () from /[...]/libpthread.so.1
#3 0x9fffffffef675e90 in ?? () from /[...]/libpthread.so.1
The backtrace is incomplete and stops at frame #3, but there are in fact
a few more frames.
The reason why we stopped the backtrace is related to the fact that
we were not able to determine the start address of the function
corresponding to the frame PC. This is visible at the user level
thanks to the "??" that GDB displayed for frame 3.
We have the following code in libunwind-frame.c:libunwind_frame_cache
which explicitly returns a NULL cache when we couldn't determine the
frame's function address, immediately triggering an end-of-stack
frame_id, thus terminating the backtrace:
/* We can assume we are unwinding a normal frame. Even if this is
for a signal trampoline, ia64 signal "trampolines" use a normal
subroutine call to start the signal handler. */
cache->func_addr = get_frame_func (this_frame);
if (cache->func_addr == 0
&& get_next_frame (this_frame)
&& get_frame_type (get_next_frame (this_frame)) == NORMAL_FRAME)
return NULL;
As explained in the comment, I think we can still go on, and use
the unwind record to do the debugging. This change imlements this
change, and allows us to get the full backtrace.
gdb/ChangeLog:
* libunwind-frame.c (libunwind_frame_cache): Do not return NULL
if we could not determine the frame's function address. Instead,
use the frame's PC, and then continue.
This patch fixes a small problem on ia64-hpux when calling functions
whose parameter are small integral values (less than 8 bytes). In
that case, the parameter value was stored on the wrong side of the
register. Same problem for return values.
With this patch, the results for gdb.base/callfuncs.exp improve from
# of expected passes 41
# of unexpected failures 78
To:
# of expected passes 95
# of unexpected failures 24
gdb/ChangeLog:
* ia64-tdep.c (ia64_struct_type_p): New function.
(ia64_extract_return_value): Handle integral values that are
less than 8 bytes long.
(ia64_push_dummy_call): Likewise.
ia64-tdep.c defines a floatformats_ia64_ext that should contain
both the little-endian and the big-endian version of the float
format used in the ia64 registers (an 82bit float format).
Right now, both entries point to the same little-endian definition.
A big-endian definition is now necessary for the ia64-hpux port.
gdb/ChangeLog:
* ia64-tdep.c (floatformat_ia64_ext_little): Renames
floatformat_ia64_ext.
(floatformat_ia64_ext_big): New static const.
(floatformats_ia64_ext): Set first entry to &floatformat_ia64_ext_big.
Tom Tromey
Pierre Muller
gdbadmin
Alan Modra
H.J. Lu
Yao Qi
Joel Brobecker
Mike Frysinger
Pedro Alves
Ralf Wildenhues