gmane.comp.gdb.devel

siginfo and core files

jmf list — 2012-05-25T13:53:24

Hello,

Is it possible to access the si_addr and si_signo siginfo fields from
a core dump in GDB? When debugging a live process I access these
values via the $_siginfo convenience var. I am not sure if both of
these values are normally stored in a core dump, or if they are
accessible via GDB.

I noticed that the signal number is printed to the console when I load
a core file, so I started reading the GDB source around the string
"Program terminated with signal" and found that the signal number is
read from the core file via gdb/corelow.c::core_open and
bfd/corefile.c::bfd_core_fail_failing_signal. It isn't apparent to me
that any of the other siginfo is stored or read, however.

I would like to access these values via the GDB Python API for both
live processes and core files. As it stands, I could potentially parse
'info target' to determine the target type, and respectively use
"$_siginfo" to get both si_signo and si_addr if my script is running
on a live process, or use "target core <corefile>" to get just the
signal number (and let the tool degrade gracefully for lack of
si_addr) if my script is running on a core file. That solution is a
bit of a kludge though, and I would like to access si_addr in the core
file if possible.

I am running GDB 7.4 in FC16 on x86_64 for this analysis.

Thanks. Any help would be appreciated,
J

GDB/remote: RSP `g' packet size, advice sought

Maciej W. Rozycki — 2012-05-24T19:17:09

Hi,

 I've been struggling with a problem with the RSP `g' packet size, that 
once initialised may only be further shrunk, and never expanded back.  
The issue can be easily reproduced with the MIPS target using QEMU, e.g.:

(gdb) target remote | /path/to/mips-linux-gnu-qemu-system -s -S -p stdio -M mipssim -cpu 24Kc --semihosting --monitor null --serial null -kernel /dev/null
Remote debugging using | /path/to/mips-linux-gnu-qemu-system -s -S -p stdio -M mipssim -cpu 24Kc --semihosting --monitor null --serial null -kernel /dev/null
0x00100000 in ?? ()
(gdb) target remote | /path/to/mips-linux-gnu-qemu-system -s -S -p stdio -M mipssim -cpu 24Kf --semihosting --monitor null --serial null -kernel /dev/null
A program is being debugged already.  Kill it? (y or n) y

QEMU: Terminated via GDBstub

Remote debugging using | /path/to/mips-linux-gnu-qemu-system -s -S -p stdio -M mipssim -cpu 24Kf --semihosting --monitor null --serial null -kernel /dev/null
Remote 'g' packet reply is too long: 
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000040000400000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000073930000000000
(gdb)

This is because the 24Kc does not support the FPU and the 24Kf does, and 
hence the latter produces a longer `g' reply packet that includes the 
extra FPU state.  However the remote backend has already shrunk its `g' 
packet buffer size when talking to the 24Kc and cannot expand it back.  
The only way to recover is to restart GDB from scratch that can be 
annoying.

 I have tracked down the cause to be the way the remote backend 
initialises the `g' packet size.  It's only done in init_remote_state that 
is called once, when gdbarch data is initialized.  The initial size is 
calculated based on the maximum number of registers supported by the 
architecture:

  rsa->regs = GDBARCH_OBSTACK_CALLOC (gdbarch,
      gdbarch_num_regs (gdbarch),
      struct packet_reg);
  rsa->sizeof_g_packet = map_regcache_remote_table (gdbarch, rsa->regs);

Then this is further adjusted whenever a `g' packet reply is received in
process_g_packet:

  if (buf_len > 2 * rsa->sizeof_g_packet)
    error (_("Remote 'g' packet reply is too long: %s"), rs->buf);
