Questions about some changes in GDB between 6.8 and 7.0

[Antony KING <antony dot king at st dot com>]

Hi,

I am in the process of upgrading our GDB from a 6.8 derivative to a
version based on 7.0 (which will eventually be moved to 7.1) and I have
a number of questions about some changes in behaviour in GDB between 6.8
and 7.0.

1) In GDB 6.8 the command 'set buffer = "a string"', where "buffer" is
defined as an array (e.g. "char buffer[12]"), would result in GDB
performing a simple write to target memory of the specified string
value, e.g:

(gdb) set debug target 1
(gdb) set buffer = "a string"
child:target_xfer_partial (2, (null), 0x0,  0xbfffc5a0,  0x8049500, 12)
= 4, bytes =
 30 31 32 33
child:target_xfer_partial (2, (null), 0x0,  0xbfffc5a4,  0x8049504, 8) =
4, bytes = 34 35 36 00
child:target_xfer_partial (2, (null), 0x0,  0xbfffc5a8,  0x8049508, 4) =
4, bytes = 00 00 00 00

In GDB 7.0 this has changed so that the string is now copied into memory
alloc'd from the target heap (using malloc) and the resulting pointer is
then assigned to buffer, which obviously fails (since the types are
incompatible) with the error "Invalid cast".

Question: Is there a way of restoring the previous GDB 6.8 behaviour
since the GDB 7.0 strategy is not desirable (as it requires the target
to be restarted and so invalidating the target state) ?

2) In GDB 6.8 setting a H/W breakpoint (using a remote style target
connection) was performed without needing to perform any target memory
reads at the H/W breakpoint address. With GDB 7.0 this is no longer the
case and GDB is now reading memory at this address (to detect permanent
breakpoints - see below). This new behaviour is unfortunate since one of
the reasons for using H/W breakpoints is to cope with targets where
memory may not be currently accessible (e.g. debugging boot from ROM
code) and accessing it may be fatal (e.g. causing the H/W to lock up).

This memory read is being performed by bp_loc_is_permanent(), which is
not really suitable when dealing with H/W breakpoints.

Question: Would a suitable fix be to only call bp_loc_is_permanent() (in
create_breakpoint()) for S/W breakpoints (i.e. when the type is
bp_breakpoint) ? E.g.:

      if ((type == bp_permanent) && bp_loc_is_permanent (loc))

3) I am seeing some strange symbolic information being reported by GDB
7.0 which is not the case when I debug the same executable in GDB 6.8.
Weirdness I have observed includes the following:

a) a function in a one object file is somehow being "merged" into a
function from another object with the effect that an incorrect argument
list is shown by GDB. Note that both object files have been compiled
with debug information.

Question: Any ideas why this might happen ?

b) in C++ applications the destructor for a class is now shown have an
additional parameter (other than the "this" parameter), for example:

  Breakpoint 4, ~FRED (this=address, __in_chrg=<value optimized out>) at
cxx.cxx:33

Question: After a bit of searching in the GCC sources I think the above
is not an error but I am curious as to why GDB 6.8 does not show the
__in_chrg parameter but GDB 7.0 does ?

FYI the code has been compiled for an embedded target using locally
maintained versions of GCC 4.3.4 and binutils 2.19 tools for the SH-4
architecture with the newlib C run-time library (version 1.18.0) with
our own libgloss equivalent library. The output file format is ELF (with
DWARF2 debug information).

Sorry for the long email :-).

Cheers,

Antony.