Debugger spews elf_new_wine_thunks fixmes

Eric Pouech pouech-eric at
Tue Jun 15 14:07:15 CDT 2004

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.

More information about the wine-devel mailing list