llvm dev - Jun 2017 - RFC: ODR checker for Clang and LLD

Hi all,

I'd like to propose an ODR checker feature for Clang and LLD. The feature
would be similar to gold's --detect-odr-violations feature, but better: we
can rely on integration with clang to avoid relying on debug info and to
perform more precise matching.

The basic idea is that we use clang's ability to create ODR hashes for
declarations. ODR hashes are computed using all information about a
declaration that is ODR-relevant. If the flag -fdetect-odr-violations is
passed, Clang will store the ODR hashes in a so-called ODR table in each
object file. Each ODR table will contain a mapping from mangled declaration
names to ODR hashes. At link time, the linker will read the ODR table and
report any mismatches.

To make this work:
- LLVM will be extended with the ability to represent ODR tables in the IR
and emit them to object files
- Clang will be extended with the ability to emit ODR tables using ODR
hashes
- LLD will be extended to read ODR tables from object files

I have implemented a prototype of this feature. It is available here:
https://github.com/pcc/llvm-project/tree/odr-checker and some results from
applying it to chromium are here: crbug.com/726071
As you can see it did indeed find a number of real ODR violations in
Chromium, including some that wouldn't be detectable using debug info.

If you're interested in what the format of the ODR table would look like,
that prototype shows pretty much what I had in mind, but I expect many
other aspects of the implementation to change as it is upstreamed.

Thanks,
-- 
-- 
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170606/73160fd1/attachment.html>

Very nice and simple implementation!

Do you have any statistics on how large these odr tables are compared to
other object file data? I assume that if these tables contain full mangled
symbol names, they could end up being very large and may want to share the
symbol name strings with the overall string table in the .o

Also, do you have any numbers on the performance of your initial
implementation?

W.r.t. LLD and having it always on by default (and hence making it as fast
as possible), it seems like right now you are implementing the checking
process with a hash table. That's simple and fine for a first
implementation, but it's probably worth mentioning in a comment the problem
of checking the tables, at least from the linker's perspective, does fit
into a map-reduce pattern and could be easily parallelized if needed. E.g.
a parallel sort to coalesce all entries for symbols of the same name
followed by a parallel forEach to check each bucket with the same symbol
name (roughly speaking).

Even better than doing it faster is just doing less work. There's a lot of
work that the linker is already doing that may be reusable for the ODR
checking.
E.g.
- maybe we could get the coalescing step as a byproduct of our existing
string deduping, which we are generally doing anyway.
- we are already coalescing symbol names for the symbol table. If the ODR
table is keyed off of symbols in the binary that we are inserting into the
symbol table, then I think we could do the entire ODR check with no extra
"string" work on LLD's part.

I see Rui already mentioned some of this in
https://bugs.chromium.org/p/chromium/issues/detail?id=726071#c4.
You mentioned that not everything is necessarily directly keyed on a symbol
(such as types), but I think that it would really simplify things if the
check was done as such. Do you have any idea exactly how much of the things
that we want to check are not keyed on symbols? If most things are keyed on
symbols, for the things we are not we can just emit extra symbols prefixed
by __clang_odr_check_ or whatever.

The issue of retaining the ODR check for functions even if they get inlined
may inherently pose an extra cost that can't be folded into existing work
the linker is doing, so there might be a reason for clang to have a default
mode that has practically no linking overhead and one that does more
thorough checking but imposes extra linking overhead. Think something like
a crazy boost library with thousands of functions that get inlined away,
but have gigantic mangled names and so precisely are the ones that are
going to impose extra cost on the linker. Simply due to the extra volume of
strings that the linker would need to look at, I don't think there's a
way
to include checking of all inlined function "for free" at the linker
level
using the symbol approach.

I guess those inlined functions would still have those symbol names in
debug info (I think?), so piggybacking on the string deduplication we're
already doing might make it possible to fold away the work in that case
(but then again, would still impose extra cost with split dwarf...).

Anyway, let's wait to see what the actual performance numbers are.

