GoogleCodeExporter
commented
9 years ago Open GoogleCodeExporter opened 9 years ago
GoogleCodeExporter
commented
9 years ago GoogleCodeExporter
commented
9 years ago Thank you for your bug report and patches!
The linux port is the only version that is currently expected to work, but this
will definitely help things move in the right direction. I've been wanting to
add support for any of the BSDs for a while, but am a little unfamiliar with
the system APIs I'll need to dive into. (For example, I need to learn more
about how to get a process's memory statistics without /proc/ and such).
As for the linker errors, I **think** I know what the problem is. Basically,
the current module system works by having the plugins reference symbols which
are exported by the main binary. On some configurations, it may need some
linker flags to make this happen correctly, but I believe that it should work
on BSD unixes as well. So I'll look into that. I am nearly 100% sure that is
the problem because the symbols I've seen so far all resolve to
"edb::v1::whatever" and the edb::v1 namespace is found entirely in the main
executable.
I'll be setting up an OpenBSD VM so I can test and apply these patches and
hopefully get it to load up correctly.
Thanks Again,
Evan TeranOriginal comment by evan.teran on 3 Oct 2012 at 4:30
GoogleCodeExporter
commented
9 years ago edb builds and now has basic functionality implemented for openbsd. Not all
features are supported (or work perfectly), but the core feature set seems to
work well.Original comment by evan.teran on 3 Oct 2012 at 4:30
GoogleCodeExporter
commented
9 years ago Is this the subversion code we are talking about? If so, where can I obtain
this?Original comment by evan.teran on 3 Oct 2012 at 4:30
GoogleCodeExporter
commented
9 years ago I am actually referring to the latest public release :-) 0.9.16. I am also
looking into setting up a public SVN so that people can take a more active role
in contributing.
Evan TeranOriginal comment by evan.teran on 3 Oct 2012 at 4:30
GoogleCodeExporter
commented
9 years ago Is this expected to build *outside* the ports infrastructure? I fetched the
most recent version and attempted a build in my home dir:
---8<---
cd src/ && make -f Makefile
g++ -c -pipe -O2 -fno-wrapv -ansi -pedantic -W -Wall -Wno-long-long
-Wnon-virtual-dtor -O2 -fno-wrapv -Wall -W -pthread -DQT_NO_DEBUG -DQT_GUI_LIB
-DQT_CORE_LIB -DQT_SHARED -I/usr/local/lib/qt4/mkspecs/openbsd-g++4 -I.
-I/usr/local/include/X11/qt4/QtCore -I/usr/local/include/X11/qt4/QtGui
-I/usr/local/include/X11/qt4 -Iwidgets -I../include -Ios/unix
-I../include/os/unix -Ios/unix/openbsd -I../include/os/unix/openbsd
-I/usr/local/include -Iarch/x86_64 -I../include/arch/x86_64
-I.moc/release-shared -I.uic -I/include -o .obj/release-shared/MemRegion.o
os/unix/openbsd/MemRegion.cpp
In file included from /usr//include/g++/memory:60,
from /usr//include/g++/string:48,
from ../include/arch/x86_64/../../../src/edisassm/edisassm_util.h:23,
from ../include/arch/x86_64/../../../src/edisassm/Instruction.h:23,
from ../include/arch/x86_64/Instruction.h:1,
from ../include/arch/x86_64/ArchTypes.h:24,
from ../include/Types.h:23,
from ../include/os/unix/openbsd/MemRegion.h:23,
from os/unix/openbsd/MemRegion.cpp:20:
/usr//include/g++/limits: In static member function 'static char
std::numeric_limits<char>::min()':
/usr//include/g++/limits:375: warning: overflow in implicit constant conversion
/usr//include/g++/limits: In static member function 'static wchar_t
std::numeric_limits<wchar_t>::max()':
/usr//include/g++/limits:530: warning: overflow in implicit constant conversion
In file included from /usr//include/g++/bits/locale_facets.h:47,
from /usr//include/g++/bits/basic_ios.h:44,
from /usr//include/g++/ios:50,
from /usr//include/g++/istream:44,
from /usr//include/g++/iomanip:45,
from ../include/arch/x86_64/../../../src/edisassm/Operand.tcc:28,
from ../include/arch/x86_64/../../../src/edisassm/Operand.h:220,
from ../include/arch/x86_64/../../../src/edisassm/Instruction.h:60,
from ../include/arch/x86_64/Instruction.h:1,
from ../include/arch/x86_64/ArchTypes.h:24,
from ../include/Types.h:23,
from ../include/os/unix/openbsd/MemRegion.h:23,
from os/unix/openbsd/MemRegion.cpp:20:
/usr//include/g++/amd64-unknown-openbsd4.8/bits/ctype_base.h: At global scope:
/usr//include/g++/amd64-unknown-openbsd4.8/bits/ctype_base.h:55: warning:
overflow in implicit constant conversion
os/unix/openbsd/MemRegion.cpp:100: error: prototype for 'void
MemRegion::set_permissions(bool, bool, bool, edb::address_t)' does not match
any in class 'MemRegion'
../include/os/unix/openbsd/MemRegion.h:82: error: candidate is: void
MemRegion::set_permissions(bool, bool, bool)
os/unix/openbsd/MemRegion.cpp:100: warning: unused parameter 'read'
os/unix/openbsd/MemRegion.cpp:100: warning: unused parameter 'write'
os/unix/openbsd/MemRegion.cpp:100: warning: unused parameter 'execute'
os/unix/openbsd/MemRegion.cpp:100: warning: unused parameter 'temp_address'
os/unix/openbsd/MemRegion.cpp:115: warning: unused parameter 'read'
os/unix/openbsd/MemRegion.cpp:115: warning: unused parameter 'write'
os/unix/openbsd/MemRegion.cpp:115: warning: unused parameter 'execute'
*** Error code 1
Stop in /home/edd/debugger/src (line 990 of Makefile).
*** Error code 1
Stop in /home/edd/debugger (line 40 of Makefile).
---8<---
I am running OpenBSD-current (a recent snapshot) on amd64.
CheersOriginal comment by evan.teran on 3 Oct 2012 at 4:31
GoogleCodeExporter
commented
9 years ago One thing I forgot to mention is that for openBSD only i386 is supported. I
haven't tested 64-bit yet. It may build on x86_64, or it may not. It definitely
won't work yet though because I need to make it use the 64-bit process state
structures in the DebuggerCore. Also, it seems that my last minute header
cleanup backfired :-(.
The function declared on line 100 of MemRegion "void
MemRegion::set_permissions(bool read, bool write, bool execute, edb::address_t
temp_address)" was supposed to be chopped out.
Sorry about that. Try removing that function entirely (it just has a TODO
comment in it anyway) and see if it builds for i386. I'll do this and push it
to my website (no version change though).
Original comment by evan.teran on 3 Oct 2012 at 4:31
GoogleCodeExporter
commented
9 years ago Actually, it may work on x86_64 :-P. I just looked at the source code. It seems
that I at least put in code for the DebuggerCore for x86_64 process state.
Let me know if it does! Also I just put up the patched version. Sorry for the
build issues.
Original comment by evan.teran on 3 Oct 2012 at 4:32
GoogleCodeExporter
commented
9 years ago Sigh... No - There is still breakage, although atleast it builds now.
File->open, /usr/bin/mail
Program received signal SIGSEGV, Segmentation fault.
[Switching to process 5854, thread 0x8b9ee400]
kvm_close (kd=0x0) at /usr/src/lib/libkvm/kvm.c:619
619 /usr/src/lib/libkvm/kvm.c: No such file or directory.
in /usr/src/lib/libkvm/kvm.c
(gdb) bt
#0 kvm_close (kd=0x0) at /usr/src/lib/libkvm/kvm.c:619
#1 0x1c0a3336 in MemoryRegions::sync ()
#2 0x1c07ae5d in DebuggerMain::set_initial_debugger_state ()
#3 0x1c07bd12 in DebuggerMain::common_open ()
#4 0x1c07bf25 in DebuggerMain::execute ()
#5 0x1c07c67e in DebuggerMain::open_file ()
#6 0x1c07c779 in DebuggerMain::on_action_Open_triggered ()
#7 0x1c0ef7bd in DebuggerMain::qt_metacall ()
#8 0x06de6863 in QMetaObject::metacall () from /usr/local/lib/libQtCore.so.8.0
#9 0x06df43d6 in QMetaObject::activate () from /usr/local/lib/libQtCore.so.8.0
#10 0x07c7cc39 in QAction::triggered () from /usr/local/lib/libQtGui.so.9.0
#11 0x07c7e3ef in QAction::activate () from /usr/local/lib/libQtGui.so.9.0
#12 0x0814ac40 in QMenuPrivate::activateCausedStack () from
/usr/local/lib/libQtGui.so.9.0
#13 0x0815133b in QMenuPrivate::activateAction () from
/usr/local/lib/libQtGui.so.9.0
#14 0x0815347d in QMenu::mouseReleaseEvent () from
/usr/local/lib/libQtGui.so.9.0
#15 0x07ce94a9 in QWidget::event () from /usr/local/lib/libQtGui.so.9.0
#16 0x08150cd4 in QMenu::event () from /usr/local/lib/libQtGui.so.9.0
#17 0x07c8435c in QApplicationPrivate::notify_helper () from
/usr/local/lib/libQtGui.so.9.0
#18 0x07c8bdac in QApplication::notify () from /usr/local/lib/libQtGui.so.9.0
#19 0x06de050b in QCoreApplication::notifyInternal () from
/usr/local/lib/libQtCore.so.8.0
#20 0x07c86b59 in QApplicationPrivate::sendMouseEvent () from
/usr/local/lib/libQtGui.so.9.0
#21 0x07d188c7 in QETWidget::translateMouseEvent () from
/usr/local/lib/libQtGui.so.9.0
#22 0x07d17fcd in QApplication::x11ProcessEvent () from
/usr/local/lib/libQtGui.so.9.0
#23 0x07d43e44 in QGuiEventDispatcherGlib::processEvents () from
/usr/local/lib/libQtGui.so.9.0
#24 0x0ce56e47 in g_main_context_dispatch () from
/usr/local/lib/libglib-2.0.so.2600.0
#25 0x0ce5a7be in g_main_context_prepare () from
/usr/local/lib/libglib-2.0.so.2600.0
#26 0x0ce5ade5 in g_main_context_iteration () from
/usr/local/lib/libglib-2.0.so.2600.0
#27 0x06e107cb in QEventDispatcherGlib::processEvents () from
/usr/local/lib/libQtCore.so.8.0
#28 0x07d43c35 in QGuiEventDispatcherGlib::processEvents () from
/usr/local/lib/libQtGui.so.9.0
#29 0x06ddf4f3 in QEventLoop::processEvents () from
/usr/local/lib/libQtCore.so.8.0
#30 0x06ddf86a in QEventLoop::exec () from /usr/local/lib/libQtCore.so.8.0
#31 0x06de1d56 in QCoreApplication::exec () from /usr/local/lib/libQtCore.so.8.0
#32 0x07c83cf7 in QApplication::exec () from /usr/local/lib/libQtGui.so.9.0
#33 0x1c0a0576 in main ()
How do you enable debuging symbols globally? So far I have found that you have
to add 'CONFIG += debug' to every project, which sucks. Do you know a way?
This is on an i386 machine now, using OpenBSD-current.
CheersOriginal comment by evan.teran on 3 Oct 2012 at 4:32
GoogleCodeExporter
commented
9 years ago Well that's no good. My guess is that one of the kvm_reads's is failing :-(.
Did you try running it as root? (I know not good practice, but for diagnostic
purposes).
If that's the problem, then adding proper error handling should fix it.
anyway, to do a general debug build, you can do this in the root project
directory.
make distclean
qmake-qt CONFIG+=debug
make
you should do the distclean first to make sure that all makefiles are
re-created. This should make everything build in debug mode.
Thanks for you efforts and sorry for the troubles with this port.Original comment by evan.teran on 3 Oct 2012 at 4:32
GoogleCodeExporter
commented
9 years ago Indeed, it does work as root. Can you take a look?
CheersOriginal comment by evan.teran on 3 Oct 2012 at 4:32
GoogleCodeExporter
commented
9 years ago Glad to hear it works as root!
I think I know what happened. If I recall correctly, in my test VM I added my
normal user to the "kvm" group. This is probably a reasonable enough solution.
When not either root or in the kvm group, kvm_getproc2() will return NULL. The
current code doesn't check that...oops.
Anyway, I think the best I can do is catch that NULL and put up a messagebox
recommending they either add themselves to the kvm group or run an a root.
The only alternative is an ugly one.
Move that particular functionality to a separate binary which is suid root and
use IPC to get the info when I need it. It would be functional, but not pretty
at all.
Original comment by evan.teran on 3 Oct 2012 at 4:33
GoogleCodeExporter
commented
9 years ago Hrm. Is there an alternative method than by using kvm functions? I have spoken
with others and we would rather not import code which requires users in the
kmem group.Original comment by evan.teran on 3 Oct 2012 at 4:33
GoogleCodeExporter
commented
9 years ago I agree that having users in the kmem group is not ideal. Unfortunately, I'm
not currently aware of alternate techniques to get the two pieces of
information that I am currently using the kvm API for:
1) process memory map
2) the fine details of the current signal being delivered to the child
But that doesn't mean that there isn't an alternative, I'm far more familiar
with the Linux APIs than I am with OpenBSD's. So it is possible that I just
need to do a little more research to get the information that I need.
Original comment by evan.teran on 3 Oct 2012 at 4:34
GoogleCodeExporter
commented
9 years ago Original comment by evan.teran on 4 Apr 2014 at 3:47
Original issue reported on code.google.com by
evan.teranon 3 Oct 2012 at 3:21