gmane.comp.gdb.devel

gdbserver tracepoint arm support

Elcoelettronica — 2013-05-21T10:17:38

Hello,

I am trying to trace my application on my board.

I compiled gdbserver 7.6 for arm with:

cd /gdb-7.6-src/gdb/gdbserver
./configure --target=arm-linux --host=arm-linux
make CC=/path/to/cross-compiler-gcc

Then I compiled gdb 7.6 for arm with:

cd /gdb-7.6-src/
./configure --target=arm-linux --prefix=/opt/gdb-arm/install/
make && make install

I compiled my trivial application with:

/path/to/cross-compiler-gcc hello.c -g -o hello

I copied gdbserver and my cross-compiled application on my board. From 
my pc (x86-pc-linux) I run:

gdb hello
(gdb) set target-async on
(gdb) tvariable $c
(gdb) actions
 >teval $c=$c+1
 >end
(gdb) break main
(gdb) target remote <ipaddr>:<port>
[Thread 1585] #1 stopped.
0x40000800 in ?? ()
Cannot access memory at address 0x0
(gdb) continue &
(gdb) tstart
Target does not support this command.
(gdb) tstatus
Target does not support this command.

The behaviour is 'normal' until the tstart command: I can debug the 
application as I want, but I am unable to start tracing the app.

Does gdbserver support tracepoints for arm or only for x86/amd_64?

Thanks in advance,
Riccardo

add-inferior / clone-inferior

David Taylor — 2013-05-20T14:43:25

The commands add-inferior / clone-inferior and several related commands
were added as long ago as gdb 7.1.  But, unless I'm missing the obvious,
they aren't currently very useful.

GDB appears to support multiple "live" inferiors only when the arise as
the result of a fork or vfork.  Please tell me that I'm wrong and that
I'm missing the obvious.

    . I start up gdb with no arguments
    . file my-elf-file
    . clone-inferior
    . info inferiors

I now have two inferiors, numbers 1 and 2, same elf file; 1 is curent.

    . target remote <arguments>
    . inferior 2
    . target remote <different-arguments>

And I get:

    A program is being debugged already.  Kill it? (y or n)

I also tried attaching to two pre-existing processes, one each two
different inferiors.  That failed as well.

I've looked more at remote targets than attached / forked targets, as we
are more interested in remote targets.  Thursday last week I would have
loved to have had 10 inferiors, 5 elf files, 2 inferiors per elf file.

Looking at remote.c, it stores a global pointer to a structure
containing a file descriptor and other state in remote_desc.

This variable, and presumably others, are inferior specific.

Looking at inferior.h I see:

  /* Private data used by the target vector implementation.  */
  struct private_inferior *private;

Based on the comment, the structure should probably be called
private_target rather than private_inferior.

I'm thinking that remote.c should define a struct private_inferior
containing, at least, a pointer to 'struct serial *remote_desc' and then
*EITHER* changing inferiors needs to save / restore remote_desc (which
would mean target_ops entries for { saving / restoring } state when you
{ switch away from / switch back to } an inferior *OR* all references to
remote_desc need to be modified to get to it via

    current_inferior -> private -> remote_desc -> ...

I'm also thinking that target_ops needs to have a couple of additional fields:

    . a boolean -- does the target support multiple concurrent active
    instances?

    . a counter -- how many active instances do we currently have?

I'm also guessing that the above is just the tip of the iceberg or
someone would have already done this.

What else needs to happen for this to work?  I'm trying to get a feel
for how big a project this would be and whether it would be better for
us to pursue other options.

Thanks.

David

p.s.  It would also be nice if inferiors could be named, otherwise
you'll end up creating a crib sheet telling you which is which.  It's
trivial, but it makes me think that no one really uses add-inferior /
clone-inferior.
--
David Taylor
dtaylor< at >emc.com

[GDB 7.6/GCC 4.8.0] Slowdown in GDB macro processing for cores?

Paul Smith — 2013-05-16T19:42:15

Hi all.  Is anyone aware of an issue with a big slowdown running macros
on core files?  I'm not sure if this is related to GCC 4.8 or GDB 7.6,
or what, but I'm seeing a 4x or more slowdown when running macros on
core files from previous releases.

Running against a live process is the same speed as before.

Details: we were building/debugging with the system compiler and
debugger (e.g., GCC 4.5.2 / GDB 7.2).  Speed of macros when dealing with
core files here was acceptable.  FYI, our code is C++ with a small to
moderate number of templates and compiled (in this case) with "-g", and
no optimization.

I wanted to use a new compiler with an encapsulated environment so we
could unify our build toolchain.  I created a separately-installed
version of GCC 4.8.0/binutils 2.23.2.

Then we discovered that trying to use older GDB instances with the
results of this build failed, because they couldn't read the DWARF4
object format generated by GCC 4.8.0.  I thought about dropping back to
an older DWARF format but instead I built GDB 7.6 and added that to our
toolchain.

Now we can debug and everything works well, except that we've noticed
this major slowdown only when debugging corefiles.

The macros are nothing fancy: they just walk through some of our data
structures printing interesting information; for example:

  set $current = $arg0.first
  set $size = 0
  while $current
    printf "node[%u]: id=", $size

    if $current->flags & 1
      printf "*"
    end

    if $current->flags & 2
      printf "^"
    end

    printf "%d, localId=%d, incarnation=%d, type=%d, state=%d\n",
$current->node->nodeId, $current->node->localId,
$current->incarnationNumber, $current->node->nodeType,
$current->node->nodeState
    set $current = $current.next
    set $size++
  end

Against a core file it takes a second or longer per iteration of this
loop!  FWIW, the class this macro operates on is very large and contains
a lot of data per object.

Any ideas?  Is there a handy way to tell where the slowdown is happening
here?  Should we just drop back to DWARF2 or DWARF3 (I haven't checked
if that will help tho)?

GDB and libthread_db.so.1 issue

Avi Gozlan — 2013-05-16T12:30:05

Hello,

I have got a problem with debugging 32bit applications on a target x86_64 machine.

I use 64bit gdb 7.1 on a x86_64 machine (running 'file `which gdb`' returns ELF 64-bit LSB executable, AMD x86-64...)
I can debug 64bit applications successfully on this target machine. However, when trying to debug 32bit applications, I get the following error message:
Cannot find new threads: generic error

Both libpthread.so.0 and libthread_db.so.1 were copied from another machine, both are located in /lib64. (for the sake of trouble shooting I replaced also libc.so.6 and ld-linux-x86.so.2 with libraries copied from that same machine).

When debugging gdb itself, I saw that indeed these shared libraries are loaded by gdb (by running 'info shared'). Yet debugging fails with 32bit programs. The top of the gdb's backtrace for the failure is the following:

#0  thread_db_err_str (err=TD_ERR) at linux-thread-db.c:264
#1  0x0000000000497897 in find_new_threads_callback (th_p=0x7fffffffb760,
    data=0x7fffffffb840) at linux-thread-db.c:1306
