<div dir="ltr"><div>Yay it's green!</div><div><a href="https://build.neon.kde.org/view/3%20unstable%20%E2%98%A3%20git%20master/job/bionic_unstable_neon-packaging_elf-dissector/">https://build.neon.kde.org/view/3%20unstable%20%E2%98%A3%20git%20master/job/bionic_unstable_neon-packaging_elf-dissector/</a></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 30 Oct 2019 at 17:30, Volker Krause <<a href="mailto:vkrause@kde.org">vkrause@kde.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">This one probably even affects all 32bit builds with Capstone available, not <br>
just ARM. I've pushed a fix for this.<br>
<br>
Thanks!<br>
Volker<br>
<br>
On Wednesday, 30 October 2019 11:02:21 CET Jonathan Riddell wrote:<br>
> That seems to have worked, it's moved onto the next 32-bit error<br>
> <br>
> <a href="https://build.neon.kde.org/job/bionic_unstable_neon-packaging_elf-dissector_" rel="noreferrer" target="_blank">https://build.neon.kde.org/job/bionic_unstable_neon-packaging_elf-dissector_</a><br>
> bin_armhf/8/console<br>
> <br>
> src/lib/disassmbler/disassembler.cpp:228:65: error: cannot convert<br>
> ‘uint64_t* {aka long long unsigned int*}’ to ‘size_t* {aka unsigned<br>
> int*}’ for argument ‘3’ to ‘bool cs_disasm_iter(csh, const uint8_t**,<br>
> size_t*, uint64_t*, cs_insn*)’*00:00:46*          if<br>
> (!cs_disasm_iter(handle, &data, &size, &address, insn)) {*00:00:46*<br>
>                                                               ^<br>
> <br>
> Jonathan<br>
> <br>
> On Tue, 29 Oct 2019 at 18:27, Volker Krause <<a href="mailto:vkrause@kde.org" target="_blank">vkrause@kde.org</a>> wrote:<br>
> > I haven't recently tested it on 32bit ARM, I pushed a possible fix using a<br>
> > similar approach that has been applied for x86 already. If that doesn't<br>
> > help I<br>
> > need to find a 32bit ARM setup again here to properly debug it.<br>
> > <br>
> > Regards,<br>
> > Volker<br>
> > <br>
> > On Tuesday, 29 October 2019 11:29:44 CET Jonathan Riddell wrote:<br>
> > > I'm getting a build failure for this on 32-bit arm<br>
> > <br>
> > <a href="https://build.neon.kde.org/job/bionic_unstable_neon-packaging_elf-dissecto" rel="noreferrer" target="_blank">https://build.neon.kde.org/job/bionic_unstable_neon-packaging_elf-dissecto</a><br>
> > r_> <br>
> > > bin_armhf/7/console<br>
> > > <br>
> > > disassembler.cpp:149:34: error: ‘print_insn_little_arm’ was not<br>
> > > declared in this scope<br>
> > > <br>
> > > Is it expected to build on this architecture?  It builds fine on 64 bit<br>
> > <br>
> > arm.<br>
> > <br>
> > > Jonathan<br>
> > > <br>
> > > On Sun, 27 Oct 2019 at 09:27, Volker Krause <<a href="mailto:vkrause@kde.org" target="_blank">vkrause@kde.org</a>> wrote:<br>
> > > > Thanks again for the feedback, this has now been moved to<br>
> > <br>
> > extragear/sdk.<br>
> > <br>
> > > > On Saturday, 28 September 2019 13:01:11 CET Volker Krause wrote:<br>
> > > > > Hi,<br>
> > > > > <br>
> > > > > ELF Dissector has been moved to kdereview for the usual review<br>
> > <br>
> > process.<br>
> > <br>
> > > > > <a href="https://phabricator.kde.org/source/elf-dissector/" rel="noreferrer" target="_blank">https://phabricator.kde.org/source/elf-dissector/</a><br>
> > > > > <br>
> > > > > ELF Dissector is a static analysis tool for ELF libraries and<br>
> > > > <br>
> > > > executables,<br>
> > > > <br>
> > > > > for doing things like inspecting forward and backward dependencies<br>
> > <br>
> > (on a<br>
> > <br>
> > > > > library or symbol level), identifying load-time performance<br>
> > <br>
> > bottlenecks<br>
> > <br>
> > > > > such as expensive static constructors or excessive relocations, or<br>
> > <br>
> > size<br>
> > <br>
> > > > > profiling of ELF files.<br>
> > > > > <br>
> > > > > ELF Dissector has been living in playground for more than 6 years<br>
> > > > <br>
> > > > because I<br>
> > > > <br>
> > > > > was sloppy following the right process. Since it's in active use by<br>
> > > > > a<br>
> > > > <br>
> > > > number<br>
> > > > <br>
> > > > > of people, is actively maintained and remains relevant and useful I<br>
> > > > > think<br>
> > > > > it's time to finally rectify this :)<br>
> > > > > <br>
> > > > > Regarding its final destination, extragear/sdk looks like the<br>
> > > > > obvious<br>
> > > > > candidate, as its such a niche tool that being part of the KDE<br>
> > > > <br>
> > > > Application<br>
> > > > <br>
> > > > > bundle is probably hard to argue. Once KDE Applications and the<br>
> > <br>
> > "release<br>
> > <br>
> > > > > service" are sufficiently decoupled, I'd of course be more than<br>
> > <br>
> > happy to<br>
> > <br>
> > > > > have it covered by the automatic release process.<br>
> > > > > <br>
> > > > > Regarding distribution, there is one annoying aspect, its dependency<br>
> > <br>
> > on<br>
> > <br>
> > > > > semi- public binutils API for accessing the C++ symbol demangling<br>
> > <br>
> > AST.<br>
> > <br>
> > > > That<br>
> > > > <br>
> > > > > works on conventional Linux distributions, but I failed to make it<br>
> > <br>
> > work<br>
> > <br>
> > > > as<br>
> > > > <br>
> > > > > a Flatpak due to that.<br>
> > > > > <br>
> > > > > Regarding portability, this currently only builds on ELF-based<br>
> > <br>
> > systems,<br>
> > <br>
> > > > > although theoretically this could be useful on a Windows host used<br>
> > <br>
> > for<br>
> > <br>
> > > > > embedded Linux development too. It's not impossible to make this<br>
> > > > > work<br>
> > > > > eventually I think, but it's probably quite some work.<br>
> > > > > <br>
> > > > > Thanks,<br>
> > > > > Volker<br>
<br>
</blockquote></div>