I'd like to have an ebuild for ERESI, the ERESI Reverse Engineering Software Interface. I'm currently developing one and would like to commit that to sunrise soon. ELFsh, currently contained in the dev-util/elfsh package, is now part of ERESI. In that sense, ERESI is a replacement for elfsh. Maybe it should be assigned to maintainer-needed, as elfsh currently is, instead of maintainer-wanted, as common for new packages.
1) Please update the keywords& to notice that the ebuild is in Sunrise, 2) Please regenerate the source archive and/or update the ebuild.
(In reply to comment #1) > 1) Please update the keywords& to notice that the ebuild is in Sunrise, > 2) Please regenerate the source archive and/or update the ebuild. Done so, and also fixed a number of issues that prevented installation on my current system. Ebuild should be better now. Thanks for taking an interest!
I would like to push this to portage and reopen bug 232141, or does anybody else like to grab it?
(In reply to comment #3) > I would like to push this to portage and reopen bug 232141, or does anybody > else like to grab it? I've just taken on maintainership of elfsh. I know its a problematic package (compile bugs, QA) but I like what it does. I am not familiar with eresi. If it does everything elfsh does and is not broken, then maybe push eresi to the tree and drop elfsh. I'll be will to maintain eresi in that case, or let someone else maintain if they feel strongly about it. (or co-maintain). Can someone compare eresi and elfsh? I'm busy today but will look myself later.
(In reply to comment #4) > Can someone compare eresi and elfsh? > If it does everything elfsh does [...] Haven't compared features or sources myself, but eresi commit r160 has the commit message "merged elfsh_0_7a7p3rc1 into HEAD" so I'd assume that anything present in elfsh before that cryptic release candidate should now be in eresi as well. As stated in comment #0, elfsh is part of eresi, so eresi certainly does everything elfsh does, at least for its own version of elfsh, and more. > and is not broken, The build system is hand-written makefiles, which compile every source file twice: one for 32bit and one for 64bit. Other than that, it seems sane enough, but I haven't really used any of the tools very much.
BTW: My patch http://overlays.gentoo.org/proj/sunrise/browser/sunrise/dev-util/eresi/files/0.82_beta2-as-needed.patch was included upstream in http://www.eresi-project.org/changeset/1428 and http://overlays.gentoo.org/proj/sunrise/browser/sunrise/dev-util/eresi/files/0.82_beta2-parallel-make.patch is in http://www.eresi-project.org/changeset/1296 http://overlays.gentoo.org/proj/sunrise/browser/sunrise/dev-util/eresi/files/0.82_beta2-drop-dprintf.patch doesn't seeem to be included upstream; might well be I forgot to inform them about this issue.
Are there any progress about push it in main tree?
(In reply to comment #7) > Are there any progress about push it in main tree? Bug me in a few days and I'll play with it on my overlay and then commit to the tree. I have now answered my question in comment 4. I'll maintain it, if you guys want.
(In reply to comment #8) > (In reply to comment #7) > > Are there any progress about push it in main tree? > > Bug me in a few days and I'll play with it on my overlay and then commit to the > tree. I have now answered my question in comment 4. > > I'll maintain it, if you guys want. 1. We want :) 2. elfsh is now part of eresi framework http://www.eresi-project.org/wiki/TheELFsh And now there other interesting batteries included So, it have some libs, which used by elfsh Here are the projects that were developed on top of the ERESI framework: elfsh : An interactive and scriptable static program instrumentation tool for ELF binary files. kernsh: An interactive and scriptable runtime kernel instrumentation tool for live code injection, modification and redirection. e2dbg : An interactive and scriptable high-performance process debugger that works without standard OS debug API (without ptrace). etrace : A scriptable runtime process tracer working at full frequency of execution without generating traps. kedbg: An interactive and scriptable OS-wide debugger interfaced with the GDB server, VMware, Qemu, Boches and OpenOCD (JTAG) via the GDB serial protocol. Evarista?: A work-in-progress static binary program transformer entirely implemented in the ERESI language. Here is diagram, of ERESI structure http://www.eresi-project.org/wiki/EresiVisualOverview Beside those top-level components, ERESI contains various libraries that can be used from one of the previously mentioned tools, or in a standalone third-party program: libelfsh : the binary manipulation library used by ELFsh, Kernsh, E2dbg, and Etrace. libe2dbg : the embedded debugger library operating within the debuggee program. libasm : the smart disassembling engine (x86, sparc, mips, arm) that gives both syntactic and semantic attributes to instructions and their operands. libmjollnir : the control flow analysis and fingerprinting library. librevm : the Runtime ERESI virtual machine, that contains the central runtime environment implementation of the framework. libstderesi : the standard ERESI library containing more than 100 built-in analysis commands. libaspect : the aspect library brings its API to reflect code and data structures in the ERESI language. libedfmt : the ERESI debug format library which can convert dwarf and stabs debug formats to the ERESI debug format. libetrace : the ERESI tracer library, on which Etrace is based. libkernsh : the Kernel shell library is the kernel accessibility library on which Kernsh is based. libgdbwrap : The GDB serial protocol library, for compatibility between ERESI and GDB/VMware/Boches/QeMu/OpenOCD.
> I'll maintain it, if you guys want. I've gotten some time to play with it and there is some serious breakage in the build system, and missing DEPENDs. I can fix some of it easily and others I cannot. Here's what I found: 1. dev-util/eresi-0.82_beta2 USE="readline server -doc" dies with Error: Readline and Distributed ELFsh are incompatible. Easy fix, with something like: pkg_setup() { if use readline && use server; then eerror "readline and server are not compatible," eerror "please USE one or the other, but not both" die } 2. dev-util/eresi-0.82_beta2 USE="server -doc -readline" dies with ar rc libdump32.a dump.32.o recv.32.o send.32.o ranlib libdump32.a ld -r dump.32.o recv.32.o send.32.o -o libdump32.o -Wl,-O1 -Wl,--as-needed -lutil ld: unrecognized option '-Wl,-O1' ld: use the --help option for usage information This makes no sense for LDFLAGS. -O1 is a compiler option. And if you are trying to pass LDFLAGS via CFLAGS, it should read -Wl,-z,xxx where xxx is the ldflag. This needs to be looked at. 3. dev-util/eresi-0.82_beta2 USE="readline -doc -server" dies with /usr/include/features.h:303:1: warning: this is the location of the previous definition readln.c: In function ‘readln_match’: readln.c:98: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result readln.c: In function ‘readln_match’: readln.c:98: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result readln.c: In function ‘readln_completion’: readln.c:179: warning: unused parameter ‘start’ readln.c:179: warning: unused parameter ‘end’ readln.c: In function ‘readln_completion’: readln.c:179: warning: unused parameter ‘start’ readln.c:179: warning: unused parameter ‘end’ /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -ltermcap collect2: ld returned 1 exit status gmake[1]: *** [libui64.so] Error 1 gmake[1]: *** Waiting for unfinished jobs.... /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -ltermcap collect2: ld returned 1 exit status gmake[1]: *** [libui32.so] Error 1 gmake[1]: Leaving directory `/var/tmp/portage/dev-util/eresi-0.82_beta2/work/eresi-0.82_beta2/libui' make: *** [world] Error 2 But! libtermcap-compat is installed, so why can't it find -ltermcap? Also DEPEND should have sys-libs/libtermcap-compat and probably other atoms. 4. dev-util/eresi-0.82_beta2 USE="-doc -readline -server" builds and installs fine. 5. Enabling "doc" doesn't seem to make much difference. I copied this to my dev overlay. I'll work on this when I have time, but if you want to speed it up, try to address points 2 and 3. I can get the dependencies right once it compiles correctly. Thanks guys.
(In reply to comment #10) > 1. dev-util/eresi-0.82_beta2 USE="readline server -doc" > if use readline && use server; then As an alternative, you could try EAPI=4 REQUIRED_USE="server? ( !readline )" See section 9.2.6 of the package manager specification. > 2. dev-util/eresi-0.82_beta2 USE="server -doc -readline" > ld: unrecognized option '-Wl,-O1' > > This makes no sense for LDFLAGS. -O1 is a compiler option. No, ld has an optimizer flag of that name as well. > And if you are > trying to pass LDFLAGS via CFLAGS, it should read -Wl,-z,xxx where xxx is the > ldflag. Only for flags which start with -z. The -Wl is a flag to gcc, telling it to pass all subsequent parts of the argument to the linker, separated at the commas. The following might solve the problem: inherit flag-o-matic ... src_compile() { LDFLAGS=$(raw-ldflags) ... } > 3. dev-util/eresi-0.82_beta2 USE="readline -doc -server" > > cannot find -ltermcap > > But! libtermcap-compat is installed, so why can't it find -ltermcap? The linker cannot find the lib due to a missing symlink: # ls -l /lib/libtermcap* | cut -c44- /lib/libtermcap.so.2 -> libtermcap.so.2.0.8 /lib/libtermcap.so.2.0.8 There should be a symlink named libtermcap.so pointing at libtermcap.so.2. According to bug #302613 this is not a bug, but a feature. Not sure why. So remove readline support for the moment, and if you feel like it, ask upstream to move to terminfo instead. Until then, app-misc/rlwrap might help. > Also DEPEND should have sys-libs/libtermcap-compat and probably other atoms. I guess when I wrote the ebuild, ncurses used to provide libtermcap, and was a dependency of readline. Things have changed, or I was wrong back then already. ldd the resulting binaries and see what packages the resulting libraries belong to. > 5. Enabling "doc" doesn't seem to make much difference. What do you mean? Doesn't affect build success, or doesn't affect the set of files installed? The latter shouldn't be the case. > I copied this to my dev overlay. Care to provide a link? I'd have preferred colaboration in sunrise...
(In reply to comment #11) > (In reply to comment #10) > > 1. dev-util/eresi-0.82_beta2 USE="readline server -doc" > > if use readline && use server; then > > As an alternative, you could try > > EAPI=4 > REQUIRED_USE="server? ( !readline )" > > See section 9.2.6 of the package manager specification. Yeah, I prefer EAPI=4 anyhow. > > > 2. dev-util/eresi-0.82_beta2 USE="server -doc -readline" > > ld: unrecognized option '-Wl,-O1' > > > > This makes no sense for LDFLAGS. -O1 is a compiler option. > > No, ld has an optimizer flag of that name as well. Ah, okay, then I think the option should not have -Wl, in front. I'll get it. > > > And if you are > > trying to pass LDFLAGS via CFLAGS, it should read -Wl,-z,xxx where xxx is the > > ldflag. > > Only for flags which start with -z. The -Wl is a flag to gcc, telling it to > pass all subsequent parts of the argument to the linker, separated at the > commas. The following might solve the problem: > > inherit flag-o-matic > ... > src_compile() { > LDFLAGS=$(raw-ldflags) > ... > } I'll give this a try too. > > > 3. dev-util/eresi-0.82_beta2 USE="readline -doc -server" > > > > cannot find -ltermcap > > > > But! libtermcap-compat is installed, so why can't it find -ltermcap? > > The linker cannot find the lib due to a missing symlink: > > # ls -l /lib/libtermcap* | cut -c44- > /lib/libtermcap.so.2 -> libtermcap.so.2.0.8 > /lib/libtermcap.so.2.0.8 > > There should be a symlink named libtermcap.so pointing at libtermcap.so.2. > According to bug #302613 this is not a bug, but a feature. Not sure why. > > So remove readline support for the moment, and if you feel like it, ask > upstream to move to terminfo instead. Until then, app-misc/rlwrap might help. I think you're right, this is a problem with libtermcap-compat. > > > Also DEPEND should have sys-libs/libtermcap-compat and probably other atoms. > > I guess when I wrote the ebuild, ncurses used to provide libtermcap, and was a > dependency of readline. Things have changed, or I was wrong back then already. > > ldd the resulting binaries and see what packages the resulting libraries belong > to. > I prefer to user ncurses. Let me try to get that working. > > 5. Enabling "doc" doesn't seem to make much difference. > > What do you mean? Doesn't affect build success, or doesn't affect the set of > files installed? The latter shouldn't be the case. I tested all combinations of USE flags. This just makes the above systematic testing complete by saying that USE="doc" or USE="-doc" doesn't affect the above results. I didn't expect it to, but testing nails it. > > > I copied this to my dev overlay. > > Care to provide a link? I'd have preferred colaboration in sunrise... I don't have access to their svn so I put ebuilds on my dev overlay to hack on them before moving to the tree. It will not stay there. I assume once its in the tree it won't be on sunrise either unless you want to use sunrise for the next bump? We'll collaborate on maintaining it on the tree. Mostly I just need another pair of eyes to tell me when eresi has another release. Also the tarballs should go on my dev space @ dev.gentoo.org (for archival reasons), but you can generate and host them at your end too and put that in the SRC_URI as well. http://git.overlays.gentoo.org/gitweb/?p=dev/blueness.git;a=summary
I just noticed another problem. The ebuild installs into /usr/local. This is because of the non-traditional build system.
Created attachment 274427 [details, diff] eresi-0.82_beta2-nold.patch (In reply to comment #12) > (In reply to comment #11) > > (In reply to comment #10) > > > 2. dev-util/eresi-0.82_beta2 USE="server -doc -readline" > > > ld: unrecognized option '-Wl,-O1' > > > > > > This makes no sense for LDFLAGS. -O1 is a compiler option. > > > > No, ld has an optimizer flag of that name as well. > > Ah, okay, then I think the option should not have -Wl, in front. I'll get it. All of these flags make perfect sense for LDFLAGS. See make.conf(5) for use of LDFLAGS and ld(1) for a description of its parameters. -O1 is a valid argument for ld and LDFLAGS _must_ have linker flags escaped with -Wl. The proper fix is to make sure that eresi never calls ld directly, since this is broken behavior and will cause other problems (such as more fun compile failures for portage-multilib users) too. > > > And if you are > > > trying to pass LDFLAGS via CFLAGS, it should read -Wl,-z,xxx where xxx is the > > > ldflag. > > > > Only for flags which start with -z. The -Wl is a flag to gcc, telling it to > > pass all subsequent parts of the argument to the linker, separated at the > > commas. The following might solve the problem: > > > > inherit flag-o-matic > > ... > > src_compile() { > > LDFLAGS=$(raw-ldflags) > > ... > > } > > I'll give this a try too. IMO, raw-ldflags() should never need to be used. Instead the Makefile should be patched. See attachment which gets through this error in my testing.
Sunrise updated, please pull changes from there. http://overlays.gentoo.org/proj/sunrise/changeset/12083
(In reply to comment #15) > Sunrise updated, please pull changes from there. > http://overlays.gentoo.org/proj/sunrise/changeset/12083 Okay I imported that. I've got two more patches to address QA issues. I put them on my dev overlay. 1) The build system created absolute links in $prefix/bin and $prefix/lib, leading to a bunch of QA notices: * QA Notice: Found an absolute symlink in a library directory: * usr/lib/libaspect.a -> /var/tmp/portage/dev-util/eresi-0.82_beta2/image//usr/lib/libaspect32.a * It should be a relative symlink if in the same directory * or a linker script if it crosses the /usr boundary. http://git.overlays.gentoo.org/gitweb/?p=dev/blueness.git;a=commit;h=a0ca1f6a9f80504ea000c4db0bfa8a5be1771be7 2) The build system tries to install some config files in the users homedir. That's fixed by the commit @ http://git.overlays.gentoo.org/gitweb/?p=dev/blueness.git;a=commit;h=e0ea894800f1dcc648471947ecf25c1d7916c73f 3) The .so are linked without an -soname. * QA Notice: The following shared libraries lack a SONAME * /usr/lib/libasm32.so * /usr/lib/libasm64.so * /usr/lib/libaspect32.so * /usr/lib/libaspect64.so * /usr/lib/libe2dbg32.so * /usr/lib/libe2dbg64.so * /usr/lib/libedfmt32.so * /usr/lib/libedfmt64.so * /usr/lib/libelfsh32.so * /usr/lib/libelfsh64.so * /usr/lib/libetrace32.so * /usr/lib/libetrace64.so * /usr/lib/libmjollnir32.so * /usr/lib/libmjollnir64.so * /usr/lib/librevm32.so * /usr/lib/librevm64.so * /usr/lib/libstderesi32.so * /usr/lib/libstderesi64.so * /usr/lib/libui32.so * /usr/lib/libui64.so I know how to fix this, but haven't gotten to it. 4) There are still some more QA issues which I haven't gotten to * QA Notice: Package has poor programming practices which may compile * fine but exhibit random runtime failures. * elf.c:173: warning: dereferencing type-punned pointer will break strict-aliasing rules * elf.c:511: warning: dereferencing type-punned pointer will break strict-aliasing rules * elf.c:527: warning: dereferencing type-punned pointer will break strict-aliasing rules * elf.c:173: warning: dereferencing type-punned pointer will break strict-aliasing rules * elf.c:511: warning: dereferencing type-punned pointer will break strict-aliasing rules * elf.c:527: warning: dereferencing type-punned pointer will break strict-aliasing rules * dwarf2-abbrev.c:300: warning: dereferencing type-punned pointer will break strict-aliasing rules * dwarf2-abbrev.c:300: warning: dereferencing type-punned pointer will break strict-aliasing rules * QA Notice: Package has poor programming practices which may compile * fine but exhibit random runtime failures. * switch.c:31: warning: implicit declaration of function ‘mjr_set_current_context’ * switch.c:31: warning: implicit declaration of function ‘mjr_set_current_context’ * signal.c:497: warning: implicit declaration of function ‘mjr_set_current_context’ * signal.c:497: warning: implicit declaration of function ‘mjr_set_current_context’ * QA Notice: Package has poor programming practices which may compile * fine but exhibit random runtime failures. * sparc64.c:162: warning: array subscript is above array bounds * sparc64.c:162: warning: array subscript is above array bounds
(In reply to comment #9) > (In reply to comment #8) > > I'll maintain it, if you guys want. > 1. We want :) What's the status here? As far as I can tell, there are my things in sunrise, and there are the improvements Anthony committed to his own overlay. There still is nothing in the main portage tree. How far are we from getting there? Should we drop eresi from sunrise, as the version there is outdated, or should we try to keep that version in sync with what Anthony has? If so, would you sync this yourself, Anthony?
Hello, everyone. It seems that at least one ebuild related to this bug exists in the Sunrise overlay at the moment. However, I have to regretfully announce that after a long inactivity period the Sunrise project has been discontinued and the related overlay will be eventually removed. For this reason, I'd like to ask you to reevaluate the ebuilds and consider moving them. If you'd like to maintain a package from Sunrise in Gentoo, please take a look at our Proxy Maintainers [1] project. Please make sure to take ebuilds from the unreviewed developer Sunrise repository [2] rather than the -reviewed one, since the latter has not been updated for over a year. While at it, please note that: 1. Adding a package to Gentoo requires declaring yourself as an active maintainer for it. All bugs regarding the package will be assigned to you, and you will be expected to maintain it. 2. Some packages may not be suitable for addition anymore. While there's no strong rules that would prevent you from adding a package, it may be a bad idea to add old-unmaintained packages that will shortly result in a large number of bugs reported with no solution. If that is the case, please close the bug as RESOLVED/OBSOLETE to make it easier to find packages worth adding. 3. Some of the bugs were already closed as WONTFIX/OBSOLETE/... while the relevant ebuild was kept in Sunrise. If you disagree with the original decision, you still can add the ebuild via proxy-maint. 4. Pleaes note that many of the Sunrise ebuilds are old and may be buggy. If you decide to move them, please make sure to update/clean them up. The proxy-maint team will also review your ebuilds, therefore making sure they land in Gentoo in good quality. Once again, thank you for your contribution. We hope that you will still want to contribute to Gentoo, through proxy-maint or otherwise. [1]:https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers [2]:https://gitweb.gentoo.org/proj/sunrise.git/
(In reply to Martin von Gagern from comment #17) > > What's the status here? > I moved the ebuild to my overlay. It looks like upstream is active on github, https://github.com/thorkill/eresi so I may eventually put something on the tree.