#2  0x0000003154202000 in iterate_thread_list () from /lib64/libthread_db.so.1
#3  0x00000031542020b5 in td_ta_thr_iter () from /lib64/libthread_db.so.1
#4  0x0000000000497aea in find_new_threads_once (info=0xd38a50, iteration=0,
    errp=0x7fffffffb8c0) at linux-thread-db.c:1378
#5  0x0000000000497ccc in thread_db_find_new_threads_2 (ptid=...,
    until_no_new=0) at linux-thread-db.c:1445
#6  0x0000000000497d2b in thread_db_find_new_threads_1 (ptid=...)
    at linux-thread-db.c:1454
#7  0x00000000004976d9 in thread_db_wait (ops=0xb21ca0, ptid=...,
    ourstatus=0x7fffffffbad0, options=0) at linux-thread-db.c:1247
#8  0x0000000000588734 in target_wait (ptid=..., status=0x7fffffffbad0,
    options=0) at target.c:2132
#9  0x0000000000551de6 in wait_for_inferior (treat_exec_as_sigtrap=0)
    at infrun.c:2270
#10 0x0000000000551468 in proceed (addr=18446744073709551615,
    siggnal=TARGET_SIGNAL_0, step=0) at infrun.c:1896
#11 0x000000000054ad68 in run_command_1 (args=0x0, from_tty=1,
    tbreak_at_main=0) at infcmd.c:585
#12 0x000000000054ad9b in run_command (args=0x0, from_tty=1) at infcmd.c:595
#13 0x00000000004bc730 in do_cfunc (c=0xb80070, args=0x0, from_tty=1)

It appears that the libthread_db library is called by gdb but identifies a problem. As said, the  very same libraries are loaded by gdb for a successful 64bit applications debugging.

I would be thankful if you could shed light on this issue.

Thanks,

Avi

Why gdb fail to make

hitlar — 2013-05-15T10:50:49

Why gdb fail to make. i have already configure & make binutils-2.23.51-1,
gcc-core-3.4.4, gcc-c++-3.4.4 for target i386-elf (cygwin  version 2.774 and
window7),  but when i build gdb-7.6.50-2 it gives following error
Shine< at >Shine-PC /usr/src/gdb-elf-7.6.50-2
 ../gdb-7.6.50-2/configure --prefix=/usr/local/i386 --target=i386-elf

Shine< at >Shine-PC /usr/src/gdb-elf-7.6.50-2
$ make
make[1]: Entering directory `/usr/src/gdb-elf-7.6.50-2'
make[2]: Entering directory `/usr/src/gdb-elf-7.6.50-2/libiberty'
make[3]: Entering directory `/usr/src/gdb-elf-7.6.50-2/libiberty/testsuite'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/usr/src/gdb-elf-7.6.50-2/libiberty/testsuite'
make[2]: Leaving directory `/usr/src/gdb-elf-7.6.50-2/libiberty'
make[2]: Entering directory `/usr/src/gdb-elf-7.6.50-2/intl'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/usr/src/gdb-elf-7.6.50-2/intl'
make[2]: Entering directory `/usr/src/gdb-elf-7.6.50-2/bfd'
Making info in doc
make[3]: Entering directory `/usr/src/gdb-elf-7.6.50-2/bfd/doc'
make[3]: Nothing to be done for `info'.
make[3]: Leaving directory `/usr/src/gdb-elf-7.6.50-2/bfd/doc'
Making info in po
make[3]: Entering directory `/usr/src/gdb-elf-7.6.50-2/bfd/po'
make[3]: Nothing to be done for `info'.
make[3]: Leaving directory `/usr/src/gdb-elf-7.6.50-2/bfd/po'
make[3]: Entering directory `/usr/src/gdb-elf-7.6.50-2/bfd'
make[3]: Nothing to be done for `info-am'.
make[3]: Leaving directory `/usr/src/gdb-elf-7.6.50-2/bfd'
make  all-recursive
make[3]: Entering directory `/usr/src/gdb-elf-7.6.50-2/bfd'
Making all in doc
make[4]: Entering directory `/usr/src/gdb-elf-7.6.50-2/bfd/doc'
make[4]: Nothing to be done for `all'.
make[4]: Leaving directory `/usr/src/gdb-elf-7.6.50-2/bfd/doc'
Making all in po
make[4]: Entering directory `/usr/src/gdb-elf-7.6.50-2/bfd/po'
file=`echo ../../../gdb-7.6.50-2/bfd/po/da | sed 's,.*/,,'`.gmo \
  && rm -f $file && PATH=../src:$PATH : -o $file
../../../gdb-7.6.50-2/bfd/po/da.po
file=`echo ../../../gdb-7.6.50-2/bfd/po/es | sed 's,.*/,,'`.gmo \
  && rm -f $file && PATH=../src:$PATH : -o $file
../../../gdb-7.6.50-2/bfd/po/es.po
file=`echo ../../../gdb-7.6.50-2/bfd/po/fr | sed 's,.*/,,'`.gmo \
  && rm -f $file && PATH=../src:$PATH : -o $file
../../../gdb-7.6.50-2/bfd/po/fr.po
file=`echo ../../../gdb-7.6.50-2/bfd/po/ja | sed 's,.*/,,'`.gmo \
  && rm -f $file && PATH=../src:$PATH : -o $file
../../../gdb-7.6.50-2/bfd/po/ja.po
file=`echo ../../../gdb-7.6.50-2/bfd/po/vi | sed 's,.*/,,'`.gmo \
  && rm -f $file && PATH=../src:$PATH : -o $file
../../../gdb-7.6.50-2/bfd/po/vi.po
file=`echo ../../../gdb-7.6.50-2/bfd/po/zh_CN | sed 's,.*/,,'`.gmo \
  && rm -f $file && PATH=../src:$PATH : -o $file
../../../gdb-7.6.50-2/bfd/po/zh_CN.po
file=`echo ../../../gdb-7.6.50-2/bfd/po/fi | sed 's,.*/,,'`.gmo \
  && rm -f $file && PATH=../src:$PATH : -o $file
