headers
Petr Hluzín | 1 May 2011 03:19
Picon

Re: [PATCH] arm reversible : <phase_2_complete>

On 25 April 2011 16:03, paawan oza <paawan1982 <at> yahoo.com> wrote:
> Hi Petr,
>
> I have implemented your review comments.

Typo "hamdle" in thumb_hamdle_ld_st_stack_insn() still exists.

I decoded the `arm_mem_r *arm_mems' strucutre:

arm_mems[0].len - is number of valid records `arm_mems[i]' after [0].
arm_mems[i].len - is number of bytes modified by the instruction.
arm_mems[0].addr - is undefined (never written, never read) - except
on line: thumb_insn_r->arm_mems[0].addr =
u_buf[0].s_word+u_buf[1].s_word;
arm_mems[i].addr - is target address of the modified block (for i=1..)

This is reusing field arm_mem_r::len for two different things.
This is ugly.

Move the counter into insn_decode_record_t. Or use struct arm_mem_r {
	int count;
	struct {
		uint32_t len;
		CORE_ADDR addr;
	} array[0];
}

Each instance of insn_decode_record_t is allocated and freed before
new instance is allocated, therefore its size does not matter.
(Continue reading)

Permalink | Reply | 17 comments |
headers
Frederic Riss | 2 May 2011 09:30
Picon

Re: Moribund breakpoints and hardware single-step

On 28 April 2011 18:26, Frederic Riss <frederic.riss <at> gmail.com> wrote:
> Hi,
>
> I just debugged a very interesting problem in the moribund breakpoints
> machinery. First I'm working on sources that must be ~ 2 months old. I
> haven't had time upgrading, but from looking at the diff, the current
> GDB master should be subject to the same behavior.

For the record, I reproduced this issue on HEAD with x86_64. It's
quite easy to reproduce, as every 1-byte instruction with cumulative
side-effects (eg a pushd) is a candidate reproducer:

-------------------8<-----------------------------------8<----------------------------
$ gcc -g -fno-omit-frame-pointer ../gdb/testsuite/gdb.base/recurse.c
$ ./gdb/gdbserver/gdbserver :10000 ./a.out &
[1] 30543
Process ./a.out created; pid = 30548
Listening on port 10000
$ ./gdb/gdb a.out --silent
Reading symbols from /tmp/gdb/build/a.out...done.
(gdb) set target-async
(gdb) set non-stop
(gdb) tar extended-remote :10000
Remote debugging using :10000
Remote debugging from host 127.0.0.1
[New Thread 30548.30548]
(gdb)
[Thread 30548.30548] #1 stopped.
0x0000003eac400b20 in ?? ()
tb *main
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tom Tromey | 2 May 2011 15:27
Picon
Favicon

Re: [PATCH] arm reversible : <phase_2_complete>

>>>>> "Oza" == paawan oza <paawan1982 <at> yahoo.com> writes:

Oza> So you are suggesting;
Oza> GET_REG_VAL (reg_cache, ARM_PC_REGNUM, &u_buf.buf[0]);
Oza> if (target is big endian)
Oza>   {
Oza>         convert_big_to_little (u_buf.s_word)
Oza>   }
Oza> something like above ?
Oza> right ?

More or less, but if you use the existing functions like
extract_unsigned_integer or extract_typed_address, then they
will handle all the details.

Oza> and while replaying do I need to convert it to big endian ?
Oza> somethig like that ?

It depends on what you are doing.

If you are doing calculations on some number, then you have to extract
it properly so that the host math works correctly.  If you are just
storing some data to be restored verbatim, then you don't need to
convert at all.

Tom
Permalink | Reply | 0 comments |
headers
Klaus Rudolph | 2 May 2011 15:55
Picon
Picon

pretty printing with python

Hi all,

I want to start with writing a pretty printer for gdb, but can't find a startup for my own printer.

First: All example contains a line
import gdb.printing
But this results in 
Traceback (most recent call last):
  File "/home/krud/projekte/myppc8000/ppc_8000_938/test.py", line 3, in <module>
    import gdb.printing
ImportError: No module named printing

Must I write that file (which?) myself. Is there an extra download for the printers? Could I install some
additional stuff?

Sorry for my confusion!

I hope you could give me a startpoint for the printer things...

Thanks
 Klaus

--

-- 
NEU: FreePhone - kostenlos mobil telefonieren und surfen!			
Jetzt informieren: http://www.gmx.net/de/go/freephone
Permalink | Reply | 3 comments |
headers
Tom Tromey | 2 May 2011 16:31
Picon
Favicon

Re: pretty printing with python

>>>>> "Klaus" == Klaus Rudolph <lts-rudolph <at> gmx.de> writes:

Klaus> I want to start with writing a pretty printer for gdb, but can't
Klaus> find a startup for my own printer.

Klaus> First: All example contains a line
Klaus> import gdb.printing
Klaus> But this results in 
Klaus> Traceback (most recent call last):
Klaus>   File "/home/krud/projekte/myppc8000/ppc_8000_938/test.py", line 3, in <module>
Klaus>     import gdb.printing
Klaus> ImportError: No module named printing

