http://blog.gmane.org/gmane.comp.gdb.patches hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.gdb.patches/86709 <pre>I found out today that MinGW GDB cannot announce DLL unloads correctly, with both stop-on-solib-events turned on and with "catch unload". It says this instead: Stopped due to shared library event (no libraries added or removed) Debugging GDB, I see the following sequence: . when a DLL is unloaded, handle_unload_dll is called by windows-nat.c, and correctly finds the DLL that is being unloaded. . handle_unload_dll then calls solib_add, which puts the unloaded DLL on the deleted_solibs list of the current_program_space. . I put a watchpoint on the deleted_solibs list, and I see that at some point after handle_unload_dll returns, we call handle_solib_event, which begins by calling clear_program_space_solib_cache, which empties the deleted_solibs list. It then calls solib_add again, but now it's too late. So it looks like the call to solib_add inside handle_unload_dll is the culprit. And indeed, the trivial one-liner below is enough to fix both stop-on-solib-events and "c</pre> Eli Zaretskii 2013-05-19T18:39:03 http://comments.gmane.org/gmane.comp.gdb.patches/86707 <pre>Hello, when I committed the support for PowerPC FreeBSD I forgot to add the ppcfbsd-tdep.o to the ALL_TARGET_OBJ. So when I build a native gdb on PowerPC FreeBSD with --enable-targets=all I get a few unreferenced symbols. The below patch fixes that. Ok for trunk? TIA, Andreas 2013-05-19 Andreas Tobler &lt;andreas&lt; at &gt;fgznet.ch&gt; * Makefile.in (ALL_TARGET_OBS): Add ppcfbsd-tdep.o. Index: Makefile.in =================================================================== RCS file: /cvs/src/src/gdb/Makefile.in,v retrieving revision 1.1255 diff -u -r1.1255 Makefile.in --- Makefile.in15 May 2013 12:26:14 -00001.1255 +++ Makefile.in19 May 2013 14:16:10 -0000 &lt; at &gt;&lt; at &gt; -575,8 +575,8 &lt; at &gt;&lt; at &gt; mt-tdep.o \ nios2-tdep.o nios2-linux-tdep.o \ nto-tdep.o \ -ppc-linux-tdep.o ppcnbsd-tdep.o ppcobsd-tdep.o ppc-sysv-tdep.o \ -ppc64-tdep.o rl78-tdep.o \ +ppc-linux-tdep.o ppcfbsd-tdep.o ppcnbsd-tdep.o ppcobsd-tdep.o \ +ppc-sysv-tdep.o ppc64-tdep.o rl78-tdep.o \ rs6000-aix-tdep.o rs6000-tdep.o solib-aix.o ppc-ravenscar-threa</pre> Andreast Tobler 2013-05-19T14:21:33 http://comments.gmane.org/gmane.comp.gdb.patches/86700 <pre>Hi. This patch speeds up reading of debug info when there is no DWP file (i.e. when reading the DWO files directly). It also makes gdb more tolerant of bad Fission debug info. Regression tested on amd64-linux with/without Fission. I will check this in in a few days if there are no objections. 2013-05-17 Doug Evans &lt;dje&lt; at &gt;google.com&gt; When reading CU, stay in DWO. Be more tolerent of bad debug info. For Fission. * dwarf2read.c (struct dwarf2_per_cu_data): New member reading_dwo_directly (struct signatured_type): New member dwo_unit. (struct die_reader_specs): New member comp_dir. (create_signatured_type_table_from_index): Use malloc for all_type_units instead of objfile's obstack. (create_all_type_units): Ditto. (fill_in_sig_entry_from_dwo_entry): New function. (add_type_unit): New function. (lookup_dwo_signatured_type): New function. (lookup_dwp_signatured_type): New function. (lookup_signatured_type): New arg cu. All callers updated. (init_cu_die_reader): Initialize comp_dir. (read_cutu_</pre> Doug Evans 2013-05-17T22:32:47 http://comments.gmane.org/gmane.comp.gdb.patches/86687 <pre>Hi. I needed to add another parameter to the cu/tu functions in dwarf.exp. And if I need to add one I may need to add another. This patch changes the existing set of options to be a list. The testcase that uses this is a separate patch, but it may be awhile in coming, sigh. I'd like to get this in now so that any new tests that get written don't also have to be updated when this goes in. Note: I made the defaults 64 bit addresses and dwarf version 4. Seems reasonable these days. It does change the dwarf version from 2 to 4 for some of the existing tests, but I didn't find an issue with this. Ok to check in? Regression tested on amd64-linux. 2013-05-17 Doug Evans &lt;dje&lt; at &gt;google.com&gt; * lib/dwarf.exp (Dwarf): New variable _abbrev_section. (_handle_DW_TAG): Use it. (cu): Replace parameters is_64, version, addr_size with options. All callers updated. Add Fission support. Index: testsuite/gdb.dwarf2/implptrconst.exp =================================================================== RCS file: /cvs/src/s</pre> Doug Evans 2013-05-17T17:27:56 http://comments.gmane.org/gmane.comp.gdb.patches/86686 <pre>I'm checking this in. I noticed that in a couple of places, gdb calls PyErr_SetString if PyObject_New failed. However, this is not needed, and is perhaps actively confusing, because PyObject_New has already set the exception. Built and regtested on x86-64 Fedora 18. Tom 2013-05-17 Tom Tromey &lt;tromey&lt; at &gt;redhat.com&gt; * python/py-inferior.c (infpy_read_memory): Don't call PyErr_SetString if PyObject_New fails. * python/py-frame.c (frame_info_to_frame_object): Don't call PyErr_SetString if PyObject_New fails. diff --git a/gdb/python/py-frame.c b/gdb/python/py-frame.c index e2eb9c5..9342f45 100644 --- a/gdb/python/py-frame.c +++ b/gdb/python/py-frame.c &lt; at &gt;&lt; at &gt; -304,11 +304,7 &lt; at &gt;&lt; at &gt; frame_info_to_frame_object (struct frame_info *frame) frame_obj = PyObject_New (frame_object, &amp;frame_object_type); if (frame_obj == NULL) - { - PyErr_SetString (PyExc_MemoryError, - _("Could not allocate frame object.")); - return NULL; - } + return NULL; TRY_CATCH (except, RETURN_MASK_ALL) </pre> Tom Tromey 2013-05-17T16:51:26 http://comments.gmane.org/gmane.comp.gdb.patches/86684 <pre>Guys, I've created a new page in the wiki: http://sourceware.org/gdb/wiki/ContributionChecklist This was heavily borrowed from glibc's own contribution checklist. (I asked them if they were okay before doing it.) At present, some of the info there duplicates what gdb/CONTRIBUTE says (but in different wording). I expect it to grow some, and I'd rather keep it dynamic, without formal review/checking steps, which IMO for this sort of think is a too heavy process. I tailored the original text to make it fitter for gdb, but it's possible/likely there are things that need more editing to make it even fitter. I've been noticing that I often find myself pointing at the same little mistakes over different submissions. E.g., pointing at need to mention changes in NEWS. As I notice these patterns, I'll add them to the wiki. I invite others to do the same. Thanks, </pre> Pedro Alves 2013-05-17T16:37:55 http://comments.gmane.org/gmane.comp.gdb.patches/86672 <pre> Add a sanity check on the frame pointer before trying to access memory. The check aims to prevent a "Cannot access memory at address" error being printed when the frame pointer is zero or otherwise below the current sp. This only affects the case where no symbols are available and has been seen with the KVM debug stub. The frame pointer is read every time the frame_id is requested so something as simple as "print $pc" can cause an error to be printed. No new testsuite failures configured with armv7l-unknown-linux-gnueabihf. gdb/ChangeLog: 2013-05-17 Will Newton &lt;will.newton&lt; at &gt;linaro.org&gt; * arm-tdep.c (arm_scan_prologue): Check the frame pointer looks valid by comparing to current sp before reading it. --- gdb/arm-tdep.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/gdb/arm-tdep.c b/gdb/arm-tdep.c index b169e35..162aea8 100644 --- a/gdb/arm-tdep.c +++ b/gdb/arm-tdep.c &lt; at &gt;&lt; at &gt; -1979,10 +1979,15 &lt; at &gt;&lt; at &gt; arm_scan_prologue (struct frame_info *this_frame, Then, we can find the value of</pre> Will Newton 2013-05-17T08:45:10 http://comments.gmane.org/gmane.comp.gdb.patches/86657 <pre>I don't intend to commit this patch as is, but I wanted to post it because it provides useful functionality for msp430 programming and debugging. I have found it very useful for running the GDB test suite because it provides the necessary functionality for printf() and write() to work. TI has an I/O mechanism used by their compiler and libraries that they call CIO. In a nutshell, it defines a small number of operations such as open, close, read, write, plus a few others. Drivers exist at several levels for implementing this functionality. E.g. there are a board level drivers that causes I/O to occur against devices on the board. When the target is connected to a debugger, a debug-based driver is available which causes I/O to be performed on the host running GDB (or some other debugger). The debugger based driver uses a simple breakpoint driven implementation. The debugger places a breakpoint on a known location which is always called when debugger-based I/O is to be performed. When the breakpoint at</pre> Kevin Buettner 2013-05-17T04:23:58 http://comments.gmane.org/gmane.comp.gdb.patches/86656 <pre>This patch adds support for the TI msp430 architecture to GDB. Comments? gdb/ChangeLog: * Makefile.in (ALL_TARGET_OBS): Add msp430-tdep.o. (ALLDEPFILES): Add msp430-tdep.c. * configure.tgt (msp430*-*-elf): New target. * msp430-tdep.c: New file. Index: Makefile.in =================================================================== RCS file: /cvs/src/src/gdb/Makefile.in,v retrieving revision 1.1255 diff -u -p -r1.1255 Makefile.in --- Makefile.in15 May 2013 12:26:14 -00001.1255 +++ Makefile.in17 May 2013 02:50:54 -0000 &lt; at &gt;&lt; at &gt; -572,6 +572,7 &lt; at &gt;&lt; at &gt; ALL_TARGET_OBS = \ mipsnbsd-tdep.o mips-tdep.o \ mn10300-linux-tdep.o mn10300-tdep.o \ moxie-tdep.o \ +msp430-tdep.o \ mt-tdep.o \ nios2-tdep.o nios2-linux-tdep.o \ nto-tdep.o \ &lt; at &gt;&lt; at &gt; -1520,6 +1521,7 &lt; at &gt;&lt; at &gt; ALLDEPFILES = \ mips-tdep.c \ mipsnbsd-nat.c mipsnbsd-tdep.c \ mips64obsd-nat.c mips64obsd-tdep.c \ +msp430-tdep.c \ nios2-tdep.c nios2-linux-tdep.c \ nbsd-nat.c nbsd-tdep.c obsd-tdep.c \ solib-osf.c \ Index: configure.tgt =====================</pre> Kevin Buettner 2013-05-17T03:00:50 http://comments.gmane.org/gmane.comp.gdb.patches/86655 <pre>Hi, When I am reading the hardware watchpoint code, I find a line of comment looks in a wrong place. After check the mail archives, I find that Michael proposed a patch &lt;http://sourceware.org/ml/gdb-patches/2011-02/msg00803.html&gt; to document the fall-through in gdb/i386-nat.c and Pedro suggested to do the same to gdbserver/i386-low.c as it is duplicated of i386-nat.c. Michael committed the change in gdbserver/i386-low.c &lt;http://sourceware.org/ml/gdb-patches/2011-02/msg00847.html&gt;, but it was in a wrong place. This patch is to fix it. Committed. gdb/gdbserver: 2013-05-17 Yao Qi &lt;yao&lt; at &gt;codesourcery.com&gt; * i386-low.c (i386_length_and_rw_bits): Move the comment to the right place. --- gdb/gdbserver/i386-low.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/gdb/gdbserver/i386-low.c b/gdb/gdbserver/i386-low.c index 4ec41fc..86ec5d8 100644 --- a/gdb/gdbserver/i386-low.c +++ b/gdb/gdbserver/i386-low.c &lt; at &gt;&lt; at &gt; -243,10 +243,10 &lt; at &gt;&lt; at &gt; Invalid hardware breakpoint type %d in i386_length_and_rw_b</pre> Yao Qi 2013-05-17T02:03:01 http://comments.gmane.org/gmane.comp.gdb.patches/86654 <pre>This patch adds a simulator for the TI MSP430 and MSP430X. DJ Delorie wrote most of this code. Other contributors include Nick Clifton and me. I'll make sure that the ChangeLog entries show this when it goes in. Comments? sim/ChangeLog: * msp430: New Directory. * configure.tgt: Add it. * configure: Regenerate. sim/common/ChangeLog: * gennltvals.sh: Add msp430 support. * nltvals.def: Regenerate. sim/msp430/ChangeLog: * Makefile.in: New. * aclocal.m4: New. * config.in: New. * configure.ac: New. * configure: Generate. * msp430-sim.c: New. * msp430-sim.h: New. * sim-main.h: New. * trace.c: New. * trace.h: New. Index: configure =================================================================== RCS file: /cvs/src/src/sim/configure,v retrieving revision 1.39 diff -u -p -w -r1.39 configure --- configure15 Jun 2012 17:19:56 -00001.39 +++ configure17 May 2013 00:48:27 -0000 &lt; at &gt;&lt; at &gt; -652,6 +652,7 &lt; at &gt;&lt; at &gt; microblaze mips mn10300 moxie +msp430 rl78 rx sh64 &lt; at &gt;&lt; at &gt; -3768,6 +3769,13 &lt; at &gt;&lt; at &gt; subdirs="$subdir</pre> Kevin Buettner 2013-05-17T00:53:00 http://comments.gmane.org/gmane.comp.gdb.patches/86645 <pre>[I'm cc'ing Joel on this, since I believe this is the same assertion failure that he is seeing.] While testing insight, I ran across the following assertion: ../../gdb/gdb/cleanups.c:264: internal-error: restore_my_cleanups: Assertion `*pmy_chain == SENTINEL_CLEANUP' failed. This is caused by a dangling cleanup in find_frame_funname, which uses a (dangling) cleanup to free memory for the returned function name in some instances. I've corrected this by simply requiring the caller to free any memory. Unfortunately, I don't have a test case to trigger the failure. Perhaps Joel can describe an ada test case? This patch definitely needs a few fresh eyeballs... Keith ChangeLog 2013-05-16 Keith Seitz &lt;keiths&lt; at &gt;redhat.com&gt; * ada-lang.c (is_known_support_routine): Add explicit free of 'func_name' from find_frame_funname. (ada_unhandled_exception_name_addr_from_raise): Likewise. * python/py-frame.c (frapy_name): Likewise for 'name'. * stack.c (find_frame_funname): Add comment explaining that funcp </pre> Keith Seitz 2013-05-16T19:25:07 http://comments.gmane.org/gmane.comp.gdb.patches/86638 <pre>Hi, Given the discussion yesterday on this, here is a patch to convert the test I committed yesterday to use gdb_test_multiple instead of gdb_expect. Ok? Keith PS. I apparently neglected to commit my original ChangeLog entry for this patch. I will commit that (in its proper place) with this patch. testsuite/ChangeLog 2013-05-16 Keith Seitz &lt;keiths&lt; at &gt;redhat.com&gt; * gdb.base/filesym.exp: Use gdb_test_multiple insteadc of gdb_expect. Index: testsuite/gdb.base/filesym.exp =================================================================== RCS file: /cvs/src/src/gdb/testsuite/gdb.base/filesym.exp,v retrieving revision 1.1 diff -u -p -r1.1 filesym.exp --- testsuite/gdb.base/filesym.exp15 May 2013 21:21:05 -00001.1 +++ testsuite/gdb.base/filesym.exp16 May 2013 17:56:31 -0000 &lt; at &gt;&lt; at &gt; -26,25 +26,21 &lt; at &gt;&lt; at &gt; if {[prepare_for_testing $testfile.exp $ # complete to "filesym"; completing again, we expect the symbol name and the # filename (in that order). +set tst "complete on \"filesy\"" send_gdb "break filesy\t</pre> Keith Seitz 2013-05-16T18:00:12 http://comments.gmane.org/gmane.comp.gdb.patches/86620 <pre>Hi all, This is an updated version of a patch series I posted last year (I underestimated the disruption a baby can bring to your life!) The series implements an improved interface between glibc and GDB which significantly improves performance and fixes the following bug: https://bugzilla.redhat.com/show_bug.cgi?id=658851 http://sources.redhat.com/bugzilla/show_bug.cgi?id=2328 "_dl_debug_state() RT_CONSISTENT called too early" The existing linker-debugger interface has a structure (r_debug) containing a list of loaded libraries, and an empty function (_dl_debug_state) for debuggers to set breakpoints on and which the linker calls both before and after modifying this list. The problems with the current interface are as follows: - There is one place where glibc calls _dl_debug_state earlier than Solaris libc. This is PR 2328. The discrepancy means GDB reports libraries as loaded and ready before they really are. - There is also no provision for communicating what (if anything) has </pre> Gary Benson 2013-05-16T14:43:40 http://comments.gmane.org/gmane.comp.gdb.patches/86605 <pre> One of the things I have noticed with frame filters is a significant penalty when printing backtraces. This is because the frame filters invalidate the frame_stash. The reason for this is as follows. Python frames do not store the GDB frame, nor should they. If they did, every time the frame cache is invalidated the Python object would be pointing to the memory freed by the invalidated frame. What Python frames do store is the frame_id. This is permanent, and allows Python to fetch the frame on demand. This on-demand nature is facilitated by a macro in the Python code: FRAPY_REQUIRE_VALID which fetches the frame with frame_find_by_id. All Python frame functions call this macro, and thus, all Python frame functions end up using frame_find_by_id before each operation. That's fine until you consider that Python frames almost act like a random access method of fetching frames, and the existing frame_stash being a single entry stash cannot cope with this. On single or occasional frame access this is</pre> Phil Muldoon 2013-05-16T13:09:28 http://comments.gmane.org/gmane.comp.gdb.patches/86588 <pre>This is the start of the next step for branch tracing support. This series adds support for the "record goto" command for the btrace record target. It allows navigating to a place in the recorded execution log and printing the back trace at this point. There are a number of opens wrt unwinding listed in the last patch of the series, which makes this more an RFC than a real PATCH series, I suppose. It also changes the existing "record function-call-history" and "record instruction-history" commands slightly and fixes PR/15240. The "record function-call-history" command can now show the call relationship like this: (gdb) record function-call-history /cli 12 fib inst 101,111 at src/fib.c:3,7 13 fib inst 112,124 at src/fib.c:3,8 14 fib inst 125,129 at src/fib.c:7 15 fib inst 130,142 at src/fib.c:3,8 16 fib inst 143,147 at src/fib.c:7,8 17 fib inst 148,152 at src/fib.c:7,8 18 fib inst 153,157 at src/fib.c:7 1</pre> Markus Metzger 2013-05-16T11:28:40 http://comments.gmane.org/gmane.comp.gdb.patches/86580 <pre>2013-05-16 Pedro Alves &lt;palves&lt; at &gt;redhat.com&gt; * gdb.ada/complete.exp (test_gdb_no_completion): Fix typo in comment. Use gdb_test_no_output. --- gdb/testsuite/gdb.ada/complete.exp | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/gdb/testsuite/gdb.ada/complete.exp b/gdb/testsuite/gdb.ada/complete.exp index 973e20b..08238f3 100644 --- a/gdb/testsuite/gdb.ada/complete.exp +++ b/gdb/testsuite/gdb.ada/complete.exp &lt; at &gt;&lt; at &gt; -38,13 +38,10 &lt; at &gt;&lt; at &gt; proc test_gdb_complete { expr expected_output } { } # A convenience function that verifies that the "complete EXPR" command -# does not genearte any output. +# does not generate any output. proc test_gdb_no_completion { expr } { - # FIXME: brobecker/2007-12-27: How do you verify that the command - # output is actually really empty??? For now, the following does - # not verify this at all: - test_gdb_complete "$expr" "" + gdb_test_no_output "complete p $expr" } # A convenience function that joins all the arguments together, </pre> Pedro Alves 2013-05-16T10:17:11 http://comments.gmane.org/gmane.comp.gdb.patches/86569 <pre>Hello, I noticed an internal-warning when trying the completion when in Ada mode: (gdb) b simple&lt;TAB&gt; /[...]/cleanups.c:265: internal-warning: restore_my_cleanups has found a stale cleanup A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) The problem is a missing do_cleanups in ada_make_symbol_completion_list, fixed thusly. gdb/ChangeLog: * ada-lang.c (ada_make_symbol_completion_list): Make sure all cleanups are done before returning from this function. gdb/testsuite/ChangeLog: * gdb.ada/complete.exp: Add test verifying completion using the "tab" key. Tested on x86_64-linux, checked in. --- gdb/ChangeLog | 5 +++++ gdb/ada-lang.c | 2 ++ gdb/testsuite/ChangeLog | 5 +++++ gdb/testsuite/gdb.ada/complete.exp | 17 ++++++++++++++++- 4 files changed, 28 insertions(+), 1 deletion(-) diff --git a/gdb/ChangeLog b/gdb/Ch</pre> Joel Brobecker 2013-05-16T07:04:18 http://comments.gmane.org/gmane.comp.gdb.patches/86562 <pre>625a626,631 gdb/rs6000-aix-tdep.c:780: #include &lt;stddef.h&gt; gdb/rs6000-aix-tdep.c:781: #include &lt;stdio.h&gt; gdb/rs6000-aix-tdep.c:782: #define __LDINFO_PTRACE32__ gdb/rs6000-aix-tdep.c:783: #define __LDINFO_PTRACE64__ gdb/rs6000-aix-tdep.c:784: #include &lt;sys/ldr.h&gt; gdb/rs6000-aix-tdep.c:795: #define pinfo(type,member) { struct type ldi = {0}; printf (', offsetof (struct type, member), sizeof (ldi.member), #member); } while (0) </pre> GDB Administrator 2013-05-16T01:51:20 http://comments.gmane.org/gmane.comp.gdb.patches/86549 <pre>This patch improves the accuracy of skip_prologue, which is used to skip the prologue of a function if no debug info is provided. The problem is with code like this: 10000478 &lt;f&gt;: void f(int a, int b, int c, int d, int e, int f, int g, int h) { 10000478: 94 21 ff c0 stwu r1,-64(r1) 1000047c: 93 e1 00 3c stw r31,60(r1) 10000480: 7c 3f 0b 78 mr r31,r1 10000484: 90 7f 00 18 stw r3,24(r31) 10000488: 90 9f 00 1c stw r4,28(r31) 1000048c: 90 bf 00 20 stw r5,32(r31) 10000490: 90 df 00 24 stw r6,36(r31) 10000494: 90 ff 00 28 stw r7,40(r31) 10000498: 91 1f 00 2c stw r8,44(r31) 1000049c: 91 3f 00 30 stw r9,48(r31) 100004a0: 91 5f 00 34 stw r10,52(r31) int x = 1; 100004a4: 39 20 00 01 li r9,1 100004a8: 91 3f 00 08 stw r9,8(r31) } 100004ac: 39 7f 00 40 addi r11,r31,64 100004b0: 83 eb ff fc lwz r31,-4(r11) 10</pre> Kwok Cheung Yeung 2013-05-15T18:01:31 http://comments.gmane.org/gmane.comp.gdb.patches/86528 <pre>GDB currently has a problem with setting breakpoints on or stepping into variadic functions on 32-bit PowerPC architectures. e.g. void f(int x, ...) { } int main(void) { f (0, 1); f (0, 1.0); } compiles (with gcc -g -O0) to: 10000478 &lt;f&gt;: void f(int x, ...) { 10000478: 94 21 ff 80 stwu r1,-128(r1) 1000047c: 93 e1 00 7c stw r31,124(r1) 10000480: 7c 3f 0b 78 mr r31,r1 10000484: 90 9f 00 0c stw r4,12(r31) 10000488: 90 bf 00 10 stw r5,16(r31) 1000048c: 90 df 00 14 stw r6,20(r31) 10000490: 90 ff 00 18 stw r7,24(r31) 10000494: 91 1f 00 1c stw r8,28(r31) 10000498: 91 3f 00 20 stw r9,32(r31) 1000049c: 91 5f 00 24 stw r10,36(r31) 100004a0: 40 86 00 24 bne cr1,100004c4 &lt;f+0x4c&gt; 100004a4: d8 3f 00 28 stfd f1,40(r31) 100004a8: d8 5f 00 30 stfd f2,48(r31) 100004ac: d8 7f 00 38 stfd f3,56(r31) 100004b0: d8 9f 00 40 </pre> Kwok Cheung Yeung 2013-05-15T14:18:00 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.gdb.patches