../../../gdb-7.6.50-2/bfd/po/fi.po
file=`echo ../../../gdb-7.6.50-2/bfd/po/id | sed 's,.*/,,'`.gmo \
  && rm -f $file && PATH=../src:$PATH : -o $file
../../../gdb-7.6.50-2/bfd/po/id.po
file=`echo ../../../gdb-7.6.50-2/bfd/po/ru | sed 's,.*/,,'`.gmo \
  && rm -f $file && PATH=../src:$PATH : -o $file
../../../gdb-7.6.50-2/bfd/po/ru.po
file=`echo ../../../gdb-7.6.50-2/bfd/po/uk | sed 's,.*/,,'`.gmo \
  && rm -f $file && PATH=../src:$PATH : -o $file
../../../gdb-7.6.50-2/bfd/po/uk.po
make[4]: Leaving directory `/usr/src/gdb-elf-7.6.50-2/bfd/po'
make[4]: Entering directory `/usr/src/gdb-elf-7.6.50-2/bfd'
make[4]: Leaving directory `/usr/src/gdb-elf-7.6.50-2/bfd'
make[3]: Leaving directory `/usr/src/gdb-elf-7.6.50-2/bfd'
make[2]: Leaving directory `/usr/src/gdb-elf-7.6.50-2/bfd'
make[2]: Entering directory `/usr/src/gdb-elf-7.6.50-2/opcodes'
make  all-recursive
make[3]: Entering directory `/usr/src/gdb-elf-7.6.50-2/opcodes'
Making all in .
make[4]: Entering directory `/usr/src/gdb-elf-7.6.50-2/opcodes'
make[4]: Leaving directory `/usr/src/gdb-elf-7.6.50-2/opcodes'
Making all in po
make[4]: Entering directory `/usr/src/gdb-elf-7.6.50-2/opcodes/po'
file=`echo ../../../gdb-7.6.50-2/opcodes/po/da | sed 's,.*/,,'`.gmo \
  && rm -f $file && PATH=../src:$PATH : -o $file
../../../gdb-7.6.50-2/opcodes/po/da.po
file=`echo ../../../gdb-7.6.50-2/opcodes/po/es | sed 's,.*/,,'`.gmo \
  && rm -f $file && PATH=../src:$PATH : -o $file
../../../gdb-7.6.50-2/opcodes/po/es.po
file=`echo ../../../gdb-7.6.50-2/opcodes/po/fi | sed 's,.*/,,'`.gmo \
  && rm -f $file && PATH=../src:$PATH : -o $file
../../../gdb-7.6.50-2/opcodes/po/fi.po
file=`echo ../../../gdb-7.6.50-2/opcodes/po/fr | sed 's,.*/,,'`.gmo \
  && rm -f $file && PATH=../src:$PATH : -o $file
../../../gdb-7.6.50-2/opcodes/po/fr.po
file=`echo ../../../gdb-7.6.50-2/opcodes/po/ga | sed 's,.*/,,'`.gmo \
  && rm -f $file && PATH=../src:$PATH : -o $file
../../../gdb-7.6.50-2/opcodes/po/ga.po
file=`echo ../../../gdb-7.6.50-2/opcodes/po/id | sed 's,.*/,,'`.gmo \
  && rm -f $file && PATH=../src:$PATH : -o $file
../../../gdb-7.6.50-2/opcodes/po/id.po
file=`echo ../../../gdb-7.6.50-2/opcodes/po/nl | sed 's,.*/,,'`.gmo \
  && rm -f $file && PATH=../src:$PATH : -o $file
../../../gdb-7.6.50-2/opcodes/po/nl.po
file=`echo ../../../gdb-7.6.50-2/opcodes/po/vi | sed 's,.*/,,'`.gmo \
  && rm -f $file && PATH=../src:$PATH : -o $file
../../../gdb-7.6.50-2/opcodes/po/vi.po
file=`echo ../../../gdb-7.6.50-2/opcodes/po/zh_CN | sed 's,.*/,,'`.gmo \
  && rm -f $file && PATH=../src:$PATH : -o $file
../../../gdb-7.6.50-2/opcodes/po/zh_CN.po
file=`echo ../../../gdb-7.6.50-2/opcodes/po/it | sed 's,.*/,,'`.gmo \
  && rm -f $file && PATH=../src:$PATH : -o $file
../../../gdb-7.6.50-2/opcodes/po/it.po
file=`echo ../../../gdb-7.6.50-2/opcodes/po/uk | sed 's,.*/,,'`.gmo \
  && rm -f $file && PATH=../src:$PATH : -o $file
../../../gdb-7.6.50-2/opcodes/po/uk.po
make[4]: Leaving directory `/usr/src/gdb-elf-7.6.50-2/opcodes/po'
make[3]: Leaving directory `/usr/src/gdb-elf-7.6.50-2/opcodes'
make[2]: Leaving directory `/usr/src/gdb-elf-7.6.50-2/opcodes'
make[2]: Entering directory `/usr/src/gdb-elf-7.6.50-2/etc'
for f in standards.info configure.info; do \
  if test -f ../../gdb-7.6.50-2/etc/`echo $f | sed -e 's/.info$/.texi/'`;
then \
    if make "MAKEINFO=makeinfo --split-size=5000000 --split-size=5000000"
$f; then \
      true; \
    else \
      exit 1; \
    fi; \
  fi; \
