On Tue, Apr 22, 2025 at 10:24 AM Serhei Makarov <ser...@serhei.io> wrote: > > On Tue, Apr 22, 2025, at 10:17 AM, Aaron Merey wrote: > >> One question this raises re: the Dwfl_Process_Tracker structure and where > >> its implementation should be located. In the patches, the Dwfl struct > >> implementation includes a pointer to a Dwfl_Process_Tracker. I’m not sure > >> if elfutils currently has a ‘lower’ level library refer to symbols from a > >> library that uses it. Would the circular dependency cause any problems? > > > > dwfl_st or dwflst prefixes work for me. I think I slightly prefer > > dwfl_st. As for where to define Dwfl_Process_tracker let's try to keep > > it to the new dwfl_stacktraceP.h and if possible use forward > > declarations to avoid circular dependencies. If it's necessary to > > include more in libdwflP.h that should be ok since it's not publicly > > exposed, > Ok, I'll test and see if a forward decl of Dwflst_Process_Tracker in > libdwflP.h works as intended. > > Starting to code this and seeing how the API/code is looking; > I would really argue for dwflst over dwfl_st. > The reason is that it becomes confusing to the casual reader > whether a symbol dwfl_st_FOO is a symbol st_FOO inside libdwfl > or a symbol FOO inside libdwfl_st. But dwflst_FOO has no such > ambiguity. > > The public header would be called libdwfl_stacktrace.h, > for immediate clarify re: what is being included.
Fair point, dwflst works for me. Aaron
