public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
* issue with conditional breakpoint
@ 2014-12-15 23:30 Javier Aguinaga
  2014-12-30 17:15 ` Doug Evans
  0 siblings, 1 reply; 2+ messages in thread
From: Javier Aguinaga @ 2014-12-15 23:30 UTC (permalink / raw)
  To: gdb

Hi guys, I'm new in gdb. The issue is the following

I'm trying to debug qemu, specificly I want to stop in the open
syscall when the argument is "/proc/meminfo", I tried the following
without successfull:

$ gdb qemu
gdb$ catch syscall open
Catchpoint 1 (syscall 'open' [2])
gdb$ cond 1 strcmp("/proc/meminfo", (char*)($rdi)) == 0
gdb$ r
-----------------------------------------------------------------------------------------------------------------------[regs]
  RAX: 0x00007FFFF7FFA4A0  RBX: 0x0000555555562AA1  RBP:
0x00007FFFFFFFD8C8  RSP: 0x00007FFFFFFFD8D0  o d I t s z a P c
  RDI: 0xFFFFFFFFFFFFFFF8  RSI: 0x000000000000000E  RDX:
0xFFFF800008005B60  RCX: 0x00007FFFF7FFA4AE  RIP: 0x00005555555FE644
  R8 : 0x00007FFFF7FFE570  R9 : 0x0000000000000000  R10:
0xFFFFFFFFFFFFFFB0  R11: 0x0000000000000246  R12: 0x00007FFFF7FFE090
  R13: 0x00007FFFF7FFD040  R14: 0x0000000000000000  R15: 0x00007FFFF7FFE570
  CS: 0033  DS: 0000  ES: 0000  FS: 0000  GS: 0000  SS: 002B
-----------------------------------------------------------------------------------------------------------------------[code]
=> 0x5555555fe644: xor    ebp,ebp
   0x5555555fe646: mov    r9,rdx
   0x5555555fe649: pop    rsi
   0x5555555fe64a: mov    rdx,rsp
   0x5555555fe64d: and    rsp,0xfffffffffffffff0
   0x5555555fe651: push   rax
   0x5555555fe652: push   rsp
   0x5555555fe653: mov    r8,QWORD PTR [rip+0x6c630e]        # 0x555555cc4968
-----------------------------------------------------------------------------------------------------------------------------

Program received signal SIGSEGV, Segmentation fault.
-----------------------------------------------------------------------------------------------------------------------[regs]
  RAX: 0x0000000000000000  RBX: 0x0000555555562AA1  RBP:
0x00007FFFFFFFD8C8  RSP: 0x00007FFFFFFFD8C8  o d I t s Z a P c
  RDI: 0x00007FFFF7FFA4A0  RSI: 0x00007FFFF7DF72D0  RDX:
0x0000000000000001  RCX: 0xFFFFFFFFFFFFFFFF  RIP: 0x00000000000A07F0
  R8 : 0x00007FFFF7FFE570  R9 : 0x0000000000000000  R10:
0xFFFFFFFFFFFFFFB0  R11: 0x0000000000000246  R12: 0x00007FFFF7FFE090
  R13: 0x00007FFFF7FFD040  R14: 0x0000000000000000  R15: 0x00007FFFF7FFE570
  CS: 0033  DS: 0000  ES: 0000  FS: 0000  GS: 0000  SS: 002B Error
while running hook_stop:
Cannot access memory at address 0xa07f0
0x00000000000a07f0 in ?? ()
Error in testing breakpoint condition:
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on".
Evaluation of the expression containing the function
(at 0x0xa07f0) will be abandoned.
When the function is done executing, GDB will silently stop.
-----------------------------------------------------------------------------------------------------------------------[regs]
  RAX: 0x0000000000000000  RBX: 0x0000555555562AA1  RBP:
0x00007FFFFFFFD8C8  RSP: 0x00007FFFFFFFD8C8  o d I t s Z a P c
  RDI: 0x00007FFFF7FFA4A0  RSI: 0x00007FFFF7DF72D0  RDX:
0x0000000000000001  RCX: 0xFFFFFFFFFFFFFFFF  RIP: 0x00000000000A07F0
  R8 : 0x00007FFFF7FFE570  R9 : 0x0000000000000000  R10:
0xFFFFFFFFFFFFFFB0  R11: 0x0000000000000246  R12: 0x00007FFFF7FFE090
  R13: 0x00007FFFF7FFD040  R14: 0x0000000000000000  R15: 0x00007FFFF7FFE570
  CS: 0033  DS: 0000  ES: 0000  FS: 0000  GS: 0000  SS: 002B Error
while running hook_stop:
Cannot access memory at address 0xa07f0

Catchpoint 1 (returned from syscall munmap), 0x00000000000a07f0 in ?? ()
gdb$

GDB stop in the condition (x/1s $rdi ==> "/proc/meminfo") but after
that I can't continue

My machine is a Debian x86_64, and I probe with v7.4 and v7.8

Anyone knows what is the problem?

P.S.: with "call strcmp("foo","foo")" I have:
(gdb) call strcmp("foo","foo")

Program received signal SIGSEGV, Segmentation fault.
0x00000000000a07f6 in ?? ()
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on".
Evaluation of the expression containing the function
(strcmp@plt) will be abandoned.
When the function is done executing, GDB will silently stop.
(gdb)

Regards

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: issue with conditional breakpoint
  2014-12-15 23:30 issue with conditional breakpoint Javier Aguinaga
@ 2014-12-30 17:15 ` Doug Evans
  0 siblings, 0 replies; 2+ messages in thread