-- Sean Silva

On Tue, Jun 6, 2017 at 10:40 PM, Peter Collingbourne via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> Hi all,
>
> I'd like to propose an ODR checker feature for Clang and LLD. The
feature
> would be similar to gold's --detect-odr-violations feature, but better:
we
> can rely on integration with clang to avoid relying on debug info and to
> perform more precise matching.
>
> The basic idea is that we use clang's ability to create ODR hashes for
> declarations. ODR hashes are computed using all information about a
> declaration that is ODR-relevant. If the flag -fdetect-odr-violations is
> passed, Clang will store the ODR hashes in a so-called ODR table in each
> object file. Each ODR table will contain a mapping from mangled declaration
> names to ODR hashes. At link time, the linker will read the ODR table and
> report any mismatches.
>
> To make this work:
> - LLVM will be extended with the ability to represent ODR tables in the IR
> and emit them to object files
> - Clang will be extended with the ability to emit ODR tables using ODR
> hashes
> - LLD will be extended to read ODR tables from object files
>
> I have implemented a prototype of this feature. It is available here:
> https://github.com/pcc/llvm-project/tree/odr-checker and some results
> from applying it to chromium are here: crbug.com/726071
> As you can see it did indeed find a number of real ODR violations in
> Chromium, including some that wouldn't be detectable using debug info.
>
> If you're interested in what the format of the ODR table would look
like,
> that prototype shows pretty much what I had in mind, but I expect many
> other aspects of the implementation to change as it is upstreamed.
>
> Thanks,
> --
> --
> Peter
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170607/dfb2e93f/attachment.html>

Does this need LLVM support - or is there some generic representation that
could be used instead? (I guess LLVM would want to be aware of it when
merging modules though, so maybe it's worth having a first-class
representation - though LLVM module linking could special case a section
the same way the linker could/would - not sure what's the better choice
there)

I was thinking (hand-wavingly vague since I don't know that much about
object files, etc) one of those auto-appending sections and an array of
constchar*+hash attributed to that section. (then even without an
odr-checking aware linker (which would compare and discard these sections)
the data could be merged & a post-processing pass on the binary could still
point out ODR violations without anything in the toolchain (except clang)
needing to support this extra info)

On Tue, Jun 6, 2017 at 10:41 PM Peter Collingbourne via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> Hi all,
>
> I'd like to propose an ODR checker feature for Clang and LLD. The
feature
> would be similar to gold's --detect-odr-violations feature, but better:
we
> can rely on integration with clang to avoid relying on debug info and to
> perform more precise matching.
>
> The basic idea is that we use clang's ability to create ODR hashes for
> declarations. ODR hashes are computed using all information about a
> declaration that is ODR-relevant. If the flag -fdetect-odr-violations is
> passed, Clang will store the ODR hashes in a so-called ODR table in each
> object file. Each ODR table will contain a mapping from mangled declaration
> names to ODR hashes. At link time, the linker will read the ODR table and
> report any mismatches.
>
> To make this work:
> - LLVM will be extended with the ability to represent ODR tables in the IR
> and emit them to object files
> - Clang will be extended with the ability to emit ODR tables using ODR
> hashes
> - LLD will be extended to read ODR tables from object files
>
> I have implemented a prototype of this feature. It is available here:
> https://github.com/pcc/llvm-project/tree/odr-checker and some results
> from applying it to chromium are here: crbug.com/726071
> As you can see it did indeed find a number of real ODR violations in
> Chromium, including some that wouldn't be detectable using debug info.
>
> If you're interested in what the format of the ODR table would look
like,
> that prototype shows pretty much what I had in mind, but I expect many
> other aspects of the implementation to change as it is upstreamed.
>
> Thanks,
> --
> --
> Peter
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170607/9cd1ccff/attachment.html>

