New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
non-debug build still refer to .debug files, while there is no symlink for it in target dir "build/$arch$/bin/" #5198
Comments
@tor-m6 linking .debug files into bin would not work because all content of bin/ ends up being integrated in the binary archives. We want to keep those archive free from the overhead of debug infos. For shipping the debug information, @cproc has enabled the creation of dbg archives via the tool/depot/create and publish tools (specify dbg instead of bin), and also equipped the on-target depot_download subsystem to handle the installation of such archives. So there are already mechanisms in place to create/publish/download debug infos via the depot tools. The question seems to be how to best apply them. Should the tools not work for you, we'd need to add a hook to the build system that allows for optionally skipping the stripping for certain targets. But I'd prefer to avoid that. @cproc may you chime in about how to best apply the tools in the case of @tor-m6 ? |
@nfeske IMHO we can have simply 2 stripped binaries - same size, one with reference inside to .debug file (as now), and second one completely stripped without reference to .debug Just omit from call to OBJCOPY reference to flag |
@tor-m6 Do I get you right that golang works without debug information in your cases but not if gnu-debuglink is set but the referenced file is not available? Wouldn't it make more sense to fallback to "no debug info" in this case? |
@chelmuth golang work without debug info, this is correct. So, if we have this flag --add-gnu-debuglink during creation of stripped binary - then libbacktrace (not golang!) found it and request it (try to open by name, try to resolve symlink in Genode open() and try to throw exception - "not found"). I checked that if I just omit this flag for stripped binaries - everything works correctly. Problem that this is normal behaviour of gcc libbacktrace in combination with Genode loader. This is very complex frame-processing engine and I prefer not to modify it. I cant force it to fallback and work only with provided debug info/etc - this is more generic mechanism. In theory, one can generate empty debug file for every such a case and link it to "bin" and to overall genode run process, while this is not seems elegant solution. |
For reference, this is the deadlock backtrace I got on base-linux:
|
Thanks @cproc that's a very welcome contribution and supports our ambition to reduce the use of exceptions. Merged to staging. |
in the commit b41df1f it was introduced the reference to separate debug file in the build.
Inside build/$arch$/debug directory it creates 2 separate links: to the stripped file and to the debug info file:
but during the "release" build it place only first link into "bin" dir, like
For applications and code which use stack unwinding (and should access to related binaries), like golang, process fail during runtime in attempt to enumerate every binary.
This is because there are still link to debug file in .stripped one, while it is not available for release version.
I see 3 options to fix a problem
The text was updated successfully, but these errors were encountered: