adapt to breaking changes in libdwarf api

[chillenb]

I ran into some issues trying to use variable name recovery:

• The libdwarf provided by my OS is too new; it's missing a bunch of deprecated symbols (dwarf_siblingof, etc). This is my attempt to use the recommended replacement functions. I know very little about libdwarf, but it seems to pass the tests.
• For some reason, my libdwarf headers are located at /usr/include/libdwarf-2, not /usr/include/libdwarf. I changed the makefiles to find the right directory with pkg-config. Does it work on your system?

[AjayBrahmakshatriya]

Hey @chillenb, I checked out your PR on my computer which has the following libdwarf and libdwarf-dev version installed -

libdwarf-dev/jammy,now 20210528-1 amd64 [installed]
  library to consume and produce DWARF debug information

libdwarf1/jammy,now 20210528-1 amd64 [installed,automatic]
  library to consume and produce DWARF debug information (runtime)

It seems these packages don't export pkg-config configurations. The output from pkf-config --list-all | grep dwarf is empty. However libunwind and libelf are present.

I think a better alternative for now could be to use a Makefile variable called LIBDWARF_PATH akin to the currently present LIBUNWIND_PATH?

Could you also share the version of libdwarf you have installed and perhaps the OS you are using?

[chillenb]

I have libdwarf 2.0 from arch. The lack of a .pc file is unfortunate indeed! At least newer versions of libdwarf provide one.

Debian testing has an incompatible libdwarf, but debian stable and all ubuntu releases use an older version that still has the deprecated functions.

I can revert all changes to the build system and handle those quirks in my downstream project for now--how does that sound?

[AjayBrahmakshatriya]

That makes sense! I figured libdwarf2 isn't the same as libdwarf, hence the different location for the headers. We could support both libdwarf and libdwarf2 with some build system flags and wrapping the function with #ifdef macros.

If you could manage it downstream in a fork that would also be fine. Since I don't modify the the part that touches variable name recovery a lot, future changes to BuildIt should be easy to merge into your fork.

Let me know if supporting libdwarf2 would be preferred. I might need some help with testing it since I don't have an arch installation lying around.

Finally, I would be curious to hear about what you are trying to use BuildIt for. If you haven't already seen this, https://github.com/BuildIt-lang/buildit-dep-template is a handy template for projects that use BuildIt as a dependency. It has all build system stuff figured out.

There is also a partially complete documentation - https://buildit.so/documentation/ which among other things has the suggested way to link against BuildIt. The regular use is straightforward, but when turning on RECOVER_VAR_NAMES=1 the flags change and BuildIt's make system itself exports those flags. It is documented under https://buildit.so/documentation/installation.html

[AjayBrahmakshatriya]

@chillenb Not sure if you still want to merge support for libdwarf2 into BuildIt upstream. Let me know if you need help wiith. If not, should we close this PR?