Package libclang_rt.san-{i386,x86_64}.a for Chromium Clang.

Package libclang_rt.san-{i386,x86_64}.a for Chromium Clang.

BUG=174801
R=thakis@chromium.org
NOTRY=true

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=273223

[Alexander Potapenko, 2014-05-28 09:25:40]

Please take a look.
This pulls in libclang_rt.san-{i386,x86_64}.a (4Mb total), but not
libclang_rt.dfsan-x86_64.a (2.4Mb).

[Nico, 2014-05-28 09:27:33]

Hm, that's pretty large. Why does this need so much code? Conceptually, the
ubsan runtime seems like it should be simpler than the asan runtime…

[Alexander Potapenko, 2014-05-28 09:28:35]

On 2014/05/28 09:27:33, Nico (traveling) wrote:
> Hm, that's pretty large. Why does this need so much code? Conceptually, the
> ubsan runtime seems like it should be simpler than the asan runtime…

For comparison, the 64-bit ASan runtime is 16 megs.

[Nico, 2014-05-28 09:29:47]

On Wed, May 28, 2014 at 11:28 AM, <glider@chromium.org> wrote:

> On 2014/05/28 09:27:33, Nico (traveling) wrote:
>
>> Hm, that's pretty large. Why does this need so much code? Conceptually,
>> the
>> ubsan runtime seems like it should be simpler than the asan runtime...
>>
>
> For comparison, the 64-bit ASan runtime is 16 megs.
>

Oh, ok. I guess it's good that this is smaller than ASan then – but it
still seems large (and 16MB seems huge). The runtimes don't do that much,
do they? Why do they need that much code? (16 MB got you a decent, complete
web browser a few years ago.)

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Alexander Potapenko, 2014-05-28 09:45:00]

On 2014/05/28 09:29:47, Nico (traveling) wrote:
> On Wed, May 28, 2014 at 11:28 AM, <mailto:glider@chromium.org> wrote:
> 
> > On 2014/05/28 09:27:33, Nico (traveling) wrote:
> >
> >> Hm, that's pretty large. Why does this need so much code? Conceptually,
> >> the
> >> ubsan runtime seems like it should be simpler than the asan runtime...
> >>
> >
> > For comparison, the 64-bit ASan runtime is 16 megs.
> >
> 
> Oh, ok. I guess it's good that this is smaller than ASan then – but it
> still seems large (and 16MB seems huge). The runtimes don't do that much,
> do they? Why do they need that much code? (16 MB got you a decent, complete
> web browser a few years ago.)
> 
> To unsubscribe from this group and stop receiving emails from it, send an
email
> to mailto:chromium-reviews+unsubscribe@chromium.org.

A quick objdump/grep shows that 800Kb of libclang_rt.san-x86_64 and almost 6Mb
of libclang_rt.asan-x86_64 are debug info.

[Nico, 2014-05-28 09:45:44]

On 2014/05/28 09:45:00, Alexander Potapenko wrote:
> On 2014/05/28 09:29:47, Nico (traveling) wrote:
> > On Wed, May 28, 2014 at 11:28 AM, <mailto:glider@chromium.org> wrote:
> > 
> > > On 2014/05/28 09:27:33, Nico (traveling) wrote:
> > >
> > >> Hm, that's pretty large. Why does this need so much code? Conceptually,
> > >> the
> > >> ubsan runtime seems like it should be simpler than the asan runtime...
> > >>
> > >
> > > For comparison, the 64-bit ASan runtime is 16 megs.
> > >
> > 
> > Oh, ok. I guess it's good that this is smaller than ASan then – but it
> > still seems large (and 16MB seems huge). The runtimes don't do that much,
> > do they? Why do they need that much code? (16 MB got you a decent, complete
> > web browser a few years ago.)
> > 
> > To unsubscribe from this group and stop receiving emails from it, send an
> email
> > to mailto:chromium-reviews+unsubscribe@chromium.org.
> 
> A quick objdump/grep shows that 800Kb of libclang_rt.san-x86_64 and almost 6Mb
> of libclang_rt.asan-x86_64 are debug info.

Is that used for anything? Can we strip it?

[Alexander Potapenko, 2014-05-28 09:52:51]

> Is that used for anything? Can we strip it?

It's sometimes useful for debugging.
The top frames in report stacks can also contain library functions (e.g.
wrap_memcpy), but we hardly ever need the exact line numbers.
Should be ok to strip.

[Alexander Potapenko, 2014-05-28 10:23:30]

On 2014/05/28 09:52:51, Alexander Potapenko wrote:
> > Is that used for anything? Can we strip it?
> 
> It's sometimes useful for debugging.
> The top frames in report stacks can also contain library functions (e.g.
> wrap_memcpy), but we hardly ever need the exact line numbers.
> Should be ok to strip.

Added stripping

[Nico, 2014-05-28 10:57:43]

Thanks. What are the sizes now? The savings from the *San libs are probably more
than the size the additional library adds, right? (If so, lgtm)

[Alexander Potapenko, 2014-05-28 11:53:38]

On 2014/05/28 10:57:43, Nico (traveling) wrote:
> Thanks. What are the sizes now? The savings from the *San libs are probably
more
> than the size the additional library adds, right? (If so, lgtm)

The total size of lib/clang/3.5.0/lib/linux/ is 7Mb now, which makes me think my
math was inaccurate :(

I've also missed 'xargs' before 'strip' (PS4)

Committing now.

[Alexander Potapenko, 2014-05-28 11:53:57]

The CQ bit was checked by glider@chromium.org

[Alexander Potapenko, 2014-05-28 11:54:12]

The CQ bit was unchecked by glider@chromium.org

[Alexander Potapenko, 2014-05-28 11:54:29]

The CQ bit was checked by glider@chromium.org

[commit-bot: I haz the power, 2014-05-28 11:55:53]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/glider@chromium.org/303473011/60001

[commit-bot: I haz the power, 2014-05-28 14:30:27]

Change committed as 273223