search for: odrs

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

On Sat, Jun 10, 2017 at 11:00 AM, Mehdi AMINI <joker.eph at gmail.com> wrote: > > > 2017-06-07 16:32 GMT-07:00 Peter Collingbourne via llvm-dev < > llvm-dev at lists.llvm.org>: > >> 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

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

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

On Wed, Jun 7, 2017 at 8:06 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > On Wed, Jun 7, 2017 at 4:31 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: > >> 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

On Tue, Jun 13, 2017 at 6:34 PM Peter Collingbourne via cfe-dev < cfe-dev at lists.llvm.org> wrote: > On Wed, Jun 7, 2017 at 11:28 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: > >> On Wed, Jun 7, 2017 at 8:06 PM, Sean Silva <chisophugis at gmail.com> wrote: >> >>> >>> >>> On Wed, Jun 7, 2017 at 4:31 PM, Peter Collingbourne

On Thu, Jun 15, 2017 at 10:44 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > On Thu, Jun 15, 2017 at 10:20 AM Peter Collingbourne <peter at pcc.me.uk> > wrote: > >> On Thu, Jun 15, 2017 at 1:14 AM, James Henderson < >> jh7370.2008 at my.bristol.ac.uk> wrote: >> >>> I agree with Dave here. In the environment I work in, we

Is the entry in your ODR table 64-bit? Sean mentioned that this is a birthday paradox situation, but I don't think we need that large hash values, as our aim is not to avoid any collisions. Small number of collisions is okay as it just slightly increases false negatives. I think it can even be 16-bit if space saving is important. If we choose 16-bit hash, the probability that an ODR violation

On Thu, Jun 15, 2017 at 1:14 AM, James Henderson < jh7370.2008 at my.bristol.ac.uk> wrote: > I agree with Dave here. In the environment I work in, we regularly see > users ship objects and static archives to other users, and then never > update them, even though the linker moves on. If they did this with an > object file that had contents (such as the ODR information) that were

On Tue, Jun 13, 2017 at 8:43 PM Peter Collingbourne <peter at pcc.me.uk> wrote: > On Tue, Jun 13, 2017 at 7:54 PM, David Blaikie <dblaikie at gmail.com> wrote: > >> >> >> On Tue, Jun 13, 2017 at 6:34 PM Peter Collingbourne via cfe-dev < >> cfe-dev at lists.llvm.org> wrote: >> >>> On Wed, Jun 7, 2017 at 11:28 PM, Peter Collingbourne

On Tue, Jun 13, 2017 at 10:05 PM Peter Collingbourne <peter at pcc.me.uk> wrote: > On Tue, Jun 13, 2017 at 8:48 PM, David Blaikie <dblaikie at gmail.com> wrote: > >> >> >> On Tue, Jun 13, 2017 at 8:43 PM Peter Collingbourne <peter at pcc.me.uk> >> wrote: >> >>> On Tue, Jun 13, 2017 at 7:54 PM, David Blaikie <dblaikie at

On Tue, Jun 13, 2017, 11:30 PM Peter Collingbourne <peter at pcc.me.uk> wrote: > On Tue, Jun 13, 2017 at 11:06 PM, David Blaikie <dblaikie at gmail.com> > wrote: > >> >> >> On Tue, Jun 13, 2017 at 10:05 PM Peter Collingbourne <peter at pcc.me.uk> >> wrote: >> >>> On Tue, Jun 13, 2017 at 8:48 PM, David Blaikie <dblaikie at

On Wed, Jun 14, 2017 at 1:41 PM Peter Collingbourne <peter at pcc.me.uk> wrote: > On Wed, Jun 14, 2017 at 12:47 PM, David Blaikie <dblaikie at gmail.com> > wrote: > >> >> >> On Tue, Jun 13, 2017, 11:30 PM Peter Collingbourne <peter at pcc.me.uk> >> wrote: >> >>> On Tue, Jun 13, 2017 at 11:06 PM, David Blaikie <dblaikie at

Hi! A few of us over at Google think a nice feature in clang would be ODR violation checking, and we thought for a while about how to do this and wrote it down, but we aren't actively working on it at the moment nor plan to in the near future. I'm posting this to share our design and hopefully save anyone else the design work if they're interested in it. For some background, C++'s

On Jul 11, 2013, at 5:45 PM, Nick Lewycky <nlewycky at google.com> wrote: > Hi! A few of us over at Google think a nice feature in clang would be ODR violation checking, and we thought for a while about how to do this and wrote it down, but we aren't actively working on it at the moment nor plan to in the near future. I'm posting this to share our design and hopefully save anyone

On 11 July 2013 18:02, John McCall <rjmccall at apple.com> wrote: > On Jul 11, 2013, at 5:45 PM, Nick Lewycky <nlewycky at google.com> wrote: > > Hi! A few of us over at Google think a nice feature in clang would be > ODR violation checking, and we thought for a while about how to do this and > wrote it down, but we aren't actively working on it at the moment nor

On Jul 11, 2013, at 6:13 PM, Nick Lewycky <nlewycky at google.com> wrote: > On 11 July 2013 18:02, John McCall <rjmccall at apple.com> wrote: > On Jul 11, 2013, at 5:45 PM, Nick Lewycky <nlewycky at google.com> wrote: > > Hi! A few of us over at Google think a nice feature in clang would be ODR violation checking, and we thought for a while about how to do this and

...f each of the hashes, and we could emit a preprocessor table with the list of initial defines and changes to those defines as the TU went along -- at each hash we could point to an index into that table to indicate where we are. Both of those give us enough information for the linker to say why the ODRs failed to match. There are other situations where the file, line and preprocessor settings were the same. Then I'd expect the md5 of the file was different, and the file was changed between two builds. Anything beyond that is pretty exotic. > This isn't going to be performant enough t...

On Mon, Jul 15, 2013 at 3:12 PM, John McCall <rjmccall at apple.com> wrote: > On Jul 11, 2013, at 6:13 PM, Nick Lewycky <nlewycky at google.com> wrote: > > On 11 July 2013 18:02, John McCall <rjmccall at apple.com> wrote: > >> On Jul 11, 2013, at 5:45 PM, Nick Lewycky <nlewycky at google.com> wrote: >> > Hi! A few of us over at Google think a

On Mon, Jul 15, 2013 at 3:42 PM, John McCall <rjmccall at apple.com> wrote: > On Jul 15, 2013, at 3:20 PM, Richard Smith <richard at metafoo.co.uk> wrote: > > On Mon, Jul 15, 2013 at 3:12 PM, John McCall <rjmccall at apple.com> wrote: > >> On Jul 11, 2013, at 6:13 PM, Nick Lewycky <nlewycky at google.com> wrote: >> >> On 11 July 2013 18:02,