Building Elfutils with Mingw32

Building Elfutils with Mingw32

[McAllister, Colin]

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

Hello,

I'm currently trying to determine the level of effort required to compile Elfutils for Windows using MinGW. I'd like to get a version of Elfutils compiled with libdebginfod in order to compile GDB with debuginfod support on Windows. I've currently explored two avenues...

I first tried to add support myself. I did this by trying to pull in Gnulib to support for argp, fts, and obstack. I didn't quite figure out how to get AC_SEARCH_LIBS to not error even after adding Gnulib and following the Gnulib documentation. I ended up just commenting out the AC_SEARCH_LIBS checks for the three aforementioned Gnulib modules. After a little more work, I was able to get Elfutils to configure, but when I tried to run make, I immediately hit an error that endian.h could not be found. I did see that endian.h is not included in Gnulib, so I wasn't sure how to deal with that error.

The second avenue opened up when I found a post from a couple years ago where Ulf Hermann was able to fork Elfutils and add support for compiling on Windows.
https://sourceware.org/pipermail/elfutils-devel/2018q3/001166.html

It looks like this fork hasn't been updated since version 0.175, which is quite a way back from when Debuginfod support was added. I figured if I could get Ulf's fork to compile, I could then try to merge his fork with a recent version of Elfutils and manually handle all the merge conflicts. This seems like the better avenue, but the number of merge conflicts is quite high.

I'm definitely not an expert when it comes to Elfutils, Autotools, and Mingw/Windows, so I was hoping I could reach out to the community for help. Any help or support would be most appreciated!

Thanks,
Colin

Re: Building Elfutils with Mingw32

[Frank Ch. Eigler]

Hi, Colin -

> I'm currently trying to determine the level of effort required to
> compile Elfutils for Windows using MinGW. I'd like to get a version
> of Elfutils compiled with libdebginfod in order to compile GDB with
> debuginfod support on Windows. I've currently explored two
> avenues...

Nice.  Please be aware of the distinct configury options to build the
debuginfod client (library linked into gdb) and the server (program).
Some of the packages you're looking for ("fts") are only used on the
server, so you wouldn't need them for your gdb project.

.../configure --help:

  --enable-libdebuginfod  Build debuginfod client library (can be =dummy)
  --enable-debuginfod     Build debuginfod server
  --enable-debuginfod-urls[=URLS]

(I'm sorry I can't be more helpful with your substantial questions.)


- FChE

Re: Building Elfutils with Mingw32

[Ulf Hermann]

Hi,

keeping the windows/elfutils fork up to date definitely is a lot of 
work, which is why I haven't found the time to do it for a while. 
However, perfparser could in fact also use debuginfod (with some caveats).

I guess that some more of my patches could be upstreamed if properly 
cleaned up. A rebase rather than a merge may be more conductive to this.

All I can do right now is tell you that I'd be happy about any 
contribution. The repository I've been using still exists and accepts 
outside contributions. See 
https://codereview.qt-project.org/q/repo:qt-creator/elfutils . You have 
to go through the Qt CLA process to work with it, but the CLA is largely 
meaningless in this case. I'd be happy to move the repository to a more 
"official" place without CLA.

There have also been other people on this mailing list talking about 
porting elfutils to windows. Maybe if we combine our efforts we'll 
actually find a way to maintain a port.

best regards,
Ulf

RE: Building Elfutils with Mingw32

[McAllister, Colin]

Hi Ulf,

I did see that there were quite a few patches sent to the ML toward the end of 2022 that attempted to add Windows support.
https://sourceware.org/pipermail/elfutils-devel/2022q4/005449.html
https://sourceware.org/pipermail/elfutils-devel/2022q4/005667.html

It looks like some of the patches were merged, but quite a few were never applied. I'm wondering if it'd be possible to finish adding support upstream such that a fork would no longer be needed?

I would be happy to help contribute however I can.

Best,
Colin

-----Original Message-----
From: Ulf Hermann <ulf.hermann@qt.io> 
Sent: Thursday, September 14, 2023 1:34 AM
To: McAllister, Colin <Colin.McAllister@garmin.com>; elfutils-devel@sourceware.org
Subject: Re: Building Elfutils with Mingw32

CAUTION - EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.


Hi,

keeping the windows/elfutils fork up to date definitely is a lot of work, which is why I haven't found the time to do it for a while.
However, perfparser could in fact also use debuginfod (with some caveats).