done
make[3]: Entering directory `/usr/src/gdb-elf-7.6.50-2/etc'
make[3]: `standards.info' is up to date.
make[3]: Leaving directory `/usr/src/gdb-elf-7.6.50-2/etc'
make[3]: Entering directory `/usr/src/gdb-elf-7.6.50-2/etc'
make[3]: `configure.info' is up to date.
make[3]: Leaving directory `/usr/src/gdb-elf-7.6.50-2/etc'
make[2]: Leaving directory `/usr/src/gdb-elf-7.6.50-2/etc'
make[2]: Entering directory `/usr/src/gdb-elf-7.6.50-2/libdecnumber'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/usr/src/gdb-elf-7.6.50-2/libdecnumber'
make[2]: Entering directory `/usr/src/gdb-elf-7.6.50-2/readline'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/usr/src/gdb-elf-7.6.50-2/readline'
make[2]: Entering directory `/usr/src/gdb-elf-7.6.50-2/gdb'
make[3]: Entering directory `/usr/src/gdb-elf-7.6.50-2/gdb'
make[4]: Entering directory `/usr/src/gdb-elf-7.6.50-2/gdb/build-gnulib'
make[5]: Entering directory `/usr/src/gdb-elf-7.6.50-2/gdb/build-gnulib'
make[6]: Entering directory
`/usr/src/gdb-elf-7.6.50-2/gdb/build-gnulib/import'
make  all-recursive
make[7]: Entering directory
`/usr/src/gdb-elf-7.6.50-2/gdb/build-gnulib/import'
make[8]: Entering directory
`/usr/src/gdb-elf-7.6.50-2/gdb/build-gnulib/import'
make[8]: Nothing to be done for `all-am'.
make[8]: Leaving directory
`/usr/src/gdb-elf-7.6.50-2/gdb/build-gnulib/import'
make[7]: Leaving directory
`/usr/src/gdb-elf-7.6.50-2/gdb/build-gnulib/import'
make[6]: Leaving directory
`/usr/src/gdb-elf-7.6.50-2/gdb/build-gnulib/import'
make[5]: Leaving directory `/usr/src/gdb-elf-7.6.50-2/gdb/build-gnulib'
make[4]: Leaving directory `/usr/src/gdb-elf-7.6.50-2/gdb/build-gnulib'
make[3]: Leaving directory `/usr/src/gdb-elf-7.6.50-2/gdb'
gcc -g -O2    -I. -I../../gdb-7.6.50-2/gdb -I../../gdb-7.6.50-2/gdb/common
-I../../gdb-7.6.50-2/gdb/config 
-DLOCALEDIR="\"/usr/local/i386/share/locale\"" -DHAVE_CONFIG_H
-I../../gdb-7.6.50-2/gdb/../include/opcode
-I../../gdb-7.6.50-2/gdb/../opcodes/..
-I../../gdb-7.6.50-2/gdb/../readline/..  -I../bfd
-I../../gdb-7.6.50-2/gdb/../bfd -I../../gdb-7.6.50-2/gdb/../include
-I../libdecnumber -I../../gdb-7.6.50-2/gdb/../libdecnumber  
-I../../gdb-7.6.50-2/gdb/gnulib/import -Ibuild-gnulib/import   -DTUI=1 
-I/usr/include/python2.7 -I/usr/include/python2.7 -Wall
-Wdeclaration-after-statement -Wpointer-arith -Wformat-nonliteral
-Wno-unused -Wunused-value -Wunused-function -Wno-switch
-Wno-char-subscripts -Wmissing-prototypes -Wdeclaration-after-statement
-Werror -c -o gdb.o -MT gdb.o -MMD -MP  -MF .deps/gdb.Tpo
../../gdb-7.6.50-2/gdb/gdb.c
In file included from ../../gdb-7.6.50-2/gdb/defs.h:803,
                 from ../../gdb-7.6.50-2/gdb/gdb.c:19:
../../gdb-7.6.50-2/gdb/utils.h:283: warning: parameter has incomplete type
Makefile:979: recipe for target `gdb.o' failed
make[2]: *** [gdb.o] Error 1
make[2]: Leaving directory `/usr/src/gdb-elf-7.6.50-2/gdb'
Makefile:8261: recipe for target `all-gdb' failed
make[1]: *** [all-gdb] Error 2
make[1]: Leaving directory `/usr/src/gdb-elf-7.6.50-2'
Makefile:831: recipe for target `all' failed
make: *** [all] Error 2





--
View this message in context: http://sourceware-org.1504.n7.nabble.com/Why-gdb-fail-to-make-tp231905.html
Sent from the Sourceware - gdb list mailing list archive at Nabble.com.

[patch]: testsuite: run bash instead of sh when using brace expansion

Christian Groessler — 2013-05-15T10:38:14

Hi,

I had some testsuite failures in gdb.dwarf2/dw2-dir-file-name.exp, 
because /bin/sh on my system doesn't support brace expansion.
I'm using Debian, where /bin/sh is in fact dash. I tried /bin/sh on 
Solaris (9), too, and it also doesn't support brace expansion.

This patch changes dw2-dir-file-name.exp to use bash instead of sh.

Ok to commit?

regards,
chris



gdb/testsuite:
2013-05-15  Christian Groessler <chris< at >groessler.org>

        * gdb.dwarf2/dw2-dir-file-name.exp: Use bash instead of sh, since
        brace expansion is not available in sh.



