<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.comp.gdb.devel">
    <title>gmane.comp.gdb.devel</title>
    <link>http://permalink.gmane.org/gmane.comp.gdb.devel</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gdb.devel/32217"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gdb.devel/32216"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gdb.devel/32215"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gdb.devel/32214"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gdb.devel/32213"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gdb.devel/32212"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gdb.devel/32211"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gdb.devel/32210"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gdb.devel/32209"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gdb.devel/32208"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gdb.devel/32207"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gdb.devel/32206"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gdb.devel/32205"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gdb.devel/32204"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gdb.devel/32203"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gdb.devel/32202"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gdb.devel/32201"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gdb.devel/32200"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gdb.devel/32199"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gdb.devel/32198"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gdb.devel/32217">
    <title>Re: Gdb online docs error?</title>
    <link>http://permalink.gmane.org/gmane.comp.gdb.devel/32217</link>
    <description>&lt;pre&gt;

Same here.  I can help if needed, I just found another page which is 404
on the server.

&lt;/pre&gt;</description>
    <dc:creator>Sergio Durigan Junior</dc:creator>
    <dc:date>2012-05-25T21:59:16</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gdb.devel/32216">
    <title>Re: Hotspot JVM GDBJIT plugin</title>
    <link>http://permalink.gmane.org/gmane.comp.gdb.devel/32216</link>
    <description>&lt;pre&gt;
Kaushik&amp;gt; With frame filters, would JIT readers still be necessary to
Kaushik&amp;gt; unwind the frame or is that done from Python too?

You would still need a JIT reader to do the unwinding.

The Python feature is really just about massaging the display of frames
already found by gdb.  At least in the first revision there won't be a
way to hook into the unwinding process.  We haven't even really
discussed letting people write unwinders in Python; I guess it could be
done.

Kaushik&amp;gt; If they're not, are JIT readers going to be supported going forward?

Yes, they will be.

Kaushik&amp;gt; When is this expected to hit trunk?

Phil?

Tom

&lt;/pre&gt;</description>
    <dc:creator>Tom Tromey</dc:creator>
    <dc:date>2012-05-25T21:03:00</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gdb.devel/32215">
    <title>Re: Hotspot JVM GDBJIT plugin</title>
    <link>http://permalink.gmane.org/gmane.comp.gdb.devel/32215</link>
    <description>&lt;pre&gt;Will do.

This was exactly what I was looking for when I started and since Python scripts
couldn't do it at the time, I wrote a JIT reader. I have a few questions though:

With frame filters, would JIT readers still be necessary to unwind the
frame or is
that done from Python too?
If they're not, are JIT readers going to be supported going forward?
When is this expected to hit trunk?

   -Kaushik

&lt;/pre&gt;</description>
    <dc:creator>Kaushik Srenevasan</dc:creator>
    <dc:date>2012-05-25T19:50:41</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gdb.devel/32214">
    <title>Re: Hotspot JVM GDBJIT plugin</title>
    <link>http://permalink.gmane.org/gmane.comp.gdb.devel/32214</link>
    <description>&lt;pre&gt;
Kaushik&amp;gt; I've been working on a Hotspot JVM JIT plugin for GDB

Very cool.

Kaushik&amp;gt; I'm writing to see if there is any interest in pulling the
Kaushik&amp;gt; changes [3] I've had to make to GDB, to get this to work.

Sure.  Just send individual patches following the contribution
instructions...

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

Sounds good.

Kaushik&amp;gt; The second (frame based symbol handler) is a feature added to
Kaushik&amp;gt; help GDB understand frames created by Hotspot's "template"
Kaushik&amp;gt; interpreter.

Kaushik&amp;gt; This adds an additional callback that the reader may choose to
Kaushik&amp;gt; implement to return the name (file path or line number) of the
Kaushik&amp;gt; function executing in the frame in question.

