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

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: 
0000000000000000000000000

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 wor

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 ru

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 t

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

[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

[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 goi

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-0ub