On Thu, Jan 4, 2024 at 2:33 PM Björn Schäpers <g...@hazardy.de> wrote: > > Am 03.01.2024 um 00:12 schrieb Björn Schäpers: > > Am 30.11.2023 um 20:53 schrieb Ian Lance Taylor: > >> On Fri, Jan 20, 2023 at 2:55 AM Björn Schäpers <g...@hazardy.de> wrote: > >>> > >>> From: Björn Schäpers <bjo...@hazardy.de> > >>> > >>> Fixes https://github.com/ianlancetaylor/libbacktrace/issues/53, except > >>> that libraries loaded after the backtrace_initialize are not handled. > >>> But as far as I can see that's the same for elf. > >> > >> Thanks, but I don't want a patch that loops using goto statements. > >> Please rewrite to avoid that. It may be simpler to call a function. > >> > >> Also starting with a module count of 1000 seems like a lot. Do > >> typical Windows programs load that many modules? > >> > >> Ian > >> > >> > > > > Rewritten using a function. > > > > If that is commited, could you attribute that commit to me (--author="Björn > > Schäpers <bjo...@hazardy.de>")? > > > > Thanks and kind regards, > > Björn. > > I noticed that under 64 bit libraries loaded with LoadLibrary were missing. > EnumProcessModules stated the correct number of modules, but did not fill the > the HMODULEs, but set them to 0. While trying to investigate I noticed if I do > the very same thing from main (in C++) I even got fewer module HMODULEs. > > So I went a different way. This detects all libraries correctly, in 32 and 64 > bit. The question is, if it should be a patch on top of the previous, or > should > they be merged, or even only this solution and drop the EnumProcessModules > variant?
Is there any reason to use both patches? Seems simpler to just use this one if it works. Thanks. Ian