* GDB 7.4.91 available for testing @ 2012-07-18 16:34 Joel Brobecker 2012-07-19 13:44 ` Mike Frysinger 2012-07-19 23:02 ` Philippe Waroquiers 0 siblings, 2 replies; 8+ messages in thread From: Joel Brobecker @ 2012-07-18 16:34 UTC (permalink / raw) To: gdb Hello, I have just finished creating the gdb-7.4.91 pre-release. It is available for download at the following location: ftp://sourceware.org/pub/gdb/snapshots/branch/gdb-7.4.91.tar.bz2 A gzip'ed version is also available: gdb-7.4.91.tar.gz. Please give it a test if you can and report any problems you might find. On behalf of all the GDB contributors, thank you! -- Joel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: GDB 7.4.91 available for testing 2012-07-18 16:34 GDB 7.4.91 available for testing Joel Brobecker @ 2012-07-19 13:44 ` Mike Frysinger 2012-07-19 23:02 ` Philippe Waroquiers 1 sibling, 0 replies; 8+ messages in thread From: Mike Frysinger @ 2012-07-19 13:44 UTC (permalink / raw) To: gdb [-- Attachment #1: Type: Text/Plain, Size: 728 bytes --] On Wednesday 18 July 2012 12:34:13 Joel Brobecker wrote: > I have just finished creating the gdb-7.4.91 pre-release. > It is available for download at the following location: > > ftp://sourceware.org/pub/gdb/snapshots/branch/gdb-7.4.91.tar.bz2 > > A gzip'ed version is also available: gdb-7.4.91.tar.gz. > > Please give it a test if you can and report any problems you might find. seems ok for sim and these targets: arm-elf avr-elf bfin-elf cr16-elf cris-elf d10v-elf frv-elf h8300-elf iq2000-elf lm32-elf m32c-elf m32r-elf m68hc11-elf mcore-elf microblaze-elf mips-elf mn10300-elf moxie-elf ppc-elf rl78-elf rx-elf sh64-elf sh-elf sparc-elf v850-elf -mike [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: GDB 7.4.91 available for testing 2012-07-18 16:34 GDB 7.4.91 available for testing Joel Brobecker 2012-07-19 13:44 ` Mike Frysinger @ 2012-07-19 23:02 ` Philippe Waroquiers 2012-07-20 7:12 ` Jan Kratochvil 1 sibling, 1 reply; 8+ messages in thread From: Philippe Waroquiers @ 2012-07-19 23:02 UTC (permalink / raw) To: Joel Brobecker; +Cc: gdb On Wed, 2012-07-18 at 09:34 -0700, Joel Brobecker wrote: > Hello, > > I have just finished creating the gdb-7.4.91 pre-release. > It is available for download at the following location: > > ftp://sourceware.org/pub/gdb/snapshots/branch/gdb-7.4.91.tar.bz2 > > A gzip'ed version is also available: gdb-7.4.91.tar.gz. > > Please give it a test if you can and report any problems you might find. The new version causes a regression with the Valgrind gdbserver. At least on x86 and on amd64, the Valgrind regression tests for inferior calls in the Valgrind gdbserver are failing as Valgrind reports errors such as: vex x86->IR: unhandled instruction bytes: 0xF 0x21 0x0 0xC0. (inferior calls are working with GDB 7.4). I believe this difference is caused by the fact that infcall.c has switched from AT_ENTRY_POINT to ON_STACK technique for the breakpoint for the fake return address of the pushed function call. The Valgrind gdbserver is handling Z0 and Z1 packets to insert breakpoints. So, GDB inserts a breakpoint on the stack using a Z0 packet. However, from what I can see, no 0xcc instruction has been written on the stack by GDB. When a function call returns, Valgrind translates and instrument (if not yet done) the instructions at the return address. (if there is a break at this address, the instrumented code will start with a call to a Valgrind helper function which reports the breakpoint to GDB and reads remote protocol packets). In case of the fake return address on the stack, I believe no instruction was effectively written by GDB (i.e. no 0xcc was written). So, when the return instruction of the pushed fn call is executed, Valgrind tries to translate and instrument what is on the stack at the return address, and then finds whatever random or invalid instruction bytes and then reports the above error. I do not see a clean/easy way to solve this problem. The only way I see (quite ugly, machine dependent, ...) will be for Valgrind gdbserver to guess that a breakpoint on the stack (when the stack was just increased before by changing sp) implies to write a valid dummy instruction on the stack to allow the Valgrind translator to work properly. It is not yet clear how to implement the above guess properly, and I do not like the idea to have Valgrind gdbserver writing itself dummy or break instructions on the stack (such work/knowledge is better done by GDB). Is there anything easier which could be done at GDB and/or by having Valgrind gdbserver handling differently some protocol packets ? (of course, I suppose there was a very good reason to switch to ON_STACK technique and that switching back is not an option). Philippe ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: GDB 7.4.91 available for testing 2012-07-19 23:02 ` Philippe Waroquiers @ 2012-07-20 7:12 ` Jan Kratochvil 2012-07-20 20:49 ` Philippe Waroquiers 0 siblings, 1 reply; 8+ messages in thread From: Jan Kratochvil @ 2012-07-20 7:12 UTC (permalink / raw) To: Philippe Waroquiers; +Cc: Joel Brobecker, gdb On Fri, 20 Jul 2012 01:03:36 +0200, Philippe Waroquiers wrote: > The Valgrind gdbserver is handling Z0 and Z1 packets to insert > breakpoints. So, GDB inserts a breakpoint on the stack using > a Z0 packet. However, from what I can see, no 0xcc instruction > has been written on the stack by GDB. The Z0 packet instructs gdbserver to put 0xcc there, linux-x86-low.c:x86_breakpoint. gdbserver does it. Thanks, Jan ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: GDB 7.4.91 available for testing 2012-07-20 7:12 ` Jan Kratochvil @ 2012-07-20 20:49 ` Philippe Waroquiers 2012-07-22 17:31 ` Jan Kratochvil 0 siblings, 1 reply; 8+ messages in thread From: Philippe Waroquiers @ 2012-07-20 20:49 UTC (permalink / raw) To: Jan Kratochvil; +Cc: Joel Brobecker, gdb On Fri, 2012-07-20 at 09:11 +0200, Jan Kratochvil wrote: > On Fri, 20 Jul 2012 01:03:36 +0200, Philippe Waroquiers wrote: > > The Valgrind gdbserver is handling Z0 and Z1 packets to insert > > breakpoints. So, GDB inserts a breakpoint on the stack using > > a Z0 packet. However, from what I can see, no 0xcc instruction > > has been written on the stack by GDB. > > The Z0 packet instructs gdbserver to put 0xcc there, > linux-x86-low.c:x86_breakpoint. gdbserver does it. Thanks for the clarification. I now understand that my expectation to have GDB writing 0xCC was quite wrong: if GDB would be responsible to write 0xCC, then why would a Z0 packet be needed ? Note that I am wondering how this ON_STACK technique works. E.g. on gcc20, readelf -a indicates the GNU_STACK is RW, but not E or X or similar. In any case, with this better understanding, I see no other solution than to have the Valgrind gdbserver writing a breakpoint instruction at the Z0 provided address (even if with the current technique Valgrind gdbserver uses to implement breakpoints, this instruction will in fact never be executed but only translated). The tricky part will be to guess that a breakpoint is for the 'return address for an inferior call', as Valgrind is not expected (or allowed) to modify the code sections of the guest client being executed. For this guess, I am thinking to use the following conditions: 1. the stack pointer in the register cache has been changed to grow the stack and 2. the breakpoint address is in this "grown zone" Comments/feedback on the above ? Thanks Philippe ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: GDB 7.4.91 available for testing 2012-07-20 20:49 ` Philippe Waroquiers @ 2012-07-22 17:31 ` Jan Kratochvil 2012-07-22 19:01 ` Philippe Waroquiers 0 siblings, 1 reply; 8+ messages in thread From: Jan Kratochvil @ 2012-07-22 17:31 UTC (permalink / raw) To: Philippe Waroquiers; +Cc: Joel Brobecker, gdb, Pedro Alves On Fri, 20 Jul 2012 22:50:09 +0200, Philippe Waroquiers wrote: > Note that I am wondering how this ON_STACK technique works. > E.g. on gcc20, readelf -a indicates the GNU_STACK is RW, but not E or X > or similar. Then it may be for example SIGSEGV instead of SIGTRAP but GDB recognizes any such trap on breakpoint address as a breakpoint hit. > The tricky part will be to guess that a breakpoint is for the > 'return address for an inferior call', as Valgrind is not expected > (or allowed) to modify the code sections of the guest client being > executed. As Z0 should insert the 0xcc instruction this issue of never-modified inferior memory needs to be resolved anyway: (gdb) monitor help general valgrind monitor commands: [...] (gdb) maintenance info breakpoints Num Type Disp Enb Address What -1 shlib events keep n 0x0000000004003702 <dl_main+6562> inf 1 -2 shlib events keep y 0x0000000004003f92 <dl_main+8754> inf 1 [...] (gdb) set debug remote 1 (gdb) stepi Sending packet: $Z0,4003f92,1#ab...Packet received: OK Packet Z0 (software-breakpoint) is supported [...] (gdb) show remote Z-packet Support for the `Z0' packet is auto-detected, currently enabled. Maybe it would be enough to treat Z0 packets like Z1 (hardware-breakpoint) packets? The valgrind simulator should be able to trap on specified addresses, shouldn't it? I am not aware how make GDB to automatically use Z1 packets but I do not have an idea why it would hurt if Z0 packets behave like Z1 ones. Just report (on x86*) PC+1 for SIGTRAP during the breakpoint hit. > For this guess, I am thinking to use the following conditions: > 1. the stack pointer in the register cache has been changed > to grow the stack > and > 2. the breakpoint address is in this "grown zone" With current default 'set breakpoint always-inserted auto' (acting like 'off') GDB continually removes and re-inserts all the breakpoints. The "grow" check will not work on breakpoint re-insertions. Thanks, Jan ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: GDB 7.4.91 available for testing 2012-07-22 17:31 ` Jan Kratochvil @ 2012-07-22 19:01 ` Philippe Waroquiers 2012-07-23 7:23 ` Jan Kratochvil 0 siblings, 1 reply; 8+ messages in thread From: Philippe Waroquiers @ 2012-07-22 19:01 UTC (permalink / raw) To: Jan Kratochvil; +Cc: Joel Brobecker, gdb, Pedro Alves On Sun, 2012-07-22 at 19:30 +0200, Jan Kratochvil wrote: > On Fri, 20 Jul 2012 22:50:09 +0200, Philippe Waroquiers wrote: > > The tricky part will be to guess that a breakpoint is for the > > 'return address for an inferior call', as Valgrind is not expected > > (or allowed) to modify the code sections of the guest client being > > executed. > > As Z0 should insert the 0xcc instruction this issue of never-modified inferior > memory needs to be resolved anyway: Currently, Valgrind does not (and cannot) modify the guest code (e.g. as the guest code might not be mapped writable). Also, modifying the guest code for a breakpoint would introduce a lot of difficulties (e.g. the translated code would have to be dropped and re-translated when stepping over the breakpoint, and that is currently not possible). So, breakpoints are implemented in Valgrind by having a helper function call inserted in the translated code as a "preamble" to the instruction at which a breakpoint is placed. E.g. the below is the translated code if there is a break on 0x8048BDA. ------ IMark(0x8048BDA, 7, 0) ------ PUT(68) = 0x8048BDA:I32 DIRTY 1:I1 RdFX-gst(24,4) MoFX-gst(68,4) ::: VG_(helperc_CallDebugger)[rp=1]{0x38072280}(0x8048BDA:I32) t7 = GET:I32(376) t0 = GET:I32(24) ... The PUT(68) is an assignment to the (virtual) program counter register. The helperc fn will indicate to GDB that a breakpoint is encountered, and will read further gdbsrv protocol packets, till a "continue" packet is received (and then the instructions following the helperc are then executed). > Maybe it would be enough to treat Z0 packets like Z1 (hardware-breakpoint) > packets? The valgrind simulator should be able to trap on specified > addresses, shouldn't it? Z0 and Z1 packets are handled the same way by Valgrind gdbserver (see above). The problem with the above technique is that there is no valid instruction at the ON_STACK breakpoint address, and the valgrind translator does not like this. Implementing breakpoints with "real" trap would imply to have the Valgrind encoder/decoder to understand the gdbserver breakpoint concept, which is not ok with regards to software dependencies. > > For this guess, I am thinking to use the following conditions: > > 1. the stack pointer in the register cache has been changed > > to grow the stack > > and > > 2. the breakpoint address is in this "grown zone" > > With current default 'set breakpoint always-inserted auto' (acting like 'off') > GDB continually removes and re-inserts all the breakpoints. The "grow" check > will not work on breakpoint re-insertions. The "grow" check just has to work for the ON_STACK breakpoints (as the other "normal" breakpoints are supposed to be done at an address where there is valid code that Valgrind can translate). The "grow" check is also only done if GDB has modified the stack pointer register (e.g. using a "P" packet) between the "stop" and "continue". So, normal stack growth (during execution) is not taken into account in this guess. I just implemented the "grow" check and tested on the x86/amd64/mips platforms (ppc32/64, s390x and arm seems to be AT_ENTRY_POINT platforms). The Valgrind gdbsrv regression tests are now passing with GDB 7.4.91 without error messages, so it looks at least to improve. The doubt I have is that an inferior function call from GDB might imply several "low level" calls (e.g. first a call to malloc to allocate some memory for the argument(s), followed by the real fn call). Currently, the guess only works for the first low level call. But it looks like the next low level call is using the same return breakpoint address (by chance maybe ?) and so the first guess has placed a 0xcc at this address, and Valgrind translator is happy. Is it by chance that successive low level calls (for the same "user inferior call") are using the same stack address as return address ? Thanks again for the help/explanations about Z0, I was a little bit lost in the GDB behaviour Philippe ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: GDB 7.4.91 available for testing 2012-07-22 19:01 ` Philippe Waroquiers @ 2012-07-23 7:23 ` Jan Kratochvil 0 siblings, 0 replies; 8+ messages in thread From: Jan Kratochvil @ 2012-07-23 7:23 UTC (permalink / raw) To: gdb [ Moved to gdb-patches: [patch] [i386] Put hlt at the ON_STACK breakpoint [Re: GDB 7.4.91 available for testing] http://sourceware.org/ml/gdb-patches/2012-07/msg00436.html ] ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2012-07-23 7:23 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-07-18 16:34 GDB 7.4.91 available for testing Joel Brobecker 2012-07-19 13:44 ` Mike Frysinger 2012-07-19 23:02 ` Philippe Waroquiers 2012-07-20 7:12 ` Jan Kratochvil 2012-07-20 20:49 ` Philippe Waroquiers 2012-07-22 17:31 ` Jan Kratochvil 2012-07-22 19:01 ` Philippe Waroquiers 2012-07-23 7:23 ` Jan Kratochvil
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).