Index: gdb.dwarf2/dw2-dir-file-name.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp,v
retrieving revision 1.4
diff -u -p -r1.4 dw2-dir-file-name.exp
--- gdb.dwarf2/dw2-dir-file-name.exp    15 Mar 2013 01:41:28 -0000      1.4
+++ gdb.dwarf2/dw2-dir-file-name.exp    15 May 2013 10:27:20 -0000
< at >< at > -322,10 +322,10 < at >< at > if { [gdb_compile "${asmsrcfile} ${srcdi
      return -1
  }

-remote_exec host "sh -c \"rm -f 
${srcabsdir}{/rdir,}{/xdir,}{/compdir,}{/ldir,}{/fdir,}/${srctmpfile}\""
-remote_exec host "sh -c \"rmdir 
${srcabsdir}{/rdir,}{/xdir,}{/compdir,}{/ldir,}{/fdir,}\""
-remote_exec host "sh -c \"mkdir 
${srcabsdir}{,/rdir}{,/xdir}{,/compdir}{,/ldir}{,/fdir}\""
-remote_exec host "sh -c \"for d in 
${srcabsdir}{,/rdir}{,/xdir}{,/compdir}{,/ldir}{,/fdir};do cp 
${srcdir}/${subdir}/${srcfile} \\\$d/${srctmpfile}; done\""
+remote_exec host "bash -c \"rm -f 
${srcabsdir}{/rdir,}{/xdir,}{/compdir,}{/ldir,}{/fdir,}/${srctmpfile}\""
+remote_exec host "bash -c \"rmdir 
${srcabsdir}{/rdir,}{/xdir,}{/compdir,}{/ldir,}{/fdir,}\""
+remote_exec host "bash -c \"mkdir 
${srcabsdir}{,/rdir}{,/xdir}{,/compdir}{,/ldir}{,/fdir}\""
+remote_exec host "bash -c \"for d in 
${srcabsdir}{,/rdir}{,/xdir}{,/compdir}{,/ldir}{,/fdir};do cp 
${srcdir}/${subdir}/${srcfile} \\\$d/${srctmpfile}; done\""

  clean_restart ${testfile}

GNU Tools Cauldron 2013 - An update on presentations

Diego Novillo — 2013-05-09T15:16:24

An update on this year's Cauldron.  We are getting close to the
limit on the presentations and BoFs, so if you are interested in
organizing a BoF or giving a presentation, please send us an
abstract soon.

We will still accept presentations and/or BoFs on-site the first
day of the workshop.  However, those will likely need to run in
parallel with the existing sessions.

We still do not have a formal schedule, but we are expecting to
have 3 pretty full days, starting on Fri 12/Jul.  I will send
details on the schedule as soon as we finalize it.

Please visit the wiki for more info http://gcc.gnu.org/wiki/cauldron2013


Diego.

A Question On GDB?

Thomas Dineen — 2013-05-08T19:57:32

Gentle People:

    I normally use GDB to find Segmentation Fault bugs such as
an uninitialized pointer. Usually I just use the "r" command and
the program runs until it crashes with GDB displaying the source
code file name and line number!

    But in the case shown below GDB dose NOT give me this
this useful information?

     Now the question: How can I find the crash point in the code?

Thanks for the help
Thomas Dineen

Sun5# gdb --args TA_Bench.sun
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-pc-solaris2.10"...
(gdb) r
Starting program: 
/net/Dineen-Linux4/home/tdineen/Projects/TA_Bench/TA_Bench.sun

warning: Lowest section in /lib/libpthread.so.1 is .dynamic at 00000074
warning: Lowest section in /lib/libthread.so.1 is .dynamic at 00000074
[New LWP 1]
[New LWP 2]
[LWP 2 exited]
[New LWP 2]
Screen Maximum Size: Width 1920 Height 1200

Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
(gdb)

Can GDB be used to print values of allocatable arrays of a derived type in Fortran 90?

Neal Kruis — 2013-05-08T19:53:47

GDB users,

I just posted this question to Stack Overflow:

http://stackoverflow.com/questions/16447741/can-gdb-be-used-to-print-values-of-allocatable-arrays-of-a-derived-type-in-fortr

I have the following data structure in a Fortran90 program:

TYPE derivedType
  CHARACTER(100)     :: name      = ' '
  INTEGER            :: type      = 0
  REAL(KIND(1.0D0))  :: property  = 0.0
END TYPE derivedType

TYPE (derivedType), ALLOCATABLE, DIMENSION(:) :: arrayOfDerivedTypes

When I try to debug and print values in GDB like:

(gdb) p arrayOfDerivedTypes(1)%name

I get non-sensical values (often stings of zeros, forward slashes and
letters), or completely wrong values (like arrayOfDerivedTypes(1)%name
= 9, when I know that it is = 2). How can I get GDB to print the
correct values?

Background

I am aware of:

this bug: http://sourceware.org/bugzilla/show_bug.cgi?id=9395
this branch of GDB: http://sourceware.org/gdb/wiki/ProjectArcher
and this blog post on printing allocatable arrays:
http://numericalnoob.blogspot.be/2012/08/fortran-allocatable-arrays-and-pointers.html

I don't want to go through the trouble of compiling a separate branch
of GDB to test if it solves this problem if someone already knows that
it won't or if there is a better solution available.

Please let me know (either here or on Stack Overflow) if you have any
suggestions.

Neal Kruis
Big Ladder Software
http://www.bigladdersoftware.com

Support for Overlays in target dependent code

Tejas Chopra — 2013-05-08T02:35:22

Hi,

I am working on Xtensa architecture (gdb-7.*/gdb/xtensa-tdep.c). I wish 
to add overlay support for Xtensa. Seeing other similar architectures, I 
believe the only addition required for overlay support to seamlessly 
work (assuming no other changes in other target dependent code) would be:

set_gdbarch_overlay_update (gdbarch, simple_overlay_update);

in <target>_gdbarch_init(), just as is the case with regards to ARM and 
MIPS.

Is anything else required too?

Thanks!
Tejas

Debugging agent library

Suchakra Sharma — 2013-05-06T19:21:14

Hi,

We tried to find out how to use the debugging agent library here [1] but
were unsuccessful. As of now, we have built a test app linked to dagent
which creates a socket file and expects commands. We wish to use it with
GDB as well as other applications to primarily objective of tracing
using GDB's fast tracepoint infra. Any help in this regard will be
appreciated. 

[1] https://github.com/MentorEmbedded/Debug-Agent-Library/wiki

Regards,
Suchakra & Simon

--
Suchakrapani Datt Sharma
Laboratorie DORSAL
École Polytechnique de Montréal

Timer

Marc Brünink — 2013-05-06T09:52:33

I want to execute a piece of code at regular intervals. Actually I'm sampling $pc.
(let's not go into detail why I use gdb)

My current solution just starts another process that sends a SIGTRAP to the debugged application. Using a simple script I can print the $pc.

However, I just realised that this approach does not work too well. If gdb is stopped due to a breakpoint it will interpret the received SIGTRAP as another hit of the very same breakpoint. 

Reproduce:
1. Attach to any program
2. Create any breakpoint
3. Wait until breakpoint is hit
4. Send SIGTRAP to debugged application
5. continue

Actually, now that I think about it, I should have anticipated this behaviour.
Is there a better way to execute a piece of code at regular intervals? 


Marc

gdb.arch vs. gdb.base gcore test cases

Andreas Arnez — 2013-05-03T11:15:08

The following two test cases are mostly identical, and their associated
C source files are exactly identical:

    gdb.arch/system-gcore.exp
    gdb.base/gcore.exp

Is there any specific reason for the two copies?  Just curious...

Cleanups and Exception handlers

Phil Muldoon — 2013-05-01T10:28:07

I'd like to quantify and discuss strategies of cleanups and GDB exception
handlers.  It seems I am always making mistakes in this area, and the
comments in the TRY_CATCH macro (well to me) are not adequate about the
mechanics of cleanups in an exception handler.

So I would like to discuss patterns of usage with a view to updating
the comments to be more explanatory.

Take this example, something that caught me out recently:

  struct cleanups cleanups;

  cleanups = make_cleanup (xfree, foo);

  TRY_CATCH (except, RETURN_MASK_ALL)
    {
      make_cleanup_ui_out_tuple_begin_end (out, NULL);
      ...
      // Do some other stuff
    }
  if (except.reason < 0)
    {
      // Some exception handling code
    }

  do_cleanups (cleanups);

It seems if you create a cleanup in an exception handler, even if the
old cleanup chain is saved before the exception handler starts, you
have to call do_cleanups() in the exception handler or the cleanup is
lost. It seems that the TRY_CATCH code is manipulating the cleanup
chain,  but I can't find any comments on why it does this, or how that
affects your own cleanup chain.  What happens if you discard cleanups
in an exception handler to a point where the cleanup was registered
before the exception handler started?

In the above example, assuming everything went OK in above, and no
calls produced an error() or some other call, when I call
do_cleanups() in that code, my "tuple" cleanup seems to have been
discarded.  (I know this as in my code, I rapidly encounter
ui_out->level > MAX_UI_OUT_LEVELS as the tuples were never closed in
the cleanups.

Question 1)

What is the rule regarding cleanup chains that were created outside of
an exception handler, but where additional cleanups were registered
and not processed (cleanedup) inside the exception handler.

Question 2)

If in the above example, something goes wrong, does one have to call
do_cleanups() in the exception handling block (IE if (except.reason <
0))

Example 2:


  TRY_CATCH (except, RETURN_MASK_ALL)
  {
    struct cleanups cleanups =
      make_cleanup_ui_out_tuple_begin_end (out, NULL);
      ...
      // Do some other stuff
    do_cleanups (cleanups);
    }
  if (except.reason < 0)
    {
      // Some exception handling code
    }

In this example we create a pointer to the cleanup chain, and perform
a tuple cleanup.  If I call do_cleanups() in this example (assuming
nothing went wrong in the TRY_CATCH block), the tuple is cleaned up
properly.  But what happens if something happens and the exception
handling "if" is called.

Question 3)

