theldus / pbd Goto Github PK

Description

At the current release, PBD does not supports enums and thus will not watch any enums available in the target. Since the enum structure is a little different from the base types (DWARF structure), I have not focused on implementing this yet, but it should occur in the next releases.

I tried to build the latest code, and got this error. I cannot find this file in this repo.

Description

Currently, PBD does not have any sort of output coloring. Having an output color would greatly improve the readability of the output. Since PBD supports two types of outputs: standard output (line numbers only) and line output (-s option), color support should be implemented for both modes.

Since it is an aesthetic feature, it will be implemented in the next releases and has a low priority. Unless someone is willing to pick this, if that is the case, let me know.

Description

PBD lacks structures and unions analysis at the moment. Since structures could go arbitrarily deep (like a tree of structs) the dwarf analysis must be changed to accommodate these changes and, at the moment, the inner code -- that does the dwarf analysis -- do not have the proper data structure to handle this.

Some proposed approaches:
1. Recursively parses the structure and for each base type found add into the variables list (as a common variable, instead of a structure item) with the proper variable location calculated too. This approach is 'reasonably' good: 1) require 'few' changes in dwarf analysis stage and 2) requires no changes (or very few) in the variables check stage.

Although good, since each variable member is dealt with as a simple variable, a huge structure could be penalized in terms of performance.

2. During dwarf analysis: create an auxiliary data structure that holds each variable location and uses it in the variable check stage. Although this method requires more change in both (dwarf and variable check) stages, this approach can lead to a more performative code since the entire structure could be scanned as a 'huge' single type, and in case of changes, the offset is searched in this auxiliary data structure.

*Unions analysis implies all the above statements and also: how can I format the output on the screen? If a union holds multiples data types, what data type should be used?

Anyways, any help in that sense is welcome, ;-).

Description

There are two ways to analyze pointers: 1) tracking the pointer value, as a normal variable (eg: ptr++ would be tracked) and 2) tracking the content pointed by the pointer.

The former is already handled by PBD, as can be seen from the test file in src/tests/test.c. The latter is more complicated and this issue aims to discuss some possible approaches to it.

Two main issues with the analysis of (the content of) pointers I can think of are:

• a) Where does the address come from? The address can come from a dynamic allocation (mmap, malloc, calloc...), a reference to a variable or part of it (ptr = &vec, ptr = &vec[2], ...), shared memory and so on.

• b) How big is this memory? If the address comes from a dynamically allocated variable, array... the size changes as well.

Both cases can be 'easily' handled if the addresses are already known, as in references to variables and structures... but it becomes quite annoying if dynamically allocated. With dynamic allocation some kind of mechanism should be used to get addresses and their size, maybe something like a dynamic library with hooks for malloc/calloc + LD_PRELOAD could be a reasonable solution to this, although it cannot handle all memory allocation cases it might be able to handle most of them.

That's it, there is no trivial solution to this, so any help in this regard is most welcome, ;-).

I tried to build your code for X86 32bit, and got the following errors. Is 32-bit supported? If not, do you have any plans to support it?

ptrace.c:102:45: error: use of undeclared identifier 'RIP'
return (ptrace(PTRACE_PEEKUSER, child, 8 * RIP, NULL));
^
ptrace.c:116:7: error: no member named 'rip' in 'struct user_regs_struct'; did you mean 'eip'?
regs.rip = pc;
^~~
eip
/usr/include/i386-linux-gnu/sys/user.h:145:12: note: 'eip' declared here
long int eip;
^
ptrace.c:130:45: error: use of undeclared identifier 'RBP'
return (ptrace(PTRACE_PEEKUSER, child, 8 * RBP, NULL));
^
ptrace.c:145:42: error: use of undeclared identifier 'RSP'
sp = ptrace(PTRACE_PEEKUSER, child, 8 * RSP, NULL);
^
4 errors generated.

It seems PBD works for binaries generated by gcc with glibc, but not for the ones linked with other libc.

Description

At the moment, PBD relies on DWARF-2/Location lists to find the appropriate variable location (whether local or global). Although not an issue, this requires the user to building the target code with -gdwarf-2 (instead of only -g) flag since GCC/CLang no longer uses DWARF-2 as default.

Supporting DWARF version 4 would be great since from this version onwards, compilers started to use CFA (Call Frame Information) as the default way to indicate variable locations and just requires the user to pass -g to emit debugging symbols.

Useful resources:

• https://stackoverflow.com/questions/33071545/what-do-i-do-with-dw-op-call-frame-cfa
• https://stackoverflow.com/questions/56204213/how-to-parse-dw-op-call-frame-cfa

1. My cee.studio backend uses containers to mount source code to /home/jail/ to build executables.
2. When a user run the executable, the executables and source code are mount to /home/usr/

This cause pbd cannot find the source files. The following is the error message.

pbd a.out main -s
PBD: Source code/theme file /home/jail/prog.c not found, please
check if the file exists in your system!

PBD still looks for the source path from which the executables are built. Is it possible to allow users to truncate "/home/jail/" by specifying env TRUCATE=/home/jail/ so PBD can search source files from the current folder.