This means your GDB is too old.  `gdb.printing' is not in any release
yet; it will make its debut in 7.3.

You can write printers so that they work with both the new- and
old-styles here.  The libstdc++ printers do this.

Tom
Permalink | Reply | 2 comments |
headers
Tom Tromey | 2 May 2011 16:46
Picon
Favicon

Re: [PATCH] arm reversible : <phase_2_complete>

>>>>> "Petr" == Petr Hluzín <petr.hluzin <at> gmail.com> writes:

Petr> I also recommend to define a local variable in the smalles scope
Petr> possible, however I understand that many
Petr> programmers use weak tools and knowing its definition requires more
Petr> effort than placing cursor on the variable - therefore they prefer
Petr> definitions at the start of function.

I agree, using the smallest scope is generally preferable.
This practice makes it simpler to reason about the code.

Petr> My IDE has a spellchecker which underlines typos. No effort required.
Petr> (Consider upgrading your tools.)

I'm curious to know what IDE you use for working on GDB.

For those using Emacs, M-x flyspell-prog-mode will spell-check in
comments and strings.

Petr> Also I have no vote in GDB development, so my patch approval would
Petr> have little impact.

I appreciate thoughtful reviews from anyone, regardless of their
official status.  I think GDB patches still spend too much time waiting
for review, and this sort of thing can help speed things up.

Petr> GDB commiters: please reply whether you agree with my review. (So that
Petr> paawan oza does not spend effort in vain.)

I thought it was quite good.  Thanks for doing this.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Francois | 2 May 2011 17:34
Picon

better assembly level debugging

Hello

I'm trying to do some machine code-level debugging using GDB.
Basically, I'm debugging a C application that provides no debugging
symbol.

GDB works greatly, and I think a few customization could make it as
nice as the other popular debugging alternatives for this task (like
OllyDbg for Win32).

- defining labels
reverse engineering is very difficult without debugging symbols. It
would be very handy if I could (like on IDA or OllyDbg) define my own
labels. That would be for example user-defined symbols, which could be
used to get a nicer output.
For example
    set label 0x402000 log_error
would define a new symbol "log_error". Further disassembly of "call
0x402000" instruction, or stepping near this address would give a
cleaner output.

- pretty printer for instructions
GDB could pretty print what it disassembles so that values of operands
are introspected (looking for strings or functions especially)

Let's take an example :

#include <stdio.h>
#include <wchar.h>
int main() {
(Continue reading)

Permalink | Reply | 3 comments |
headers
Klaus Rudolph | 2 May 2011 17:50
Picon
Picon

calling cast operator

Hi all,

can I use a cast operator from an object on gdb?

class B
{
...
};

class A
{
   operator B()
};

anyFunc()
{
   A a;

-> breakpoint
}

how can I get the value of the operation "a.operator B();" on the command line?

print a.operator B() 
is not working...?

Thanks
 Klaus

--

--
(Continue reading)

Permalink | Reply | 2 comments |
headers
André Pönitz | 2 May 2011 18:09
Picon

Re: calling cast operator

On Monday 02 May 2011 17:50:27 ext Klaus Rudolph wrote:
> Hi all,
> 
> can I use a cast operator from an object on gdb?
> 
> class B
> {
> ...
> };
> 
> class A
> {
>    operator B()
> };
> 
> anyFunc()
> {
>    A a;
> 
> -> breakpoint
> }
> 
> how can I get the value of the operation "a.operator B();" on the command line?
> 
> print a.operator B() 

"print a.'operator B'()" might work, and possibly  "print (B)a", too.

Andre'
(Continue reading)

Permalink | Reply | 0 comments |
headers
Phil Muldoon | 2 May 2011 18:12
Picon
Favicon

Re: better assembly level debugging

Francois <rigault.francois <at> gmail.com> writes:

> - defining labels
> reverse engineering is very difficult without debugging symbols. It
> would be very handy if I could (like on IDA or OllyDbg) define my own
> labels. That would be for example user-defined symbols, which could be
> used to get a nicer output.
> For example
>     set label 0x402000 log_error
> would define a new symbol "log_error". Further disassembly of "call
> 0x402000" instruction, or stepping near this address would give a
> cleaner output.

I like the utility of this.  I think you could probably write a large
amount of this in Python.  If a label is just a location, that could
easily be stored in a Python list.  You would have to teach the GDB
linespec code about parsing these utility labels though; that is an
internal GDB task.  OTOH, I think there is a way to assign locations to
GDB vars from the command-line right now.  I'm not sure.

> - pretty printer for instructions
> GDB could pretty print what it disassembles so that values of operands
> are introspected (looking for strings or functions especially)
>
> Let's take an example :
>
> #include <stdio.h>
> #include <wchar.h>
> int main() {
>     int (*printIt) (const wchar_t*, ...) = wprintf;
(Continue reading)

Permalink | Reply | 2 comments |

Gmane