Re: Building Elfutils with Mingw32

[Milian Wolff <mail@milianw.de>]

[-- Attachment #1: Type: text/plain, Size: 4937 bytes --]

On Samstag, 16. September 2023 09:17:44 CEST Ulf Hermann via Elfutils-devel 
wrote:
> Hi,
> 
> I'll answer some questions here:
> > Given that Windows doesn't even use ELF why would you even want elfutils
> > on
> > such a platform?
> 
> There is a large number of developers who build software for ELF-based
> embedded systems on windows and test/debug/profile/deploy it over some
> network or USB connection. Those people want to have elfutils for their
> debugging and profiling. They want to use elfutils on the host (the
> windows box) because that is much faster.
> 
> Those people are not me and I'm not talking about sanity.
> 
> Qt Creator (the Qt IDE) has a profiling view that takes data produced by
> perf and paints pretty graphs from that. The actual perf data is
> recorded on the target (potentially an embedded device), then streamed
> or copied to the host, then run through perfparser to produce meaningful
> stack traces. perfparser uses elfutils for the actual work. That work is
> quite heavy. A sample frequency of 1000Hz is not uncommon. Few embedded
> device can do that "on the side" while still producing meaningful
> results for the actual task. Finally, Qt Creator takes the processed
> data and displays a UI to explore it. There is another UI for the same
> data, "Hotspot" by Milian, but I don't know if that can run on windows.

In theory it could - but elfutils doesn't officially support Windows which 
blocks this effort. I would love to see this change.

One potential approach that should actually be workable is using heaptrack via 
WSL. Then no porting work is needed on the elfutils side - not an option 
probably for QtCreator, but it would be "good enough" for my purposes I think.

> > And why aren't people simply using cygwin for such a port?
> 
> If we built perfparser with cygwin, the people who use it would also
> need cygwin. People building embedded devices generally have a colorful
> mess of different tools, none of which you can rely on in advance. I
> haven't considered shipping cygwin with perfparser. Is that actually
> possible? It looks like it needs some installation procedure I would
> have to burden the user with.
> 
> > Without it you don't even have a normal POSIX like system.
> 
> Indeed, but we have gnulib and the various adapters I wrote myself (some
> of which should probably be upstreamed to gnulib). That deals with the
> problem. We get binaries that only depend on a basic windows system.
> 
> This comes at the price of using the most basic C library that Microsoft
> offers, msvcrt.dll. In order to use the elfutils libraries built that
> way you have to jump through the open/close and malloc/free hoops we
> provide in eu_compat.lib. However, that is only a problem for perfparser
> or other software linked against elfutils, not for the user.
> 
> > And when using mingw do people still use a normal gcc compiler (to cross
> > build)? Or is the goal to build with some alternative windows
> > compiler?
> 
> The gold standard would indeed be the ability to build it with Microsoft
> compilers and their associated C libraries. Then we could get  rid of
> the malloc/free and open/close hacks. However, given that Microsoft
> compilers have a rather different idea of C than elfutils, I didn't go
> there. Building it with gcc is more overhead for me when producing the
> binary. I cannot cleanly integrate it into the Qt Creator build system
> since that assumes it can use the same compiler for everything. However,
> for the users it doesn't make a difference.

Another option could be to use clang, which is working very well on Windows 
too. Not perfect for QtCreator, but in theory you could build elfutils with 
clang and provide it externally.

> > But if there is consensus (among the Windows hackers) about using one
> > common target for the port then maybe we should have an official
> > branch on sourceware?
> 
> Such a thing would certainly be welcome from my point of view!

I also think so. In general, it's quite sad to see that the code used here is 
so platform dependent on such low levels.

As a wild idea: I know that C++ is used at least in the debuginfod code base - 
could we use that in more places outside of that? That would at least easily 
allow us to  access the filesystem in a platform agnostic way. At work I work 
on software that supports macos, windows and linux, and very rarely if ever do 
I have to consciously  think about these targets, thanks to C++ (and Qt).

> > Also there is a mingw container setup on builder.sourceware.org which
> > we might use for doing CI on the port?
> > https://sourceware.org/cgit/builder/tree/builder/containers/Containerfile-> > fedora-mingw
>
> I'll have to look at it in detail, but that also sounds great! So far
> there is no automated CI. I just run the tests manually when I change
> anything.
> 
> best regards,
> Ulf


-- 
Milian Wolff
mail@milianw.de
http://milianw.de

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]