From: Doug Evans @ 2014-12-30 17:15 UTC (permalink / raw)
  To: Javier Aguinaga; +Cc: gdb

On Mon, Dec 15, 2014 at 3:30 PM, Javier Aguinaga
<javier.4guinaga@gmail.com> wrote:
> Hi guys, I'm new in gdb. The issue is the following
>
> I'm trying to debug qemu, specificly I want to stop in the open
> syscall when the argument is "/proc/meminfo", I tried the following
> without successfull:
>
> $ gdb qemu
> gdb$ catch syscall open
> Catchpoint 1 (syscall 'open' [2])
> gdb$ cond 1 strcmp("/proc/meminfo", (char*)($rdi)) == 0
> gdb$ r
> -----------------------------------------------------------------------------------------------------------------------[regs]
>   RAX: 0x00007FFFF7FFA4A0  RBX: 0x0000555555562AA1  RBP:
> 0x00007FFFFFFFD8C8  RSP: 0x00007FFFFFFFD8D0  o d I t s z a P c
>   RDI: 0xFFFFFFFFFFFFFFF8  RSI: 0x000000000000000E  RDX:
> 0xFFFF800008005B60  RCX: 0x00007FFFF7FFA4AE  RIP: 0x00005555555FE644
>   R8 : 0x00007FFFF7FFE570  R9 : 0x0000000000000000  R10:
> 0xFFFFFFFFFFFFFFB0  R11: 0x0000000000000246  R12: 0x00007FFFF7FFE090
>   R13: 0x00007FFFF7FFD040  R14: 0x0000000000000000  R15: 0x00007FFFF7FFE570
>   CS: 0033  DS: 0000  ES: 0000  FS: 0000  GS: 0000  SS: 002B
> -----------------------------------------------------------------------------------------------------------------------[code]
> => 0x5555555fe644: xor    ebp,ebp
>    0x5555555fe646: mov    r9,rdx
>    0x5555555fe649: pop    rsi
>    0x5555555fe64a: mov    rdx,rsp
>    0x5555555fe64d: and    rsp,0xfffffffffffffff0
>    0x5555555fe651: push   rax
>    0x5555555fe652: push   rsp
>    0x5555555fe653: mov    r8,QWORD PTR [rip+0x6c630e]        # 0x555555cc4968
> -----------------------------------------------------------------------------------------------------------------------------
>
> Program received signal SIGSEGV, Segmentation fault.
> -----------------------------------------------------------------------------------------------------------------------[regs]
>   RAX: 0x0000000000000000  RBX: 0x0000555555562AA1  RBP:
> 0x00007FFFFFFFD8C8  RSP: 0x00007FFFFFFFD8C8  o d I t s Z a P c
>   RDI: 0x00007FFFF7FFA4A0  RSI: 0x00007FFFF7DF72D0  RDX:
> 0x0000000000000001  RCX: 0xFFFFFFFFFFFFFFFF  RIP: 0x00000000000A07F0
>   R8 : 0x00007FFFF7FFE570  R9 : 0x0000000000000000  R10:
> 0xFFFFFFFFFFFFFFB0  R11: 0x0000000000000246  R12: 0x00007FFFF7FFE090
>   R13: 0x00007FFFF7FFD040  R14: 0x0000000000000000  R15: 0x00007FFFF7FFE570
>   CS: 0033  DS: 0000  ES: 0000  FS: 0000  GS: 0000  SS: 002B Error
> while running hook_stop:
> Cannot access memory at address 0xa07f0
> 0x00000000000a07f0 in ?? ()
> Error in testing breakpoint condition:
> The program being debugged was signaled while in a function called from GDB.
> GDB remains in the frame where the signal was received.
> To change this behavior use "set unwindonsignal on".
> Evaluation of the expression containing the function
> (at 0x0xa07f0) will be abandoned.
> When the function is done executing, GDB will silently stop.
> -----------------------------------------------------------------------------------------------------------------------[regs]
>   RAX: 0x0000000000000000  RBX: 0x0000555555562AA1  RBP:
> 0x00007FFFFFFFD8C8  RSP: 0x00007FFFFFFFD8C8  o d I t s Z a P c
>   RDI: 0x00007FFFF7FFA4A0  RSI: 0x00007FFFF7DF72D0  RDX:
> 0x0000000000000001  RCX: 0xFFFFFFFFFFFFFFFF  RIP: 0x00000000000A07F0
>   R8 : 0x00007FFFF7FFE570  R9 : 0x0000000000000000  R10:
> 0xFFFFFFFFFFFFFFB0  R11: 0x0000000000000246  R12: 0x00007FFFF7FFE090
>   R13: 0x00007FFFF7FFD040  R14: 0x0000000000000000  R15: 0x00007FFFF7FFE570
>   CS: 0033  DS: 0000  ES: 0000  FS: 0000  GS: 0000  SS: 002B Error
> while running hook_stop:
> Cannot access memory at address 0xa07f0
>
> Catchpoint 1 (returned from syscall munmap), 0x00000000000a07f0 in ?? ()
> gdb$
>
> GDB stop in the condition (x/1s $rdi ==> "/proc/meminfo") but after
> that I can't continue
>
> My machine is a Debian x86_64, and I probe with v7.4 and v7.8
>
> Anyone knows what is the problem?
>
> P.S.: with "call strcmp("foo","foo")" I have:
> (gdb) call strcmp("foo","foo")
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00000000000a07f6 in ?? ()
> The program being debugged was signaled while in a function called from GDB.
> GDB remains in the frame where the signal was received.
> To change this behavior use "set unwindonsignal on".
> Evaluation of the expression containing the function
> (strcmp@plt) will be abandoned.
> When the function is done executing, GDB will silently stop.
> (gdb)
>
> Regards

Hi.
I'll address the strcmp segv in another email, I'm travelling at the
moment, but two things occur to me off the top of my head.

1) in order for a function call with a string argument to work gdb has
to malloc space for the string and copy the string to the malloc'd
memory.  There is no mechanism for automagically freeing this memory
(at least none that I'm aware of) so using strcmp as a breakpoint
condition will leak memory.  That's not necessarily a bad thing,
especially if it helps one find the problem, but it is something to be
aware of.

2) there is the $_streq convenience function:

(gdb) cond 1 $_streq("/proc/meminfo", (char*)($rdi))

$_streq is implemented in Python and comes with recent gdbs (and thus
requires gdb to be built with python support).  There are two nice
properties of $_streq:
a) no inferior function calls, which can perturb inferior state in
undesirable ways
b) no leakage of memory

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2014-12-30 17:15 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-12-15 23:30 issue with conditional breakpoint Javier Aguinaga
2014-12-30 17:15 ` Doug Evans

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).