For cleanups created and registered exclusively in the TRY_CATCH
block, on some exception being raised are they cleaned up
automatically?  (As there is no scope for the exception handling
failure code to do cleanups).

This all came about as MI tuples tend to be "long lived" cleanups and
in Python we have to handle every potential GDB exception call in an
exception handler to prevent propagation upwards.  I found this leads
to giant TRY_CATCH calls that encompass tuple creation, tuple
population, and tuple closure. But I am not sure.

Cheers,

Phil

A little help with JIT support

Rouslan Korneychuk — 2013-04-30T23:05:01

I wanted to use GDB's JIT support feature in a JIT compiler I'm working on. This requires creating an object file, so I read the ELF and DWARF 4 specifications, and implemented the JIT data structures from the GDB manual. It all seems to be working except for one thing. The addresses used in the object file are supposed to be position independent "virtual" addresses, meaning they don't represent the final positions in memory. So my first function is at "address" 0, but GDB is treating these as absolute addresses. For example: if I try to use the "disassemble" command on my function, it tries to read from address 0 (which of course causes an error).

Are the addresses in an in-memory object file supposed to be absolute addresses? I figure I'm just missing something. Although using absolute addresses would work either way, I would prefer to know the proper way, so I would know how to create executable and dynamic library files. I looked at the information that GCC generates for object files, but it generates too much information for me to guess what mine is missing.


I'm using GDB 7.3.1

Here is an example of what I get when I run "readelf -hS" on my object file:

ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              REL (Relocatable file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          0 (bytes into file)
  Start of section headers:          4464 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           0 (bytes)
  Number of program headers:         0
  Size of section headers:           64 (bytes)
  Number of section headers:         8
  Section header string table index: 7

Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
  [ 0]                   NULL             0000000000000000  00000000
       0000000000000000  0000000000000000           0     0     0
  [ 1] .text             PROGBITS         0000000000000000  00000050
       0000000000000fe0  0000000000000000  AX       0     0     16
  [ 2] .symtab           SYMTAB           0000000000000000  00001030
       0000000000000060  0000000000000018           3     4     0
  [ 3] .strtab           STRTAB           0000000000000000  00001090
       0000000000000018  0000000000000000           0     0     0
  [ 4] .debug_info       PROGBITS         0000000000000000  000010a8
       0000000000000054  0000000000000000           0     0     0
  [ 5] .debug_abbrev     PROGBITS         0000000000000000  000010fc
       000000000000001b  0000000000000000           0     0     0
  [ 6] .debug_str        PROGBITS         0000000000000000  00001117
       0000000000000011  0000000000000000           0     0     0
  [ 7] .shstrtab         STRTAB           0000000000000000  00001128
       0000000000000046  0000000000000000           0     0     0
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), l (large)
  I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)


And if I run "objdump -W"

file format elf64-x86-64

Contents of the .debug_info section:

  Compilation Unit < at > offset 0x0:
   Length:        0x48 (32-bit)
   Version:       4
   Abbrev Offset: 0
   Pointer Size:  8
 <0><17>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <18>   DW_AT_use_UTF8    : 1    
 <1><18>: Abbrev Number: 2 (DW_TAG_subprogram)
    <19>   DW_AT_name        : (indirect string, offset: 0x0): $module$    
    <21>   DW_AT_high_pc     : 2051    
    <23>   DW_AT_low_pc      : 0x0    
 <1><2b>: Abbrev Number: 2 (DW_TAG_subprogram)
    <2c>   DW_AT_name        : (indirect string, offset: 0x9): gentest    
    <34>   DW_AT_high_pc     : 1650    
    <36>   DW_AT_low_pc      : 0x810    
 <1><3e>: Abbrev Number: 3 (DW_TAG_subprogram)
    <3f>   DW_AT_high_pc     : 287    
    <41>   DW_AT_low_pc      : 0xe90    
 <1><49>: Abbrev Number: 3 (DW_TAG_subprogram)
    <4a>   DW_AT_high_pc     : 48    
    <4b>   DW_AT_low_pc      : 0xfb0    

Contents of the .debug_abbrev section:

  Number TAG
   1      DW_TAG_compile_unit    [has children]
    DW_AT_use_UTF8     DW_FORM_flag_present
   2      DW_TAG_subprogram    [no children]
    DW_AT_name         DW_FORM_strp
    DW_AT_high_pc      DW_FORM_udata
    DW_AT_low_pc       DW_FORM_addr
   3      DW_TAG_subprogram    [no children]
    DW_AT_high_pc      DW_FORM_udata
    DW_AT_low_pc       DW_FORM_addr

Contents of the .debug_str section:

  0x00000000 246d6f64 756c6524 0067656e 74657374 $module$.gentest
  0x00000010 00                                  .

Visualize in memory OpenCV image or matrix from GDB pretty printers

asmwarrior — 2013-04-30T08:49:56

Hi, I'm pleased to share the script to show an in memory cv::Mat or Images when debugging.
Suppose you have such C++ code:

#include <opencv/cv.h>
#include <opencv/highgui.h>
using namespace cv; 
...
Mat img = imread("1.jpg", CV_LOAD_IMAGE_GRAYSCALE);
...

When debugging those code under GDB, I would like to see how the in memory data "img" looks like. Thanks to GDB and OpenCV, both of them have Python interface, so here is the python pretty script (I released the script code under GPLv3)