Phil has been working on a related feature in gdb, called "frame
filters".  Frame filters let you write Python code to modify frames as
they are being displayed; you can change nearly any aspect &lt;/pre&gt;</description>
    <dc:creator>Tom Tromey</dc:creator>
    <dc:date>2012-05-25T14:36:48</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gdb.devel/32213">
    <title>Re: Is there any mechanism in GDB to print memory allocation pattern in a core dump file</title>
    <link>http://permalink.gmane.org/gmane.comp.gdb.devel/32213</link>
    <description>&lt;pre&gt;
Santosh&amp;gt; The application is a C++ application running on Linux (RHEL 5.7
Santosh&amp;gt; x86_64). It uses a private memory allocator (variation of
Santosh&amp;gt; ptmalloc). The gdb-heap link says it works for python objects
Santosh&amp;gt; and work for c++ is under process. Can I use the gdb-heap ?

Probably not as-is.  gdb-heap relies on glibc.

You could probably port it to your allocator, though.

Tom

&lt;/pre&gt;</description>
    <dc:creator>Tom Tromey</dc:creator>
    <dc:date>2012-05-25T14:27:28</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gdb.devel/32212">
    <title>Re: siginfo and core files</title>
    <link>http://permalink.gmane.org/gmane.comp.gdb.devel/32212</link>
    <description>&lt;pre&gt;




I don't think the whole siginfo object is stored on core files.

See /usr/include/linux/elfcore.h .  The elf_prstatus and elf_prpsinfo
structures is what is put in the core.   We can retrieve some info, but
unfortunately, it doesn't look like si_addr is anywhere to be found.

