search for: 5.05s

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 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

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 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

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 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

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