From: jamie.iles@oracle.com (Jamie Iles)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm64/debug: don't duplicate filenames.
Date: Thu, 9 Nov 2017 14:41:36 +0000 [thread overview]
Message-ID: <20171109144136.n4iser235446sv3x@cedar> (raw)
In-Reply-To: <20171109143121.GC22781@e103592.cambridge.arm.com>
On Thu, Nov 09, 2017 at 02:31:22PM +0000, Dave Martin wrote:
> On Thu, Nov 09, 2017 at 01:08:51PM +0000, Jamie Iles wrote:
> > Hi Dave,
> >
> > On Thu, Nov 09, 2017 at 12:35:04PM +0000, Dave Martin wrote:
> > > On Thu, Nov 09, 2017 at 12:14:40PM +0000, Jamie Iles wrote:
> > > > Rather than explicitly pushing the filename into .rodata.str, use a
> > > > compiler generated string literal and use the address of that as an
> > > > input constraint to the inline assembly. This allows the compiler to
> > > > emit only one version of the string without relying on the linker to
> > > > deduplicate.
> > >
> > > But if the linker does deduplicate, why does it matter?
> >
> > It's not broken, but at the moment we have multiple copies in the object
> > file then we're relying on the linker. If we use the same pattern as
> > X86, we can let GCC assign sections+attributes for us and only get one
> > copy in the object file.
> >
> > > Or is the linker not removing duplicates that some from the same source
> > > file?
> >
> > In my testing, yes, the linker is merging them.
>
> So, playing devil's advocate here, what is this fixing?
It's caused some confusion looking at object files, it's certainly not a
critical bug!
> It doesn't really matter where in the toolchain the duplicates get
> removed, just that it happens somewhere...
>
> It looks like ld -r doesn't do the deduplication, so there may be a fair
> amount of duplicates before the final linux of vmlinux -- which I guess
> could be an issue if BUG() is used in macros that get expanded all over
> the place.
Ah, interesting. Testing with a loadable module, this means that there
are duplicates in modules. With mainline:
strings ./fs/ext4/ext4.ko | grep -c "inode\.c"
61
and with my patch:
strings ./fs/ext4/ext4.ko | grep -c "inode\.c"
4
Thanks,
Jamie
next prev parent reply other threads:[~2017-11-09 14:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-09 12:14 [PATCH] arm64/debug: don't duplicate filenames Jamie Iles
2017-11-09 12:35 ` Dave Martin
2017-11-09 13:08 ` Jamie Iles
2017-11-09 14:31 ` Dave Martin
2017-11-09 14:41 ` Jamie Iles [this message]
2017-11-09 14:48 ` Dave Martin
2017-11-09 15:01 ` Dave Martin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171109144136.n4iser235446sv3x@cedar \
--to=jamie.iles@oracle.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).