[...]
  if (buf_len < 2 * rsa->sizeof_g_packet)
    {
      rsa->sizeof_g_packet = buf_len / 2;
[...]

Hotspot JVM GDBJIT plugin

Kaushik Srenevasan — 2012-05-24T11:03:58

I've been working on a Hotspot JVM JIT plugin for GDB and noticed that
there was some interest about this earlier [1]. I currently have mixed
mode stack traces working [2] and plan to at least add file and
line number support in the future.

I'm writing to see if there is any interest in pulling the
changes [3] I've had to make to GDB, to get this to work. I also
intend to ping the OpenJDK folks to try to get the GDBJIT hooks into
the official distribution.

The first of these changes [3] is a simple fix to a crash while trying to
display the return type of a JIT frame (say on 'finish'.)

The second (frame based symbol handler) is a feature added to help GDB
understand frames created by Hotspot's "template" interpreter. Hotspot
generates expansions for bytecodes from templates (once) into a buffer
and uses jump tables to handle dispatch. The same code range thus
corresponds to different functions, with the only differentiating
factor being metadata in stack frames. Neither ELF symbol tables nor
callbacks work in this case and hence the need for frame based symbol
resolution.

This adds an additional callback that the reader may choose to
implement to return the name (file path or line number) of the function
executing in the frame in question. GDB's stack walk code consults this
handler if it can't find a symbol in its global symbol table. The JIT
host inserts itself as a handler and simply forwards the call to the
reader. Symbols are only ever created lazily; when the unwinder finds
the frame on the stack. I also want to add support to display
inlined frames which I can't imagine being realized without frame
based handlers. [3] is only a rough implementation that I intend to
complete based on feedback I get from this list.

Thanks,
   -Kaushik

[1] http://sources.redhat.com/ml/gdb/2012-02/msg00025.html
[2] http://sysenter.org/~ks/gdb/gdb-jvm.png
[3] https://github.com/kaushiks/GDB/commit/98d8b224c3f48639368e91f0a531394124596a2e

problems with async mode using user-defined or python command sequences

Tim Black — 2012-05-23T18:36:43

I'm using gdb 7.4.1 on embedded powerpc target and 2.6.32.28 kernel to
perform some analysis on my multi-threaded C++ program that uses
pthreads. My end goal was to script gdb with python to automate some
common analysis functions, and create a crude profiler by sampling the
stack of the active thread. The problem is that I am finding some
discrepancy in behavior when I run commands individually at the
command line vs. in a gdb user-defined command (or invoking the same
commands via python script). I found a reference to a very similar
problem on this mailing list:
http://sourceware.org/ml/gdb/2009-01/msg00157.html
Although I don't completely follow Pedro's response about the
limitation of async mode, I think he's implying that in async mode,
the relative timing of user-defined command sequences cannot be
trusted. This is what I found empirically.

In both scenarios, I perform the following start-up steps, loading my
program, setting its args, and turning on asynchronous and non-stop
debugging modes, then running the program in the background:

(gdb) file myprogram
(gdb) set args --interface=eth0 --try-count=0
(gdb) set target-async on
(gdb) set pagination off
(gdb) set non-stop on
(gdb) run &

At this point, if I manually issue "interrupt" and then "info threads"
commands, I see the list of all threads running except one that got
stopped. Then I can continue & and repeat to my hearts content, it
works consistently. When stopped, I can inspect that thread's stack
frames and all is well.

However, if instead I put these commands into a user-defined gdb command:

(gdb) define foo
(gdb) interrupt
(gdb) info threads
(gdb) continue &
(gdb) end
(gdb) foo
Cannot execute this command while the selected thread is running.

I believe the error msg is caused by the "continue &" command, because
the preceding "interrupt" did not stop any threads (yet). I thought
this was a problem inherent to the asynchronous gdb commanding, so I
inserted an absurdly long wait after the interrupt command and got the
same behavior:

(gdb) define foo
(gdb) interrupt
(gdb) shell sleep 5
(gdb) info threads
(gdb) continue &
(gdb) end
(gdb) foo
Cannot execute this command while the selected thread is running.

With or without the sleep command, I can always issue the manual CLI
commands and the threads get stopped correctly.

Similarly, I get the same results sourcing a python script to do the
thread perusal:

import gdb, time

gdb.execute("file myprogram")
gdb.execute("set args --interface=eth0 --try-count=0")
gdb.execute("set target-async on")
gdb.execute("set pagination off")
gdb.execute("set non-stop on")
gdb.execute("run &")
time.sleep(5)
gdb.execute("interrupt")

# here, I inspect threads via gdb module interface
# in practice, they're always all running bc the program never got interrupted
for thread in gdb.selected_inferior().threads():
    print thread.is_running(),

gdb.execute("continue &")

I get the same result even if I specify from_tty=True in the
gdb.execute calls. Also, if I use continue -a it suppresses the error
string but does not help otherwise bc the interrupt call still doesn't
work.

So... is this:

    * cockpit error? Is there something that I'm omitting or doing
incorrectly, given what I'm trying to accomplish? Should this work, or
do I have to use GDB/MI to asynchronously "drive" gdb like this?
    * a timing problem? Maybe invoking shell sleep (or python
time.sleep()) doesn't do what I assume it would, in this context.
    * a gdb problem?

Thanks.

Is there any mechanism in GDB to print memory allocation pattern in a core dump file

santoshp — 2012-05-23T12:32:57

Hi All,
I got a crash for which the size of the core file is little bigger i.e.
~9GB. Initial impression is that there might be some memory leaks in the
process as the size is bugger than the usual size. Is there any mechanism in
GDB/Linux I can find out the memory allocation pattern in the core file?
e.g. There is a tool debug diag in Windows which can do this nicely from
dump file.

Any pointers will be appreciated.

Thanks,
Santosh

Gdb online docs error?

Mingjie Xing — 2012-05-18T05:26:51

Hi,

The link page http://sourceware.org/gdb/current/onlinedocs/gdb/Command-Files.html#Command-Files
is not available for now.  Maybe the gdb online docs have problems.

Thanks
Mingjie

Gdb crashing or not attaching in Netbeans

2012-05-17T14:38:16

Hello.
I've used GDB as a standalone debugger before, maybe with one amateur 
interface until recently I discovered Netbeans.
During development of a program suddenly debugging stopped working.
If I load a simple hello world, GDB works fine.
In the program I'm re-writing now (old program whose external libraries got 
changed) GDB doesn't want to work anymore.
Now Netbeans doesn't provide any info at all to help me debug this, so I'm 
asking here: how can I gather information on this kind of malfunction?

