search for: odr

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

.... 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. >> > > If you IR Link two modules, you'd want to check that the hash matches and > diagnose immediately before dropping link once_odr functions, right? > The ODR table (including its string table) is created by the compiler and is unaffected by dropped functions. Functions can be dropped by the optimizer in the non-LTO case as well, of course, and we'd still want to be able to diagnose ODR mismatches in those functions....

...39;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 sec...

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

...M, 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 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 >>> >> >&...

...rote: >>> >>>> 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 &gt...

...;> 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 later >>> warned about due to older versions being deprecated, the user linking that >>> object would probably get quite annoyed, especially as in such cases, the >>> original producer may no longer be able/willing to update the >>> object/...

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

...ristol.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 later > warned about due to older versions being deprecated, the user linking that > object would probably get quite annoyed, especially as in such cases, the > original producer may no longer be able/willing to update the > object/archive. > I think this issu...

...ed, 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 st...

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

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

...; 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 >>>>>>>>&...

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

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 else the design work if they're interested in it. >...

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

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

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

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

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