linux-kernel - Re: [PATCH v2 06/10] selftests/nolibc: make functions static if possible

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4ad4b853-b89f-4c5a-a50b-28739d7b81c0@t-8ch.de>
Date:   Tue, 1 Aug 2023 10:50:05 +0200
From:   Thomas Weißschuh <linux@...ssschuh.net>
To:     Willy Tarreau <w@....eu>
Cc:     Shuah Khan <shuah@...nel.org>, linux-kselftest@...r.kernel.org,
        linux-kernel@...r.kernel.org, Yuan Tan <tanyuan@...ylab.org>,
        Zhangjin Wu <falcon@...ylab.org>
Subject: Re: [PATCH v2 06/10] selftests/nolibc: make functions static if
 possible

On 2023-08-01 10:13:07+0200, Willy Tarreau wrote:
> On Tue, Aug 01, 2023 at 09:34:18AM +0200, Thomas Weißschuh wrote:
> > On 2023-08-01 08:52:19+0200, Willy Tarreau wrote:
> > > On Tue, Aug 01, 2023 at 07:30:13AM +0200, Thomas Weißschuh wrote:
> > > > diff --git a/tools/testing/selftests/nolibc/nolibc-test.c b/tools/testing/selftests/nolibc/nolibc-test.c
> > > > index 1555759bb164..53a3773c7790 100644
> > > > --- a/tools/testing/selftests/nolibc/nolibc-test.c
> > > > +++ b/tools/testing/selftests/nolibc/nolibc-test.c
> > 
> > > [..]
> > 
> > > >  /* prepare what needs to be prepared for pid 1 (stdio, /dev, /proc, etc) */
> > > > -int prepare(void)
> > > > +static int prepare(void)
> > > >  {
> > > >  	struct stat stat_buf;
> > > >  
> > > > @@ -1208,7 +1208,7 @@ static const struct test test_names[] = {
> > > >  	{ 0 }
> > > >  };
> > >  
> > > For these ones it will prevent gcc from putting breakpoints there, which
> > > is counter-productive.
> > 
> > Indeed.
> > 
> > An alternative would be to add -g to CFLAGS (and remove -s from LDFLAGS).
> > This way we get full debugability including breakpoints for everything.
> 
> It wouldn't change much because while it would allow the debugger to know
> where the function was possibly inlined, it's still not very convenient:
> you believe you're in a function but in fact you're in the caller. It
> really depends what you're debugging but here I don't see all that as
> providing a value, at least it brings more annoyance and little to no
> gain IMHO.

Even if it doesn't work 100% properly it wouldn't it still be a superset
of the previous functionality?
And we don't have to manually keep track of which ones should be static
and which shouldn't (See this discussion).

Would it be better with -ggdb?

If you are still not conviced I'll drop the argument here :-)
(And the changes in the next revision)

> > I didn't find the reasoning for -s in LDFLAGS.
> 
> It's historic, because normally when you want small binaries you strip
> them, and the command line was reused as-is, but I agree that we could
> get rid of it!

I'll remove it. It was annoying to figure out why my "-g" CFLAG didn't
work at all.

Thomas