It *seems* that there is a problem with the source of a library.
Meaning that if I exclude the include (and the relevant code which is most of 
it) GDB works.
The moment I include that external source, it stops working.
Files are there though and compilation goes without problems.

I'm really in the dark here.

Best regards
Claudio

problem while probing the local variables

chansarav — 2012-05-17T08:41:40

Hi,

I am porting gdb (7.3.1) for the first time to a 32 bit VLIW
architecture. I have added the bfd files, architecture descriptions
files by studying the reference ports. Now the ported gdb is able to
do the following basic operations:

1. Inserting/removing breakpoints
2. probing the global variables at a particular breakpoint

But I face problem while probing the local variables during execution
at a particular breakpoint. (Note: I build the application for debug
mode in which no optimization is performed by the compiler tool
chain).

Please consider the following example case:

1 . #define N 1000
2 .
3 . int global_var1 = 0;
4 . int global_var2 = 1;
5 .
6 . void func (int arg)
7 . {
8 .   global_var2 = arg;
9 . }
10.
11. int main()
12. {
13.   int i;
14.   int result = 0;
15.   int A[N];
16.
17.   global_var1 = 2;
18.
19.   for (i=0; i<N; i++)
20.   {
21.     result += i*10;
22.     A[i] = result;
23.   }
24.
25.   func (result);
26.
27.   global_var1 = result;
28.
29.   return 0;
30. }


When I break the exection at line 27 and print the local variable
'result', gdb says "No symbol "result" in current context.".

And on issuing the "info scope main", gdb says "Symbol i is Unexpected
opcode after DW_OP_breg0 for symbol "i"."

On analyzing on this issue I found the following:

1. Currently the compiler tool chain generates the ELF files only with
allocable sections (data and code). The non-allocable sections are not
included in the ELF file generated. Hence the symbol table information
is missing. Will this hinder the debugging by gdb?

2. On debugging for the message "Symbol i is Unexpected opcode after
DW_OP_breg0 for symbol "i".", I found that in function
locexpr_describe_location_piece () of dwarf2loc.c, the frame_offset
for symbol 'i' is being read correctly. But problem comes out in the
following piece of code:

