some Python related and other stuff...

[Jagged]

Dear debuggers,

attached is a bouquet (still a few days 'til Valentine, but...) of
cases that seem to be subject to some investigation.


The first subdirectory (01. missing in action) is about some missing
features in my copy (see below) of gdb 7.3.1, that should actually be
there, if one can believe the docs.

The second subdir (02. confusion of tongues) holds some issues about
my favourite topic when it comes to gdb: the "language" parameter and
its inconveniences/flaws.

The cases in the third directory (03. debug init ...) reveal incon-
sistencies in the determination of the first temporary breakpoint
when running the inferior by means of the "start" command.

The examples in the fourth directory (04. please call again ...) show
how to better not use events from within Python scripts, including
one way to quit gdb without further confirmation inquiries when the
inferior is still running (i. e. a complete gdb crash (core file
included; that's why the archive is that large)).

The fifth subdir (05. when Peter unlearned to fly) is about... hooks...
what else... more a feature request than a bug report.


Each of these directories contains

- descr.txt:    which describes the details of what I've encountered
                during my gdb safari
- session_*.gdbrc: gdb script file for each example; the * part is an
                alphanumerically sorted "counter"
- session.sh:   a bash script that runs gdb with all session_*.gdbrc
                files in the respective directory
                it looks for some gdb7 in the path; if it is not found,
                it creates an alias gdb7=gdb; I chose this way because
                I still have an "old" 6.8 version around here
                the script takes the optional argument "-f", which
                can in turn be followed by an optional filename; if no
                filename is given, "allsessions.out" is taken as the
                default; using the -f option, the script `tee's the
                output to the respective file, to /dev/null else
- allsessions.out: the output as rendered on my system (just in case
                you can not reproduce the described behaviour)

Some directories further contain:

- session_*.py: Python scripts involved in the respective session; the
                numbering is loosely tied to that of the *.gdbrc files,
                i. e. session_01[ab].gdbrc may both include
                session_01.py
- *.{pas,s}:    the source codes of the involved programs; they are
                actually stripped down to almost do nothing, and I'm
                glad the errors have not to do much with the inferiors,
                because I can not reveal the original sources
- *.o and executables: provided just in case you can not reproduce
                "binary compatible" files on your system; (at least
                for the stuff in directories 02.* and 03.* you'd need
                something compiled by Free Pascal)

My system is a 64 bit openSuSE 11.2; it has a stock (system supplied)
gdb 6.8 that I don't use any longer (mostly for the lack of the very
valuable "to_string=True" support in Python's gdb.execute()), but I
didn't dare to uninstall it yet.

The version of gdb that I use is 7.3.1 (complete version information
is in 01.*/allsessions.out), which I manually installed (config log
is in the trunk dir of the archive) with no further `configure'
options other than --prefix=...; the file is not the original though,
but is from another run without the --prefix option used.

The system has a stock fpc 2.2.4 (Free Pascal Compiler) and a manually
installed 2.4.4 version (from sources, but with default options). I
usually use the latter (and did so for the examples).

as and ld are stock SuSE versions; version info is in the archive's
trunk in as.version and ld.version, respectively.

That's it so far...

One other topic is regarding the documentation: in some places some
features are declared to be deprecated (like "BreakpointEvent.breakpoint"
in section "Events in Python" is shown as deprecated in docs version
7.3.92.20120114, but not for my 7.3.1). It'd be very helpful if there
were some info provided at which version the change took place; also,
it'd be convenient to know with which version new features have been
introduced. The Python documentation gives a great example (in this
respect).

A few weeks ago, when someone on irc.freenode.org#gdb encouraged me
to file a bug report, I asked him if this is also the right place for
requesting new features (well, that one mentioned above, about hooks,
is obviously "missing"), he suggested it is. So I give it a try:

1. I think it'd be a valuable enhancement to have a Python interface
   to the disassembler, to query something like gdb.disas(address).
   It wouldn't be too difficult to create some Python function that
   invokes gdb.execute to perform this task, but it should also be
   able to disassemble from memory regions that don't belong to code
   sections, which not even gdb's disassemble command does (which
   it should do on request, if you ask me).
   (supplemental: I figured out it does under certain conditions,
   but what are the exact conditions? I.e. when the $pc points at
   0x7fff..... (47 bits something) it assembles on "disas $pc,$pc+1",
   but not on "disas $pc" (shows "No function contains specified
   address." then).)

2. I don't know how much sense this makes, but a feature that allows
   arbitrary code injection would be great, as a quick way to provide
   temporary patches. I know that there have been (successful)
   approaches using gdb as a support tool for manually doing like
   this.
   I already thought about calling `as' (and `ld') via the "shell"
   command (or the Python equivalent) and loading the generated file
   by means of dlopen() or something, but a builtin version would be
   great.

3. What's really missing is a "try" statement, with which one could
   check what would happen if the next instruction were the one just
   passed to "try", for example "try sub $0x29a,%ecx", which would
   both alter %ecx and set the flags according to the result.
   ("set $ecx=$ecx-0x29a" doesn't set the flags, for example.)
   This would indeed require an additional "commit" or "discard"
   command or at least another confirmation inquiry, but that would
   be really useful.

Also, I didn't find a way to "symbolically" set the flags (instead
of explaining, I'll show off some attempted variations:)

------------
(gdb) print $eflags
$13 = [ IF ]
(gdb) set $eflags=$eflags | 's'
(gdb) print $eflags
$14 = [ CF AF ZF IF ]
(gdb) set $eflags=$eflags | "s"
Argument to arithmetic operation not a number or boolean.
(gdb) set $eflags=$eflags | sf
No symbol "sf" in current context.
(gdb) set $eflags=$eflags | [sf]
A syntax error in expression, near `[sf]'.
------------

I also tried '+' and so, but... well...

That's it for now... really... Thanks in advance for any effort, and have a 
nice time... oh well, and forgive me my sometimes cynical choice of terms... 
thanks again.

Best regards,

Jagged

-- 
 /¯\ ASCII RIBBON CAMPAIGN |  I believe  in  spon-  | _   _   O  ___ ___
 \ /  KEIN HTML IN E-MAIL  |  taneous  combustion,  | ¯\ /¯\ /¯\ ¯|¯ |¯¯
  X   UND  USENET-GRUPPEN  |  not in instant email  | _/ | _ |_|  |  |-
 / \  www.asciiribbon.org  |  replies...            | ¯\ \_/ |¯|  |  |__ o o o

bugreports.tar.bz2
Description: application/bzip-compressed-tar

pgpQRGci1IzQT.pgp
Description: PGP signature