Hi Eric,
I get a lot of messages like this since the new debugger shuffle patch landed:
fixme:dbghelp:elf_new_wine_thunks Duplicate in kernel32<elf>: audiocdW.6<40515de8-00000012> audiocdW<40515de8-00000000>
For now I just changed the fixme to a warn in my local tree - what does this message mean though? It makes it much harder to use the debugger currently.
thanks -mike
Mike Hearn a écrit :
Hi Eric,
I get a lot of messages like this since the new debugger shuffle patch landed:
fixme:dbghelp:elf_new_wine_thunks Duplicate in kernel32<elf>: audiocdW.6<40515de8-00000012> audiocdW<40515de8-00000000>
For now I just changed the fixme to a warn in my local tree - what does this message mean though?
To make a long story short, in the stabs information, there's no data about the actual address of the symbol. So, the address is gotten by reading some table in the ELF header (the .symtab). However, what's known to make the link between this two sets of information is: - the symbol name - the filename of the source (not the entire path) So, there are cases were the two don't exactly match: - for example, when to static symbols are defined in the same module are defined in two different source files with the same filename, but with a different pathname (believe me, it happens in wine source) - another case, the one you run into, is that for static variables declared inside functions, gcc seems to append a .NN suffix (.1 for the first one in a compilation unit, .2 for the second...) in order to get different names if two variables of same name are defined in the same compilation unit but in two different functions (or in two non nested blocks). To make things easier, this suffix is added in the .symtab table, but not in the stabs... So, in your case, the best fix is to handle the .NN suffix properly (which we don't do yet). There are also some other cases (where two symbols overlap) (for example, where symbols are defined as markers like _edata or _bss_start).
It makes it much harder to use the debugger currently.
Well, the intended output of this was: - to measure the real impact of the heuristics used for symbol matchup (which is quite low given the traffic on this topic) The other side effect was to measure the number of people who where actually using the debugger. If I assume that any decent user should report this type of error, I only counted 2 reports (yours, and Shachar on some other topics), which is IMO a rather low figure. I'll adapt my time on winedbg hacking depending on this. A+
On Tue, 2004-06-15 at 21:07 +0200, Eric Pouech wrote:
If I assume that any decent user should report this type of error, I only counted 2 reports (yours, and Shachar on some other topics), which is IMO a rather low figure. I'll adapt my time on winedbg hacking depending on this.
OK, bear in mind some users did not report it but simply reverted the patch (I know one guy who did that at least, there may well be more). Also, it's not been that long since the debugger patch landed.
Hi
--- Mike Hearn mh@codeweavers.com wrote:
OK, bear in mind some users did not report it but simply reverted the patch (I know one guy who did that at least, there may well be more). Also, it's not been that long since the debugger patch landed.
I can also say the extra stuff in the backtrace makes it a pain for me. I never do much from winedbg other than run a bt but its still a lot to look over.
Thanks Steven
__________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo
Eric Pouech wrote:
If I assume that any decent user should report this type of error, I only counted 2 reports (yours, and Shachar on some other topics),
Actually, if you'll read between the lines, you'll see this has been bugging me as well. That's the reason I sent you a diff of two runs, rather than two runs.
I actually removed that FIXME from the sources.
which is IMO a rather low figure. I'll adapt my time on winedbg hacking depending on this. A+
-
Eric Pouech -
Mike Hearn -
Shachar Shemesh -
Steven Edwards