Using gdb with a Delphi XE2 project

OBones — 2012-05-15T08:51:23

Hello all,

Under Windows, I'm trying to debug with gdb an exe file created with 
Delphi XE2
However, I can't find which options I should set for the compiler/linker 
in order for gdb to find the symbols and allow debugging as right now, I 
always get this message:

Reading symbols from C:\Some\Dir\MyProgram.exe...(no debugging symbols 
found)...done.

Does anyone have any suggestion?

Regards

[mingw gdb/mi] Separating debuggee output from MI

Noobody — 2012-05-15T06:20:37

I'm currently writing a gdb frontend using the GDB/MI interface, but I have
been experiencing difficulties with differentiating between output by the
debuggee and output from gdb itself.

The documentation mentions target-stream-output, which is prefixed with "< at >",
but it seems it is not actually being used. Instead, target output appears
interleaved with gdb output.

This can cause various problems, so I would like to be able to safely 
separate
target output/input from gdb output/input. Searching for a bit revealed that
this is quite a common problem when writing gdb frontends on windows due to
various limitations of the OS, but I was unable to find a good solution.

I implemented a workaround to this which seems to work, however I am not 
quite
sure whether it is safe to use.

What I'm doing right now is start the debuggee process in suspended mode 
from
the frontend (with CreateProcess and CREATE_SUSPENDED flag), create the gdb
process separately, attach it to the suspended process and then resume it
with ResumeThread (assuming a single-threaded program).

Something like this:

/* Start debug process */
CreateProcess(...)

/* Start gdb */
  gdb.exe -i mi
 >> -target-attach pid
<< *stopped
 >> -exec-continue
<< *running,thread-id="all"

/* Resume suspended process */
ResumeThread(...)

This seems to work, as I now have the debuggee input/output and the gdb
input/output in separate pipes. However, I have not had the chance to 
test this
any further, so I'm wondering - could this setup could cause any problems?
Especially the fact that I'm doing -exec-continue on a suspended process 
seems
like asking for trouble.

Thanks!
Benedikt Bitterli

[x86-64 psABI] RFC: Extend x86-64 psABI to support x32

H.J. Lu — 2012-05-14T17:31:11

Hi,

Support for the x32 psABI:

http://sites.google.com/site/x32abi/

is added in Linux kernel 3.4-rc1.  X32 uses the ILP32 model for x86-64
instruction set with size of long and pointers == 4 bytes.  X32 is
already supported in GCC 4.7.0 and binutils 2.22.  I am now working
to integrate x32 support into GLIBC 2.16 and GDB 7.5   Here is a
patch to extend x86-64 psABI for x32.  Any comments?

Thanks.

[mingw]gdb CVS HEAD build error

asmwarrior — 2012-05-14T01:25:43

