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.
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.
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!
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