I guess that some more of my patches could be upstreamed if properly cleaned up. A rebase rather than a merge may be more conductive to this.

All I can do right now is tell you that I'd be happy about any contribution. The repository I've been using still exists and accepts outside contributions. See https://urldefense.com/v3/__https://codereview.qt-project.org/q/repo:qt-creator/elfutils__;!!EJc4YC3iFmQ!V-n1VhUSf6Zz6kOtv6XIbgO0el_54wkfPU0fV7nrQMXmpser6j6-rFUtlaE2bw6kNlqXpIYTJpkFBTF13J0n02PTDg$  . You have to go through the Qt CLA process to work with it, but the CLA is largely meaningless in this case. I'd be happy to move the repository to a more "official" place without CLA.

There have also been other people on this mailing list talking about porting elfutils to windows. Maybe if we combine our efforts we'll actually find a way to maintain a port.

best regards,
Ulf

Re: Building Elfutils with Mingw32

[Ulf Hermann]

Indeed I have noticed the other patches, but I don't think they are the 
same as mine. So, now we have a three way merge.

I guess some more of the changes could be merged if properly cleaned up 
and made to benefit other obscure platforms, too. However, there are a 
few I got a definite "no" for. In particular the windows dance around 
text/binary mode when opening files was not welcome. I couldn't come up 
with a better solution than adding an O_BINARY or O_TEXT to every single 
open() call. We actually need the distinction as some files need to be 
opened in text mode for the tests to pass. If you can come up with 
anything better here, please let me know.

best regards,
Ulf

Re: Building Elfutils with Mingw32

[McAllister, Colin]

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

Ulf,

My only other suggestion for avoiding manually specifying O_BINARY and O_TEXT would be to override the open call on Windows and use O_BINARY as the default and switch to O_TEXT on a condition. Maybe that condition could be based on the file signature or some other analysis of the file contents. Probably not the most efficient or deterministic solution, but it's the only alternative I can think of. Specifying O_BINARY and O_TEXT is probably the better option. Gnulib states that O_BINARY and O_TEXT are "essential for portability to native Windows platforms" https://www.gnu.org/software/gnulib/manual/html_node/fcntl_002eh.html

Best,
Colin
________________________________
From: Ulf Hermann <ulf.hermann@qt.io>
Sent: Friday, September 15, 2023 01:57
To: McAllister, Colin <Colin.McAllister@garmin.com>; elfutils-devel@sourceware.org <elfutils-devel@sourceware.org>
Subject: Re: Building Elfutils with Mingw32

CAUTION - EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.


Indeed I have noticed the other patches, but I don't think they are the
same as mine. So, now we have a three way merge.

I guess some more of the changes could be merged if properly cleaned up
and made to benefit other obscure platforms, too. However, there are a
few I got a definite "no" for. In particular the windows dance around
text/binary mode when opening files was not welcome. I couldn't come up
with a better solution than adding an O_BINARY or O_TEXT to every single
open() call. We actually need the distinction as some files need to be
opened in text mode for the tests to pass. If you can come up with
anything better here, please let me know.

best regards,
Ulf

Re: Building Elfutils with Mingw32

[Mark Wielaard]

Hi Colin, Hi Ulf,

On Thu, Sep 14, 2023 at 07:44:08PM +0000, McAllister, Colin via Elfutils-devel wrote:
> I did see that there were quite a few patches sent to the ML toward the end of 2022 that attempted to add Windows support.
> https://sourceware.org/pipermail/elfutils-devel/2022q4/005449.html
> https://sourceware.org/pipermail/elfutils-devel/2022q4/005667.html
> 
> It looks like some of the patches were merged, but quite a few were never applied. I'm wondering if it'd be possible to finish adding support upstream such that a fork would no longer be needed?
> 
> I would be happy to help contribute however I can.

Thanks. It would be nice if elfutils was a bit more portable.  The
trouble is that not many people have that much experience with
Windows.  At least I have none.  When reviewing these patches I always
get really confused. And I don't fully understand the use case. Given
that Windows doesn't even use ELF why would you even want elfutils on
such a platform? And why aren't people simply using cygwin for such a
port. Without it you don't even have a normal POSIX like system. 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?

But all that really is my confusion. It does make reviewing these
change proposals really hard though. Because I often don't know
whether some abstraction is really needed. And I do worry about
unnecessary abstractions/ifdefs/code because it is unclear how to
maintain them long term if I am not sure why.

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?

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