As to the performance on the linker side, one thing I'd like to note about
is that we might be able to use some probabilistic approach (e.g. a bloom
filter-ish data structure). In that sense, .odrtab doesn't have to contain
complete information to detect ODR violations. Instead, it can contain
hints. If the table allows us quickly verify that there's no ODR violation
with 99.99% probability for each identifier, for example, then we can fall
back to the debug info to see if the remaining 0.01% are real, and the cost
of false positive is probably negligible.

I can imagine for example that we can store a 32-bit hash for each mangled
name and compare hashes instead of large strings.

On Wed, Jun 7, 2017 at 8:18 AM, David Blaikie via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> Does this need LLVM support - or is there some generic representation that
> could be used instead? (I guess LLVM would want to be aware of it when
> merging modules though, so maybe it's worth having a first-class
> representation - though LLVM module linking could special case a section
> the same way the linker could/would - not sure what's the better choice
> there)
>
> I was thinking (hand-wavingly vague since I don't know that much about
> object files, etc) one of those auto-appending sections and an array of
> constchar*+hash attributed to that section. (then even without an
> odr-checking aware linker (which would compare and discard these sections)
> the data could be merged & a post-processing pass on the binary could
still
> point out ODR violations without anything in the toolchain (except clang)
> needing to support this extra info)
>
> On Tue, Jun 6, 2017 at 10:41 PM Peter Collingbourne via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> Hi all,
>>
>> I'd like to propose an ODR checker feature for Clang and LLD. The
feature
>> would be similar to gold's --detect-odr-violations feature, but
better: we
>> can rely on integration with clang to avoid relying on debug info and
to
>> perform more precise matching.
>>
>> The basic idea is that we use clang's ability to create ODR hashes
for
>> declarations. ODR hashes are computed using all information about a
>> declaration that is ODR-relevant. If the flag -fdetect-odr-violations
is
>> passed, Clang will store the ODR hashes in a so-called ODR table in
each
>> object file. Each ODR table will contain a mapping from mangled
declaration
>> names to ODR hashes. At link time, the linker will read the ODR table
and
>> report any mismatches.
>>
>> To make this work:
>> - LLVM will be extended with the ability to represent ODR tables in the
>> IR and emit them to object files
>> - Clang will be extended with the ability to emit ODR tables using ODR
>> hashes
>> - LLD will be extended to read ODR tables from object files
>>
>> I have implemented a prototype of this feature. It is available here:
>> https://github.com/pcc/llvm-project/tree/odr-checker and some results
>> from applying it to chromium are here: crbug.com/726071
>> As you can see it did indeed find a number of real ODR violations in
>> Chromium, including some that wouldn't be detectable using debug
info.
>>
>> If you're interested in what the format of the ODR table would look
like,
>> that prototype shows pretty much what I had in mind, but I expect many
>> other aspects of the implementation to change as it is upstreamed.
>>
>> Thanks,
>> --
>> --
>> Peter
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170607/09994b7c/attachment.html>

On Wed, Jun 7, 2017 at 12:17 AM, Sean Silva <chisophugis at gmail.com>
wrote:
> Very nice and simple implementation!
>
> Do you have any statistics on how large these odr tables are compared to
> other object file data? I assume that if these tables contain full mangled
> symbol names, they could end up being very large and may want to share the
> symbol name strings with the overall string table in the .o
>
Looking at Chromium's object files it looks like the total size of the
odrtabs is about 50% of the total size of the object files, which isn't
great. The current implementation only looks at records, so I imagine that
it would be hard to share any of the strings that I'm currently creating.
(I guess it's possible that some types will have a mangled vtable name in
the string table, so we may be able to share a little that way.) Note
however that this was without debug info.

One option for reducing size would be to
1) store hashes of ODR names in ODR tables, per Rui's suggestion (alongside
a reference to the name itself in the string table)
2) compress the string table for the ODR names with a standard compression
algorithm like gzip.
This wouldn't seem to affect link time performance much because I think we
should only need to look at the strings if we see a ODR name hash match
together with an ODR hash mismatch, which would mean an ODR violation with
a high probability (i.e. unless there was an ODR name hash collision, we
have found an ODR violation). If we don't expect a lot of sharing with
regular string tables (see below), it seems even more reasonable.

Also, do you have any numbers on the performance of your
initial
> implementation?
>
I measured the link time for chromium's unit_tests (the largest single
binary in chromium) at 5.05s without ODR checks and 6.61s with ODR checks.
So about 30% overhead, but in absolute terms it doesn't seem too bad. So I
think this may be acceptable for an initial implementation, but it
certainly seems worth trying to do better.

W.r.t. LLD and having it always on by default (and hence making it as
fast
> as possible), it seems like right now you are implementing the checking
> process with a hash table. That's simple and fine for a first
> implementation, but it's probably worth mentioning in a comment the
problem
> of checking the tables, at least from the linker's perspective, does
fit
> into a map-reduce pattern and could be easily parallelized if needed. E.g.
> a parallel sort to coalesce all entries for symbols of the same name
> followed by a parallel forEach to check each bucket with the same symbol
> name (roughly speaking).
>
Right, that's one approach. I was thinking of a simpler approach where at
compile time we sort ODR names by hash and partition them using (say) the
upper bits of the hash, so that at link time we can have N threads each
building a hash table for a specific partition.

And of course this work can be started right after symbol resolution
finishes and parallelised with the rest of the work done by the linker.

Even better than doing it faster is just doing less work. There's a lot
of
> work that the linker is already doing that may be reusable for the ODR
> checking.
> E.g.
> - maybe we could get the coalescing step as a byproduct of our existing
> string deduping, which we are generally doing anyway.
> - we are already coalescing symbol names for the symbol table. If the ODR
> table is keyed off of symbols in the binary that we are inserting into the
> symbol table, then I think we could do the entire ODR check with no extra
> "string" work on LLD's part.
>
> I see Rui already mentioned some of this in https://bugs.chromium.org/p
> /chromium/issues/detail?id=726071#c4.
> You mentioned that not everything is necessarily directly keyed on a
> symbol (such as types), but I think that it would really simplify things if
> the check was done as such. Do you have any idea exactly how much of the
> things that we want to check are not keyed on symbols? If most things are
> keyed on symbols, for the things we are not we can just emit extra symbols
> prefixed by __clang_odr_check_ or whatever.
>
Since the current implementation only works with records there is basically
zero overlap right now between ODR names and symbols. I suppose that I
could estimate the amount of function overlap in a hypothetical
implementation that computes ODR hashes of functions by comparing the
number of *_odr functions after clang has finished IRgen with the number
after optimization finishes. This of course would be strictly more than
functions + types.

> The issue of retaining the ODR check for functions even if they get
> inlined may inherently pose an extra cost that can't be folded into
> existing work the linker is doing, so there might be a reason for clang to
> have a default mode that has practically no linking overhead and one that
> does more thorough checking but imposes extra linking overhead. Think
> something like a crazy boost library with thousands of functions that get
> inlined away, but have gigantic mangled names and so precisely are the ones
> that are going to impose extra cost on the linker. Simply due to the extra
> volume of strings that the linker would need to look at, I don't think
> there's a way to include checking of all inlined function "for
free" at the
> linker level using the symbol approach.
>
>
I guess those inlined functions would still have those symbol names
in
> debug info (I think?), so piggybacking on the string deduplication
we're
> already doing might make it possible to fold away the work in that case
> (but then again, would still impose extra cost with split dwarf...).
>
> Anyway, let's wait to see what the actual performance numbers are.
>
> -- Sean Silva
>
> On Tue, Jun 6, 2017 at 10:40 PM, Peter Collingbourne via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> Hi all,
>>
>> I'd like to propose an ODR checker feature for Clang and LLD. The
feature
>> would be similar to gold's --detect-odr-violations feature, but
better: we
>> can rely on integration with clang to avoid relying on debug info and
to
>> perform more precise matching.
>>
>> The basic idea is that we use clang's ability to create ODR hashes
for
>> declarations. ODR hashes are computed using all information about a
>> declaration that is ODR-relevant. If the flag -fdetect-odr-violations
is
>> passed, Clang will store the ODR hashes in a so-called ODR table in
each
>> object file. Each ODR table will contain a mapping from mangled
declaration
>> names to ODR hashes. At link time, the linker will read the ODR table
and
>> report any mismatches.
>>
>> To make this work:
>> - LLVM will be extended with the ability to represent ODR tables in the
>> IR and emit them to object files
>> - Clang will be extended with the ability to emit ODR tables using ODR
>> hashes
>> - LLD will be extended to read ODR tables from object files
>>
>> I have implemented a prototype of this feature. It is available here:
>> https://github.com/pcc/llvm-project/tree/odr-checker and some results
>> from applying it to chromium are here: crbug.com/726071
>> As you can see it did indeed find a number of real ODR violations in
>> Chromium, including some that wouldn't be detectable using debug
info.
>>
>> If you're interested in what the format of the ODR table would look
like,
>> that prototype shows pretty much what I had in mind, but I expect many
>> other aspects of the implementation to change as it is upstreamed.
>>
>> Thanks,
>> --
>> --
>> Peter
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>>
>