Before that, you need 
1, GDB with python enabled
2, OpenCV python interface (under Windows, it is one file cv2.pyd)
3, install python, numpy

############################################################
#filename: cvplot.py
import gdb
import cv2.cv as cv
import sys


class PlotterCommand(gdb.Command):
    def __init__(self):
        super(PlotterCommand, self).__init__("plot",
                                             gdb.COMMAND_DATA,
                                             gdb.COMPLETE_SYMBOL)
    def invoke(self, arg, from_tty):
        args = gdb.string_to_argv(arg)
        
        
        # generally, we type "plot someimage" in the GDB commandline
        # where "someimage" is an instance of cv::Mat
        v = gdb.parse_and_eval(args[0])
        
        # the value v is a gdb.Value object of C++
        # code's cv::Mat, we need to translate to
        # a python object under cv2.cv
        image_size =  (v['cols'],v['rows'])
        # print v
        # these two below lines do not work. I don't know why
        # channel = gdb.execute("call "+ args[0] + ".channels()", False, True)
        # channel = v.channels();
        CV_8U =0
        CV_8S =1
        CV_16U=2
        CV_16S=3
        CV_32S=4
        CV_32F=5
        CV_64F=6
        CV_USRTYPE1=7
        CV_CN_MAX = 512
        CV_CN_SHIFT = 3
        CV_MAT_CN_MASK = (CV_CN_MAX - 1) << CV_CN_SHIFT
        flags = v['flags']
        channel = (((flags) & CV_MAT_CN_MASK) >> CV_CN_SHIFT) + 1
        CV_DEPTH_MAX = (1 << CV_CN_SHIFT)
        CV_MAT_DEPTH_MASK = CV_DEPTH_MAX - 1
        depth = (flags) & CV_MAT_DEPTH_MASK
        IPL_DEPTH_SIGN = 0x80000000
        cv_elem_size = (((4<<28)|0x8442211) >> depth*4) & 15
        if (depth == CV_8S or depth == CV_16S or depth == CV_32S):
                mask = IPL_DEPTH_SIGN
        else:
                mask = 0
        ipl_depth = cv_elem_size*8 | mask     
        img = cv.CreateImageHeader(image_size, ipl_depth, channel)
        
        # conver the v['data'] type to "char*" type
        char_type = gdb.lookup_type("char")
        char_pointer_type =char_type.pointer()
        buffer = v['data'].cast(char_pointer_type)
        
        # read bytes from inferior's memory, because
        # we run the opencv-python module in GDB's own process
        # otherwise, we use memory corss processes        
        buf = v['step']['buf']
        bytes = buf[0] * v['rows'] # buf[0] is the step? Not quite sure.
        inferior = gdb.selected_inferior()
        mem = inferior.read_memory(buffer, bytes)
        
        # set the img's raw data
        cv.SetData(img, mem)
        
        # create a window, and show the image
        cv.NamedWindow('debugger')
        cv.ShowImage('debugger', img)
        
        # the below statement is necessory, otherwise, the Window
        # will hang
        cv.WaitKey(0) 
        
PlotterCommand()
############################################################
The script above add a new GDB command "plot" to show the in memory data cv::Mat.
Now, you can simply type: "source cvplot.py" to load this script to GDB, then type: "plot img" to show the cv::Mat in OpenCV's Window, to let GDB continue, just close the debugger window.

BTW: I found one issue, if I uncomment "# print v" in the script source, then this script will complain such message and abort:
Python Exception <type 'exceptions.UnicodeEncodeError'> 'ascii' codec can't encode characters in position 80-100: ordinal not in range(128): 
Error occurred in Python command: 'ascii' codec can't encode characters in position 80-100: ordinal not in range(128)

But if I run the command "print img" directly in the GDB's command line, it shows:
$2 = {flags = 1124024320, dims = 2, rows = 243, cols = 322, data = 0xb85020 "\370\362趔貅鲵篝躜貘篚赧鲶篥躐篝趔篝趔趑趑趑趑蝓趔\372\357豸趑趑趑趑趑趑趑趑趑趱貂趑趑趔篝趑篌趑趑趑趔篌篌篝貂趑篝趱鲺豸趑趔篝趑趔篝篝趱趑趑鲴蝥铛鲳豸趑趑趑趑趑趑趑貂趑趑貂蝮趱貂趑篚躞篚豸貂趑趑趑趑趑篌趑趱豸篌貊"..., refcount = 0xb981c8, datastart = 0xb85020 "\370\362趔貅鲵篝躜貘篚赧鲶篥躐篝趔篝趔趑趑趑趑蝓趔\372\357豸趑趑趑趑趑趑趑趑趑趱貂趑趑趔篝趑篌趑趑趑趔篌篌篝貂趑篝趱鲺豸趑趔篝趑趔篝篝趱趑趑鲴蝥铛鲳豸趑趑趑趑趑趑趑貂趑趑貂蝮趱貂趑篚躞篚豸貂趑趑趑趑趑篌趑趱豸篌貊"..., dataend = 0xb981c6 "\255\272\001", datalimit = 0
 xb981c6 "\255\272\001", allocator = 0x0, size = {p = 0x22fe64}, step = {p = 0x22fe8c, buf = {322, 1}}}

I'm not sure how to fix this, but surely I can see it was some issue that python try to decode the raw buffer to normal text. (I'm using WinXP)

Many thanks to Tromey, Andre_, Pmuldoon for their kind help in GDB IRC, also thanks to Hui Ning(ninghui8673< at >126.com) for great help and suggestion.

Yuanhui Zhang

About adding new script language

Nala Ginrut — 2013-04-30T07:49:02

Hi GDB folks!
I'm new comer here, and I'm trying to make guile the extension language.
Anyway, folks could use python as well, before guile has reliable python
front-end.
I've read the python part, here're some ideas, correct me if I'm wrong
please. ;-)

1. Is it necessary to use language_defn to define the extension
language?
My understanding is language_defn defines a new language support for
debugging the defined language, not to define a new extension language
for other debugging purpose. Or not?
For example, go-lang.c is the support for debugging go, not add go as
the debug script language, just like python. But it confused me that
python has used language_defn.

2. There should be interfaces to add the script language, but I didn't
find it, anyone point me out? I don't think I have to write new
lexer/parser for that, just need a way to get the expr and call guile's
read function. Thanks!

3. My aim is not only add guile as an extension in gdb's REPL, but a
more powerful language for the automatic debugging. For that purpose,
the hard/heavy work is not to add guile into gdb, but a framework
project implemented by guile based on the support of guile-gdb. 
Is this idea too unrealistic?

Happy hacking!
Thanks!

