[PATCH] D54747: Discard debuginfo for object files empty after GC
Rui Ueyama via llvm-commits
llvm-commits at lists.llvm.org
Thu May 9 04:44:53 PDT 2019
>
> Hello, in a bit of a https://xkcd.com/1172/ moment this breaks the
> chromium/android build. We have a list of "resources" (strings, bitmaps,
> etc) that we list in an XML file which then generates a header with lots of
> "IDR_foo" constants. As it turns out, now all of these resources are used
> on all platforms, so we use the following technique to only keep the ones
> actually used on android:
>
> - Have an empty template function `template<int N> Whitelist() {}`
> - Have the resource header expand IDR_foo to
> `(Whitelist<unique_id_per_resource>(), unique_id_per_resource)` where
> `unique_id_per_resource` is something like 123 (and different for every
> resource)
> - For every IDR_foo referenced in a cc file, this generates debug info for
> the function call `Whitelist<unique_id_per_resource>()`
>
> We then look at `'readelf', '-p', '.debug_str'` and grep for
> `WhitelistedResource<` and keep all resources whose ID is referenced from
> debug info.
>
> Before this change, this worked great.
>
> Now, resources that are referenced from functions that make it into the
> final binary get stripped. From the patch description, it sounds like maybe
> that shouldn't happen (can you confirm?), but in practice it does.
>
If a function is included in the final binary, its debug info shouldn't be
stripped. So something is wrong. Since the problem only occurs when LTO is
enabled, maybe LTO found that the functions are not used by anyone and
remove them, which makes the later pass to remove their debug info as well?
The way how Chrome manages resources seems a bit too tricky. I wonder if
you can use regular symbols instead of debug info. Can't you just define
symbols with empty contents with special names and search for the symbols
in the later pass?
If this only stripped debug info for functions that don't make it into the
> final binary, this would be a great change for us though!
>
>
> Repository:
> rL LLVM
>
> CHANGES SINCE LAST ACTION
> https://reviews.llvm.org/D54747/new/
>
> https://reviews.llvm.org/D54747
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20190509/ecb015f9/attachment.html>
More information about the llvm-commits
mailing list