On 13/03/2024 03:17, Daniel Xu wrote: > Hi Alan, > > On Wed, Feb 28, 2024 at 05:57:01PM -0700, Daniel Xu wrote: >> Hi Alan, >> >> On Thu, Feb 08, 2024 at 10:00:15AM +0000, Alan Maguire wrote: >>> On 04/02/2024 18:40, Daniel Xu wrote: > > [...] > >>> >>> Then all you'd need to do is iterate over BTF functions, using >>> btf_encoder__find_function() to get a function and associated ELF info >>> by name. >> >> Didn't know about this, thanks. I'll take a look at if the patch can use >> the existing function metadata. That should get rid of >> btf_encoder__collect_btf_funcs() if it works. > > I experimented with this a bit and I'm not sure if it's a good approach. > > Here are the two commits: > > https://pastes.dxuuu.xyz/xo9jwk > https://pastes.dxuuu.xyz/xmzew5 > > Basically my approach was to fan-in all the function info collected by > the different threads. I don't think it'll work cuz some of the data > (the name in particular) in struct elf_function belongs to the thread's > struct btf_encoder instance. Which is all freed by btf_encoder__delete() > before btf_encoder__encode(). > > It could probably be fixed, but doesn't seem very clean to me. So I > think it'll be better to keep the code as-is. Unless you were thinking > something different. > Thanks for trying! We may end up revisiting the freeing of ELF function/variable info in the future if we add address information from symbols into BTF, but since that's not there yet, it makes sense to do your collection separately. Alan