GDB fast tracepoint query

Suchakrapani Datt Sharma — 2013-04-29T19:27:24

Hi,

I am trying to do some performance analysis of various dynamic
instrumentation/tracing tools. I started with simple overhead analysis of my
'dummy' test program when traced with fast tracepoints using gdb. If I do not
provide 'actions' after setting a tracepoint, will gdb still pass through the
tracepoint and induce some overhead or its just the same as *not* setting the
fast tracepoint and running a clean test? Is the first instruction at the
tracepoint on foo() modified immediately upon setting the tracepoint using
'ftrace foo'?

Regards,
Suchakra

--
Suchakrapani Datt Sharma
Laboratorie DORSAL
École Polytechnique de Montréal

[Documentation] Broken link - 404 Not found

Simeon S — 2013-04-28T17:50:51

Hi guys,

There seems to be a broken link in the documentation. In section 4.1
Compilation for Debugging, the "Options for Debugging..." link seems
to be broken:

http://sourceware.org/gdb/current/onlinedocs/gcc/Debugging-Options.html#Debugging-Options


Simeon

[ANNOUNCEMENT] GDB 7.6 released!

Joel Brobecker — 2013-04-26T14:07:41

            GDB 7.6 released!

Release 7.6 of GDB, the GNU Debugger, is now available via anonymous
FTP.  GDB is a source-level debugger for Ada, C, C++, Objective-C,
Pascal and many other languages.  GDB can target (i.e., debug programs
running on) more than a dozen different processor architectures, and GDB
itself can run on most popular GNU/Linux, Unix and Microsoft Windows
variants.

You can download GDB from the GNU FTP server in the directory:

        ftp://ftp.gnu.org/gnu/gdb

The vital stats:

  Size  md5sum                            Name
  24MB  fda57170e4d11cdde74259ca575412a8  gdb-7.6.tar.bz2
  30MB  a9836707337e5f7bf76a009a8904f470  gdb-7.6.tar.gz

There is a web page for GDB at:

        http://www.gnu.org/software/gdb/

That page includes information about GDB mailing lists (an announcement
mailing list, developers discussion lists, etc.), details on how to
access GDB's CVS repository, locations for development snapshots,
preformatted documentation, and links to related information around
the net.  We will put errata notes and host-specific tips for this release
on-line as any problems come up.  All mailing lists archives are also
browsable via the web.

GDB 7.6 brings new targets, features and improvements, including:

  * New native configurations:

    ARM AArch64 GNU/Linux           aarch64*-*-linux-gnu
    FreeBSD/powerpc                 powerpc*-*-freebsd
    x86_64/Cygwin                   x86_64-*-cygwin*
    Tilera TILE-Gx GNU/Linux        tilegx*-*-linux-gnu

  * New target configurations:

    ARM AArch64                     aarch64*-*-elf
    ARM AArch64 GNU/Linux           aarch64*-*-linux
    Lynx 178 PowerPC                powerpc-*-lynx*178
    x86_64/Cygwin                   x86_64-*-cygwin*
    Tilera TILE-Gx GNU/Linux        tilegx*-*-linux

  * New configure options: -enable-libmcheck/--disable-libmcheck

  * Support for the "mini debuginfo" section, .gnu_debugdata

  * The C++ ABI now defaults to the GNU v3 ABI.  This has been the
    default for GCC since November 2000.

  * New command line option: -nh (disables auto-loading of ~/.gdbinit)

  * Various GDB/MI changes

  * Python scripting:

    ** Vectors can be created with gdb.Type.vector.
    ** Python's atexit.register now works in GDB.
    ** Types can be pretty-printed via a Python API.
    ** Python 3 is now supported (in addition to Python 2.4 or later)
    ** New class gdb.Architecture exposes GDB's internal representation
       of architecture in the Python API.
    ** New method Frame.architecture returns the gdb.Architecture object
       corresponding to the frame's architecture.
    ** New Python-based convenience functions ($_memeq, $_streq,
       $_strlen and $_regex)

  * The 'cd' command now defaults to using '~' (the home directory) if
    not given an argument.

  * New commands:
    ** catch signal
    ** maint info bfds
    ** python-interactive
    ** enable/disable type-printer

  * New remote packets (QTBuffer:size, Qbtrace:bts, Qbtrace:off and
    qXfer:btrace:read)

  * New options:
    ** set/show print type methods (on|off)
    ** set/show print type typedefs (on|off)
    ** set/show filename-display basename|relative|absolute
    ** set/show trace-buffer-size
    ** set/show remote trace-buffer-size-packet auto|on|off
    ** set/show debug aarch64
    ** set/show debug coff-pe-read
    ** set/show debug mach-o
    ** set/show debug notification

  * target record:

    The "target record" command has been renamed to "target record-full",
    and a new "target record-btrace" has been added.  This new target
    uses hardward support to record the control-flow of a process.
    Execution replay is not supported, but this targets allows investigating
    the program's recorded execution.

For a complete list and more details on each item, please see the
gdb/NEWS file.

Thread exit messages on MS-Windows

Eli Zaretskii — 2013-04-26T09:46:56

This is from the node "Threads" of the manual:

  `set print thread-events'
  `set print thread-events on'
  `set print thread-events off'
       The `set print thread-events' command allows you to enable or
       disable printing of messages when GDB notices that new threads have
       started or that threads have exited.  By default, these messages
       will be printed if detection of these events is supported by the
       target.  Note that these messages cannot be disabled on all
       targets.

However, debugging MinGW programs on MS-Windows, I see only messages
about new threads, like this:

  [New Thread 6184.0x1bbc]
  [New Thread 6184.0x13c8]
  [New Thread 6184.0x1a3c]

I never see any messages about threads that exited, although examining
the details of the program being debugged, I clearly see that most of
them did.

Does that mean that GDB doesn't support thread exit messages on
Windows?  What feature(s) are missing for this support to be
available?

I can get thread exit messages from windows-nat.c such as

  [Deleting Thread 8112.0x1494]
  [Deleting Thread 8112.0x11d0]

if I "set verbose on", but that mode causes GDB to become much more
talkative than I'd like.

In thread.c, I see that add_thread_with_info will announce new threads
if print_thread_events is non-zero, but I see no similar announcement
in delete_thread or its subroutines.  Is this supposed to be handled
by target-specific back ends?  I see something like that in, e.g.,
linux-nat.c and in inf-ttrace.c, but I'm unsure whether that is a
conclusive evidence.

If indeed thread deletion should be announced by the target, why this
asymmetry with thread creation?

TIA for any help or info.