&lt;/pre&gt;</description>
    <dc:creator>Pedro Alves</dc:creator>
    <dc:date>2012-05-25T14:21:09</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gdb.devel/32211">
    <title>siginfo and core files</title>
    <link>http://permalink.gmane.org/gmane.comp.gdb.devel/32211</link>
    <description>&lt;pre&gt;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 &amp;lt;corefile&amp;gt;" to get just&lt;/pre&gt;</description>
    <dc:creator>jmf list</dc:creator>
    <dc:date>2012-05-25T13:53:24</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gdb.devel/32210">
    <title>GDB/remote: RSP `g' packet size, advice sought</title>
    <link>http://permalink.gmane.org/gmane.comp.gdb.devel/32210</link>
    <description>&lt;pre&gt;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&lt;/pre&gt;</description>
    <dc:creator>Maciej W. Rozycki</dc:creator>
    <dc:date>2012-05-24T19:17:09</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gdb.devel/32209">
    <title>Hotspot JVM GDBJIT plugin</title>
    <link>http://permalink.gmane.org/gmane.comp.gdb.devel/32209</link>
    <description>&lt;pre&gt;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&lt;/pre&gt;</description>
    <dc:creator>Kaushik Srenevasan</dc:creator>
    <dc:date>2012-05-24T11:03:58</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gdb.devel/32208">
    <title>problems with async mode using user-defined or python command sequences</title>
    <link>http://permalink.gmane.org/gmane.comp.gdb.devel/32208</link>
    <description>&lt;pre&gt;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&lt;/pre&gt;</description>
    <dc:creator>Tim Black</dc:creator>
    <dc:date>2012-05-23T18:36:43</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gdb.devel/32207">
    <title>Re: Is there any mechanism in GDB to print memory allocation pattern in a core dump file</title>
    <link>http://permalink.gmane.org/gmane.comp.gdb.devel/32207</link>
    <description>&lt;pre&gt;
The application is a C++ application running on Linux (RHEL 5.7 x86_64). It
uses a private memory allocator (variation of ptmalloc). The gdb-heap link
says it works for python objects and work for c++ is under process. Can I
use the gdb-heap ?

Thanks,
Santosh

Nothing built in, but there is gdb-heap, if you're on a system using
glibc.

https://fedorahosted.org/gdb-heap/

Tom



&lt;/pre&gt;</description>
    <dc:creator>santoshp</dc:creator>
    <dc:date>2012-05-23T17:18:30</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gdb.devel/32206">
    <title>Re: Is there any mechanism in GDB to print memory allocation pattern in a core dump file</title>
    <link>http://permalink.gmane.org/gmane.comp.gdb.devel/32206</link>
    <description>&lt;pre&gt;
Santosh&amp;gt; I got a crash for which the size of the core file is little
Santosh&amp;gt; bigger i.e.  ~9GB. Initial impression is that there might be
Santosh&amp;gt; some memory leaks in the process as the size is bugger than the
Santosh&amp;gt; usual size. Is there any mechanism in GDB/Linux I can find out
Santosh&amp;gt; the memory allocation pattern in the core file?  e.g. There is
Santosh&amp;gt; a tool debug diag in Windows which can do this nicely from dump
Santosh&amp;gt; file.

Nothing built in, but there is gdb-heap, if you're on a system using
glibc.

https://fedorahosted.org/gdb-heap/

Tom

&lt;/pre&gt;</description>
    <dc:creator>Tom Tromey</dc:creator>
    <dc:date>2012-05-23T15:13:18</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gdb.devel/32205">
    <title>Is there any mechanism in GDB to print memory allocation pattern in a core dump file</title>
    <link>http://permalink.gmane.org/gmane.comp.gdb.devel/32205</link>
    <description>&lt;pre&gt;
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
&lt;/pre&gt;</description>
    <dc:creator>santoshp</dc:creator>
    <dc:date>2012-05-23T12:32:57</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gdb.devel/32204">
    <title>Re: Will therefore GDB utilize C++ or not?</title>
    <link>http://permalink.gmane.org/gmane.comp.gdb.devel/32204</link>
    <description>&lt;pre&gt;It's a NetBSD/MIPS64 derivative embedded system.  No other secondary storage for code.  Threading support is needed.  (That doesn't add much.)  I don't currently have multi-inferior support, although I've thought about adding that.

paul

On May 21, 2012, at 1:57 PM, Jan Kratochvil wrote:



&lt;/pre&gt;</description>
    <dc:creator>Paul_Koning&lt; at &gt;Dell.com</dc:creator>
    <dc:date>2012-05-22T18:03:41</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gdb.devel/32203">
    <title>Re: [PATCH] MIPS/sim: Fix build breakage</title>
    <link>http://permalink.gmane.org/gmane.comp.gdb.devel/32203</link>
    <description>&lt;pre&gt;

 Yep, no build failure for mips-sde-elf anymore.

  Maciej

&lt;/pre&gt;</description>
    <dc:creator>Maciej W. Rozycki</dc:creator>
    <dc:date>2012-05-22T14:26:19</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gdb.devel/32202">
    <title>Re: Gdb crashing or not attaching in Netbeans</title>
    <link>http://permalink.gmane.org/gmane.comp.gdb.devel/32202</link>
    <description>&lt;pre&gt;  Finally I got logs!
I'm asking for help in understanding what is happening.
First is a correct log, as to say a log of a working debugging session up to 
the first break point.
Then a log of a crashed debugging session, from which the debugger never 
recovers (closing the IDE, restarting the computer, nothing solves the debugger 
crash. Just clearing the IDE user settings folder).

So here is a working log.
=thread-group-added,id="i1"
~"GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2) 7.4-2012.04\n"
~"Copyright (C) 2012 Free Software Foundation, Inc.\n"
~"License GPLv3+: GNU GPL version 3 or later &amp;lt;http://gnu.org/licenses/gpl.
html&amp;gt;\nThis is free software: you are free to change and redistribute it.
\nThere is NO WARRANTY, to the extent permitted by law.  Type \"show copying\"
\nand \"show warranty\" for details.\n"
~"This GDB was configured as \"x86_64-linux-gnu\".\nFor bug reporting 
instructions, please see:\n"
~"&amp;lt;http://bugs.launchpad.net/gdb-linaro/&amp;gt;.\n"
&amp;amp;"/home/erupter/.gdbinit: No such file or directory&lt;/pre&gt;</description>
    <dc:creator>erupter&lt; at &gt;libero.it</dc:creator>
    <dc:date>2012-05-22T10:55:02</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gdb.devel/32201">
    <title>Re: Gdb online docs error?</title>
    <link>http://permalink.gmane.org/gmane.comp.gdb.devel/32201</link>
    <description>&lt;pre&gt;
I get a build on gdb-7.4.1 release on my box.  Both missing files, as
reported, Command-Files.html and GDB_002fMI-Command-Syntax.html are
generated properly.  However, the pdf version got from
http://sourceware.org/gdb/current/onlinedocs/gdb.pdf.gz looks correct.

A lot users reference gdb html doc on sourceware.org, so it is not good
to give them a "page not found" error.  I am happy to help on this, but
don't know what I can do.

&lt;/pre&gt;</description>
    <dc:creator>Yao Qi</dc:creator>
    <dc:date>2012-05-22T04:39:32</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gdb.devel/32200">
    <title>Re: [PATCH] MIPS/sim: Fix build breakage</title>
    <link>http://permalink.gmane.org/gmane.comp.gdb.devel/32200</link>
    <description>&lt;pre&gt;
so Nick's patch addresses your build failures ?  seems like you guys had some 
overlap, but not entirely ...
-mike
&lt;/pre&gt;</description>
    <dc:creator>Mike Frysinger</dc:creator>
    <dc:date>2012-05-22T01:52:27</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gdb.devel/32199">
    <title>Re: [PATCH] MIPS/sim: Fix build breakage</title>
    <link>http://permalink.gmane.org/gmane.comp.gdb.devel/32199</link>
    <description>&lt;pre&gt;

 Nope, just trying to get other work done, and since I did these tweaks 
anyway I decided to share them in case they would help someone else too.
I can see Nick's commited his fixes now, so that settles it.

  Maciej

&lt;/pre&gt;</description>
    <dc:creator>Maciej W. Rozycki</dc:creator>
    <dc:date>2012-05-22T00:11:10</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gdb.devel/32198">
    <title>Re: Will therefore GDB utilize C++ or not?</title>
    <link>http://permalink.gmane.org/gmane.comp.gdb.devel/32198</link>
    <description>&lt;pre&gt;
FWIW, I have an openwrt install on a 4MB flash, and figuring out how
to find enough space for the existing gdbserver was a pain.
to the point where I just made a ramdisk and copied gdbserver to it
when i needed it (which lucky for me wasn't debugging any issue at
boot time/user space worked enough to get gdbserver to its
destination.)

many of these newer openwrt/dd-wrt systems also have usb they can use
to add additional storage.

that is to say, i think regardless of c/c++ gdbserver is possibly too
big for some of these small but not tiny installations or at least on
the cusp of being so, and getting larger, thus a smaller gdbserver
might be warranted regardless of c/c++

&lt;/pre&gt;</description>
    <dc:creator>Matt Rice</dc:creator>
    <dc:date>2012-05-21T18:53:50</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gdb.devel/32197">
    <title>Re: Will therefore GDB utilize C++ or not?</title>
    <link>http://permalink.gmane.org/gmane.comp.gdb.devel/32197</link>
    <description>&lt;pre&gt;
With RAII you do not have to write many times in that function that do_cleanup
statement (for multiple cleanup markers), which makes one of the differences.


Jan

&lt;/pre&gt;</description>
    <dc:creator>Jan Kratochvil</dc:creator>
    <dc:date>2012-05-21T16:52:52</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.gdb.devel">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.gdb.devel</link>
  </textinput>
</rdf:RDF>

