Closed GoogleCodeExporter closed 8 years ago
What's going on here is that yasm generates a single "COMDAT" for the contents
of each .ASM file. The instrumenter is conservative in what it will instrument,
in that it'll only instrument pointers to the start of a "COMDAT" (which
appears to the instrumenter as a "section contribution" in symbol information).
By adding a unique section/segment directive before each function declaration,
e.g.
section .text$2
;void vp8_short_fdct4x4_sse2(short *input, short *output, int pitch)
global sym(vp8_short_fdct4x4_sse2) PRIVATE
sym(vp8_short_fdct4x4_sse2):
Yasm will implicitly generate separate "COMDATs", as each function is assigned
a separate segment.
Maybe this could be folded into a new macro, "function(x)" which could
concatenate e.g. __LINE__ into a SECTION directive?
I see there's a feature request filed against yasm to add comdats
[http://tortall.lighthouseapp.com/projects/78676/tickets/210-support-comdat-sect
ionsymbol-for-windowscoff], but it's been deferred several times.
It's not a bad idea to deposit each function in a separate COMDAT in any case,
as otherwise the linker will bring in all the functions in a given .OBJ file
(and the transitive closure of their dependencies) if even only one of them is
referenced.
Alternatively we could make the instrumenter less conservative, although we
know there are compiler support functions in the CRT that fall into the same
general category of trouble, and so we'd have to find a way to back off on
those functions somehow.
Original comment by siggi@chromium.org
on 9 Jan 2013 at 8:54
Adding "SEGMENT .text$<unique_identifier>" in asm file did solve the problem.
Thanks!
Original comment by yunqingw...@google.com
on 10 Jan 2013 at 2:35
This issue is either invalid or it concern Chrome, if so please fill a bug at
crbug.com
Original comment by sebmarch...@google.com
on 26 Mar 2014 at 2:43
Original issue reported on code.google.com by
yunqingw...@google.com
on 15 Dec 2012 at 12:48Attachments: