Trepan

Latest version: v0.8.6

Safety actively analyzes 621562 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 1 of 6

0.8.6

Largely administrative changes

- Bump uncompyle6 version; use new uncompyle6 API
- Tweak disassemble doc
- Remove depares --pretty. sync with trepan2 code
- disassemble improvements
- small doc changes

0.8.5

- Fix botched packaging? (modname)

0.8.4

- Add deparsing in "list" command
- 3.4 compliance
there is a breakpoint
- Cache deparse info
- "set style" improvements
- Handle PyPy better
- "info locals *" and "info globals *" will list names
in columnar form omitting values

0.8.3

User incompatibilty alert!

We have redone location, breakpoint, and list-range parsing.

This release needs an explanation.

Code to parse commands like "list" and "breakpoint" were ugly and hard
to maintain. I hit a the tipping point in adding flexibility to the
"disassemble" command which allows address in addition to the usual
other kinds of locations.

Since version 0.6.3 when the "deparse" command was added, there has
been a hidden dependency of the the Earley parser.

That is now used to simplify parsing concepts like location,
list range, or breakpoint position.

In the process, I've gone over the syntax to make things more gdb
compatible. But of course gdb is also a moving target, so its syntax
has been extended and gotten more complicated as well.

In the olden days, I was sad that debuggers didn't follow someone
else's syntax but instead invented their own, sometimes incompatible
with gdb. Nowadays though it is a Herculean feat to come close to
matching gdb's syntax. Sigh.

The other problem with matching gdb's syntax is that debugging Python
is enherently different from debugging a compiled language with object
files. Python's language model just isn't the same as C's.

So there are deviations. The biggest change that I suspect will impact
users is that function names in locations in this debugger needs a
trailing "()" to mark it as a function. This was not needed in
previous versions and it isn't needed in gdb.

Not implimented in our notion of location are things that feel
compiled-language object-file-ish. Specifying the function name inside
an object file, isn't the way Python (or most dynamic languages)
do things. Instead you list the method/function inside a class or
module. And we allow this to be done off of variables and variables
holding instance methods.

Some things like ending at an address is not implemented as going
backwards in variable-length bytecode is a bit of work. Other things
of dubious merit I've omitted. The flexibility that is there
is probably overkill.

Speaking of reduced flexibility. Now with parser in place we no longer
support expressions as numbers in list commands. It's not in gdb and
I have a feeling that too is overkill.

- Add break! and b! aliases to force setting a breakpoint on a line

0.7.8

- Release for updated xdis and botched Rst
- PyPy 2.x tolerance
- Small error message improvements

0.7.7

- improve remote debugging:
* scans for open ports
* allow a socket to be passed in
* start Celery remote debugging
- add deval, deval? commands: deparsed eval and eval?
- in python/shell don't go into post-mortem debugger on exception
- find source or decompile when bytecode is given
- Handle position in the presence of eval() and exec()
- show code via xdis when disassembling an entire function.
- improved terminal background detection respecting
environment variables: DARK_BG, COLORFGBG
- deparse improvements:
* do deparse offset fuzzing
* show asm listing for opcode
* add -o | --offset to indicate where to start deparsing from

Page 1 of 6

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.