Date: Sun, 20 Jun 2021 14:08:25 -0700 From: Steve Kargl <sgk@troutmask.apl.washington.edu> To: Ed Maste <emaste@freebsd.org> Cc: John Baldwin <jhb@freebsd.org>, Poul-Henning Kamp <phk@phk.freebsd.dk>, "freebsd-arch@freebsd.org" <arch@freebsd.org> Subject: Re: It's time to kill statistical profiling Message-ID: <20210620210825.GA45154@troutmask.apl.washington.edu> In-Reply-To: <CAPyFy2BV0R_uXir1dYf8nN2JEOCZCprKYbHa6E1biFFJMbmAQQ@mail.gmail.com> References: <202106180736.15I7aYmk068064@critter.freebsd.dk> <d63d21fe-c1ef-dbb9-64e2-3e23621820bc@FreeBSD.org> <CAPyFy2BV0R_uXir1dYf8nN2JEOCZCprKYbHa6E1biFFJMbmAQQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jun 20, 2021 at 03:18:31PM -0400, Ed Maste wrote: > On Fri, 18 Jun 2021 at 11:13, John Baldwin <jhb@freebsd.org> wrote: > > > > As Konstantin has noted, we already no longer build or ship > > -pg libraries by default. > > Kostik was talking about only kernel -pg support I believe; we still > build _p.a libraries by default. I floated the idea of disabling them > by default but there was some opposition and I didn't proceed. > > It seems like it is in fact past time to disable them by default, and > I've now put the change in review at > https://reviews.freebsd.org/D30833. Are there plans to replace the _p.a with something that allows profiling code? If not, are you upstreaming patches to GCC to disable -pg? AFAIK, 'gcc10 -pg ... -lm' causes gcc to look for at least libc_p.a and libm_p.a. -- Steve
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20210620210825.GA45154>