I have build error when building gdbserver.exe
Here is the log:
mingw32-gcc -c  -g -O2 -D__USE_MINGW_ACCESS    -I. -I../../../gdb/gdb/gdbserver -I../../../gdb/gdb/gdbserver/../common -I../../../gdb/gdb/gdbserver/../regformats -I../../../gdb/gdb/gdbserver/../../include -I../../../gdb/gdb/gdbserver/../gnulib/import -Ibuild-gnulib-gdbserver/import -Wall -Wdeclaration-after-statement -Wpointer-arith -Wformat-nonliteral -Wno-char-subscripts -Werror ../../../gdb/gdb/gdbserver/../common/buffer.c -DGDBSERVER
../../../gdb/gdb/gdbserver/../common/buffer.c: In function 'buffer_xml_printf':
../../../gdb/gdb/gdbserver/../common/buffer.c:144:9: error: unknown conversion type character 'l' in format [-Werror=format]
../../../gdb/gdb/gdbserver/../common/buffer.c:144:9: error: too many arguments for format [-Werror=format-extra-args]
../../../gdb/gdb/gdbserver/../common/buffer.c:147:9: error: unknown conversion type character 'l' in format [-Werror=format]
../../../gdb/gdb/gdbserver/../common/buffer.c:147:9: error: too many arguments for format [-Werror=format-extra-args]
../../../gdb/gdb/gdbserver/../common/buffer.c:150:9: error: unknown conversion type character 'l' in format [-Werror=format]
../../../gdb/gdb/gdbserver/../common/buffer.c:150:9: error: too many arguments for format [-Werror=format-extra-args]
../../../gdb/gdb/gdbserver/../common/buffer.c:153:9: error: unknown conversion type character 'l' in format [-Werror=format]
../../../gdb/gdb/gdbserver/../common/buffer.c:153:9: error: too many arguments for format [-Werror=format-extra-args]
cc1.exe: all warnings being treated as errors
make[4]: *** [buffer.o] Error 1
make[4]: Leaving directory `/f/build_gdb/gdb/gdbgit/newbuild/gdb/gdbserver'
make[3]: *** [subdir_do] Error 1
make[3]: Leaving directory `/f/build_gdb/gdb/gdbgit/newbuild/gdb'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/f/build_gdb/gdb/gdbgit/newbuild/gdb'
make[1]: *** [all-gdb] Error 2
make[1]: Leaving directory `/f/build_gdb/gdb/gdbgit/newbuild'
make: *** [all] Error 2

I see the code change in buffer.c in
Commit:2e01eef6b3e2152435a344c7de3351d4b92525dd

* 2012-05-11  Stan Shebs  <stan< at >codesourcery.com>
    Kwok Cheung Yeung  <kcy< at >codesourcery.com>


It looks like those format: "%lld"

sprintf (str, "%lld", va_arg (ap, long long));

is not supported under MinGW.

By reading this link:
http://cboard.cprogramming.com/cplusplus-programming/118149-long-long-int-gplusplus-mingw.html

It suggest that under MinGW, we should use %I64d

Any ideas?

Thanks

Yuanhui Zhang

[design change] record-replay linux ABI level

oza Pawandeep — 2012-05-09T09:16:21

Hi all,

currently linux-record.h is having defination of
enum gdb_syscall {...} which seems generic one, but infact it only
addresses i386 arch.

the way the arm syscall number defined are different and mapping is different.

I am thinking of moving all the definition to i386 specific files
(assuming there is no generic way to address all the systemcalls on
all arch).

there might be similar instances which also like to be moved to i386
specific file
(for e.g. struct linux_record_tdep
{
  /* The size of the type that will be used in a system call.  */
  int size_pointer;
  int size__old_kernel_stat;
  int size_tms;
-
-
-
-
-
}

please let me know any input for the same, as I am working on arm
syscall recording part.

Regards,
Oza.

Microblaze simulator - Fix missing prototype

Joel Sherrill — 2012-05-07T20:23:34

Without this patch, this generates a missing prototype
warning which is treated as an error. I don't see this
routine referenced elsewhere, so there is the possibility
that it also could be made static.

OK to apply?

2012-05-12  Joel Sherrill <joel.sherrill< at >oarcorp.com>

     * microblaze-rom.c (_initialize_picobug_rom): Add prototype.

Add microblaze--rtems

Joel Sherrill — 2012-05-07T20:19:38

OK to apply?

2012-05-07  Joel Sherrill <joel.sherrill< at >oarcorp.com>

     * configure.tgt (microblaze*-*-rtems*): New target

Do you need a backround check done quickly and confidentially?

2012-05-07T08:53:45

http://www.j.mp/IiNUrk

GNU Tools Cauldron 2012 - Hotels and registered presentations

Diego Novillo — 2012-05-03T20:05:22

An update on the GNU Tools Cauldron (http://gcc.gnu.org/wiki/cauldron2012)

We have published an initial schedule for the workshop.  It is
available at http://gcc.gnu.org/wiki/cauldron2012.

Presenters, please double-check your entries.  If you find
anything missing or wrong, please contact me and I will correct
it.


Thank you.

Question about GDB event mechanism

Siva Chandra — 2012-05-03T18:42:04

Hi all,

I am trying to understand the event mechanism when used in Python
code.  For example, set a breakpoint at main and run 'tcmd' after
sourcing the following Python script:

<CODE>
import gdb

def bp_handler(bp_event):
   print "Hello, BreakPoint!"

gdb.events.stop.connect(bp_handler)

class Cmd(gdb.Command):
   def __init__(self):
       super(Cmd, self).__init__("tcmd", gdb.COMMAND_OBSCURE)

   def invoke(self, arg, from_tty):
       gdb.execute("run", to_string=True)
       print "End of 'tcmd'"

Cmd()
</CODE>

I would expect "Hello, Breakpoint!" to be printed, but it is not being
printed as 'run' is executed via 'execute_command_to_string' which
will reset gdb_stdout only after 'execute_command' returns.  The
notification of the breakpoint event is sent via 'normal_stop' before
'execute_command' returns.

Above was a simple example, but consider a case where a user is trying
to execute commands like 'step' or 'up' as part of the stop event
callback: For a long time, I didn't understand what was going when I
did such things (I of course had a very different expectations).
Hence, should the current behavior be documented or fixed?

Thanks,
Siva Chandra

sun compiler and gdb

Tomasz Grobelny — 2012-05-03T03:23:24

Hi all,
Should it be possible to debug C++ programs compiled using sun compiler
using GDB? If so which debug format should I use? Which versions of the
compiler/gdb support such a scenario? Currently the situation looks like
this (which does not look very promising):

CC: Sun C++ 5.11 SunOS_i386 2010/08/13
usage: CC [ options ] files.  Use 'CC -flags' for details
Reading symbols from /full/path/to/my/a.out...done.
(gdb) break fun
Dwarf Error: Cannot find DIE at 0x0 referenced from DIE at 0x13b33 [in
module /full/path/to/my/a.out]
(gdb) break main
Dwarf Error: Cannot find DIE at 0x0 referenced from DIE at 0x13b33 [in
module /full/path/to/my/a.out]
(gdb) run
Starting program: /full/path/to/my/a.out
[Thread debugging using libthread_db enabled]
hello world
[Inferior 1 (process 9412    ) exited normally]
(gdb) quit
SunOS solac1 5.10 Generic_137138-09 i86pc i386 i86pc

gdb version is 7.4.1
Any ideas what is wrong here?

Symbol Handling improvements

Doug Evans — 2012-05-02T22:13:01

[bcc gdb-patches, just to make sure it reaches everyone]

Hi.
fyi, I have started a page to collect issues related to symbol
handling, debug info, etc. and to list ideas people are thinking
about.

I don't have any specific actions to take yet.
It's just a beginning.

http://sourceware.org/gdb/wiki/SymbolHandling

Comments welcome.

-ggdb3 -gdwarf-4 but "info macro BLAH" still doesn't work?

Martin Olsson — 2012-05-01T20:36:49

Hello,

In a small test app built with -g3 I can print values of macros inside 
gdb by doing "info macro MYMACRONAME", however in a larger application 
I cannot get it to work despite passing the same -g3 and using the 
same gdb command. Just to be sure, I tried turning off stuff like 
pre-compiled headers etc in the large app but I still can't get the 
macro values to print correctly. In the large app, what I see is:

(gdb) info macro MYMACRONAME
The symbol `MYMACRONAME' has no definition as a C/C++ preprocessor macro
at ../../platforms/linux/src/main.cpp:263

In both cases gdb "info source" reports "Includes preprocessor macro 
info."
and also "Compiled with DWARF 2 debugging format."

For the large app readelf also reports the macro I'm testing as 
present (so I'm assuming the gcc end is doing the right thing):

$ readelf -wm binary | grep MYMACRONAME
  DW_MACINFO_define - lineno : 12 macro : MYMACRONAME 4096

FWIW; I'm using ubuntu 12.04 LTS which means I got gcc 
4:4.6.3-1ubuntu5 and gdb 7.4-2012.02-0ubuntu2. I've also tried 
building with "-ggdb3 -gdwarf-4" but I still can't get values of 
macros and oddly gdb then still reports "Compiled with DWARF 2 
debugging format", which was a bit weird?

Also if I do "info macros" then I get nothing printed at all.

---

What else can I try to make progress on this issue?

If there is no easier way, maybe someone can recommend a breakpoint 
location in GDB where I can step through the code that executes the 
"info macro BLAH" command ?

Martin