-- 
-- 
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170607/6b486a06/attachment.html>

On Wed, Jun 7, 2017 at 8:18 AM, David Blaikie <dblaikie at gmail.com>
wrote:
> Does this need LLVM support - or is there some generic representation that
> could be used instead? (I guess LLVM would want to be aware of it when
> merging modules though, so maybe it's worth having a first-class
> representation - though LLVM module linking could special case a section
> the same way the linker could/would - not sure what's the better choice
> there)
>
The only thing that LLVM needs to do is to have some way to store a blob
that will be emitted to the object file. In my prototype I just create a
GlobalVariable with private linkage, I think in the final version I will
use an MDString referenced by a named MD node. I don't think we would want
a higher level representation -- I'd imagine that the blob would be
entirely a property of the source code, so I can't see anything that an
IR-level pass would want to do with it. It's similar to some parts of debug
info in that there's no real benefit to representing it as anything other
than a blob.

I was thinking (hand-wavingly vague since I don't know that much
about
> object files, etc) one of those auto-appending sections and an array of
> constchar*+hash attributed to that section. (then even without an
> odr-checking aware linker (which would compare and discard these sections)
> the data could be merged & a post-processing pass on the binary could
still
> point out ODR violations without anything in the toolchain (except clang)
> needing to support this extra info)
>
Linkers merge section contents by section name, so you wouldn't need
anything other than for the object files to agree on a section name. The
odrtab header in my prototype has a size field, so we could use that to
split an .odrtab section into multiple odrtabs.

Peter

On Tue, Jun 6, 2017 at 10:41 PM Peter Collingbourne via cfe-dev
<
> cfe-dev at lists.llvm.org> wrote:
>
>> Hi all,
>>
>> I'd like to propose an ODR checker feature for Clang and LLD. The
feature
>> would be similar to gold's --detect-odr-violations feature, but
better: we
>> can rely on integration with clang to avoid relying on debug info and
to
>> perform more precise matching.
>>
>> The basic idea is that we use clang's ability to create ODR hashes
for
>> declarations. ODR hashes are computed using all information about a
>> declaration that is ODR-relevant. If the flag -fdetect-odr-violations
is
>> passed, Clang will store the ODR hashes in a so-called ODR table in
each
>> object file. Each ODR table will contain a mapping from mangled
declaration
>> names to ODR hashes. At link time, the linker will read the ODR table
and
>> report any mismatches.
>>
>> To make this work:
>> - LLVM will be extended with the ability to represent ODR tables in the
>> IR and emit them to object files
>> - Clang will be extended with the ability to emit ODR tables using ODR
>> hashes
>> - LLD will be extended to read ODR tables from object files
>>
>> I have implemented a prototype of this feature. It is available here:
>> https://github.com/pcc/llvm-project/tree/odr-checker and some results
>> from applying it to chromium are here: crbug.com/726071
>> As you can see it did indeed find a number of real ODR violations in
>> Chromium, including some that wouldn't be detectable using debug
info.
>>
>> If you're interested in what the format of the ODR table would look
like,
>> that prototype shows pretty much what I had in mind, but I expect many
>> other aspects of the implementation to change as it is upstreamed.
>>
>> Thanks,
>> --
>> --
>> Peter
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>

