On Wed, 2012-11-28 at 17:31 +0100, Jan Kratochvil wrote: > Application should be able to write its own parser > and this is just one its instance (it could not anyway but that is a different > patch "[patch 3/4] unwinder: Provide dwfl_core_filename_report").
Yeah. You are a few steps ahead of me. > But in practice if you used dwfl_standard_argp then an application had to give > up using USERDATA and there was no other field for the application left, as > application cannot modify dwfl_standard_argp to share the USERDATA field some > way, so an application would have to copy+modify / reimplement > dwfl_standard_argp. Which is not great just to save a Dwfl_Module field. So in the end it is just an dwfl_standard_argp () implementation detail. OK, I cannot think of a better way than using some internal libwfl field. And if we do think of something better we now have testcases. Still one suggestion. There can be only one executable for a core based Dwfl, can't there? So if we are using libdwfl internals anyway it seems better to store the state in the Dwfl struct instead of reserving a field in each Dwfl_Module struct. And one nit. The libdwfl/ChangeLog has a line that is way too long. Thanks, Mark _______________________________________________ elfutils-devel mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/elfutils-devel
