Debugger spews elf_new_wine_thunks fixmes

[Mike Hearn]

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

[Eric Pouech]

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+

[Mike Hearn]

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.

-- 
Mike Hearn <mh(a)codeweavers.com>
CodeWeavers, Inc

[Steven Edwards]

Hi

--- Mike Hearn <mh(a)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

[Shachar Shemesh]

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+

-- 
Shachar Shemesh
Lingnu Open Source Consulting ltd.
http://www.lingnu.com/