-- 
-- 
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170607/2f5abe48/attachment.html>

Peter Collingbourne via llvm-dev <llvm-dev at lists.llvm.org> writes:
> Hi all,
>
> I'd like to propose an ODR checker feature for Clang and LLD. The
feature
> would be similar to gold's --detect-odr-violations feature, but better:
we
> can rely on integration with clang to avoid relying on debug info and to
> perform more precise matching.
It seems a really nice idea. Do you have performance numbers?

I agree with others that suggested putting the strings in .strtab. For
-O0 at least it should save many duplicates.

Cheers,
Rafael

On Wed, Jun 7, 2017 at 7:59 PM, Rafael Avila de Espindola <
rafael.espindola at gmail.com> wrote:
> Peter Collingbourne via llvm-dev <llvm-dev at lists.llvm.org> writes:
>
> > Hi all,
> >
> > I'd like to propose an ODR checker feature for Clang and LLD. The
feature
> > would be similar to gold's --detect-odr-violations feature, but
better:
> we
> > can rely on integration with clang to avoid relying on debug info and
to
> > perform more precise matching.
>
> It seems a really nice idea. Do you have performance numbers?
>
I gave a few perf (and binary size) numbers in my response to Sean.
http://lists.llvm.org/pipermail/llvm-dev/2017-June/113865.html

I agree with others that suggested putting the strings in .strtab.
For
> -O0 at least it should save many duplicates.
>
Maybe. As I wrote in my message to Sean it isn't clear exactly how many
duplicates we will have in practice, so it may be better to use a separate
string table and compress it. In any case it does seem to require closer
investigation and maybe more prototyping.

Thanks,
-- 
-- 
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170607/08380715/attachment.html>

+Richards (Smith & Trieu) because building functionality on top of the AST
and AST hashes here seems worth some input from them.

On Tue, Jun 6, 2017 at 10:41 PM Peter Collingbourne via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> Hi all,
>
> I'd like to propose an ODR checker feature for Clang and LLD. The
feature
> would be similar to gold's --detect-odr-violations feature, but better:
we
> can rely on integration with clang to avoid relying on debug info and to
> perform more precise matching.
>
> The basic idea is that we use clang's ability to create ODR hashes for
> declarations. ODR hashes are computed using all information about a
> declaration that is ODR-relevant. If the flag -fdetect-odr-violations is
> passed, Clang will store the ODR hashes in a so-called ODR table in each
> object file. Each ODR table will contain a mapping from mangled declaration
> names to ODR hashes. At link time, the linker will read the ODR table and
> report any mismatches.
>
> To make this work:
> - LLVM will be extended with the ability to represent ODR tables in the IR
> and emit them to object files
> - Clang will be extended with the ability to emit ODR tables using ODR
> hashes
> - LLD will be extended to read ODR tables from object files
>
> I have implemented a prototype of this feature. It is available here:
> https://github.com/pcc/llvm-project/tree/odr-checker and some results
> from applying it to chromium are here: crbug.com/726071
> As you can see it did indeed find a number of real ODR violations in
> Chromium, including some that wouldn't be detectable using debug info.
>
> If you're interested in what the format of the ODR table would look
like,
> that prototype shows pretty much what I had in mind, but I expect many
> other aspects of the implementation to change as it is upstreamed.
>
> Thanks,
> --
> --
> Peter
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170615/aa80c6bf/attachment.html>