Thanks,

Mark

Re: Building Elfutils with Mingw32

[Ulf Hermann]

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

Re: Building Elfutils with Mingw32

[Ulf Hermann]

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

I guess shipping cygwin with perfparser would make me a 3PP [1]. Sounds 
like fun.

[1] https://www.cygwin.com/acronyms/#3PP

Re: Building Elfutils with Mingw32

[Mark Wielaard]

On Sat, 2023-09-16 at 09:33 +0200, Ulf Hermann via Elfutils-devel
wrote:
> > 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.
> 
> I guess shipping cygwin with perfparser would make me a 3PP [1]. Sounds 
> like fun.
> 
> [1] https://www.cygwin.com/acronyms/#3PP

:) But I think the real solution would be for someone to package
elfutils for cygwin.
https://www.cygwin.com/packaging-contributors-guide.html

That way people that need the elfutils tools on windows can just get
them through cygwin. It might not be a total solution for people
needing to use the libraries when building for mingw with some other
posix compatibility layer, but it seems the best solution for just
getting the elfutils tools easily available on Windows.

It would be great if we could get some volunteer for packaging elfutils
for cygwin.

Cheers,

Mark

Re: Building Elfutils with Mingw32

[Milian Wolff]

[-- 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 --]

RE: Building Elfutils with Mingw32

[McAllister, Colin]

Hello,

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

This is also our use case. I support developers that use Windows on their host PC to develop Embedded Linux applications. I’m currently exploring options to provide Windows users the same development tooling to use GDB with Debuginfod for them to be able to debug Embedded Linux applications.

> Those people are not me and I'm not talking about sanity.

Likewise 😊
 
> > 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.

I would prefer to use MinGW instead of Cygwin. For some extra context, we use the Yocto Project to build our Embedded Linux images, which can provide a cross compiler toolchain and other host development tools for Windows using MinGW.

The Yocto Project has added a distribution feature to enable Debuginfod support for developers.
https://elinux.org/images/d/d4/005-1400-SLIDES-using_debuginfod_with_the_yocto_project.pdf
This feature is now enabled by default. The feature compiles Elfutils and GDB with Debuginfod support enabled. Additionally, there's tooling to easily stand up a local Debuginfod server that hosts the RPM/DEB/IPK packages built by Yocto.

Unfortunately, due to Elfutils being unable to be built with MinGW, the Debuginfod distribution feature is prevented from being enabled for the Windows SDK. If MinGW support was added to Elfutils, I could submit a patch to the Yocto Project to allow the distribution feature to be used for the Windows SDK. This would likely be helpful for others in the community.

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

If support cannot be added to the main branch, this sounds like an acceptable option to me.

Best regards,
Colin

Re: Building Elfutils with Mingw32

[Frank Ch. Eigler]

Hi -

> [...] I would prefer to use MinGW instead of Cygwin. For some extra
> context, we use the Yocto Project to build our Embedded Linux
> images, which can provide a cross compiler toolchain and other host
> development tools for Windows using MinGW. [...]

FWIW, I'm not aware of any conflict between these toolsets, to the
extent that anything would prevent you from using together some tools
built for the mingw runtime, and other tools built for cygwin.

- FChE

Re: Building Elfutils with Mingw32

[Mark Wielaard]

Hi,

On Mon, 2023-09-18 at 13:18 +0000, McAllister, Colin via Elfutils-devel
wrote:
> > 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.
> 
> This is also our use case. I support developers that use Windows on their host PC to develop Embedded Linux applications. I’m currently exploring options to provide Windows users the same development tooling to use GDB with Debuginfod for them to be able to debug Embedded Linux applications.
> 
> > Those people are not me and I'm not talking about sanity.
> 
> Likewise 😊
>  
> > > 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.
> 
> I would prefer to use MinGW instead of Cygwin.

So for those people preferring MinGW over Cygwin you still need some
posix/linux compatibility layer. It isn't clear to me what that needs
to be. It seems to become very complicated very quickly. For example
there is this patch series:

https://patchwork.sourceware.org/project/elfutils/list/?series=15310&state=*

I have reviewed and pushed various of those patches where they made
sense (to me). But as you can see there are various patches that were
just rejected and others where I really don't understand the real
issue/solution.

If someone could help reviewing those that would be really appreciated.

Thanks,

Mark