u-boot.lists.denx.de archive mirror
 help / color / mirror / Atom feed
From: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
To: u-boot@lists.denx.de
Subject: fdtdec: what is the purpose of the compat_names array
Date: Tue, 17 Mar 2020 01:10:22 +0100	[thread overview]
Message-ID: <50288d08-3ab8-ef3c-5118-f74e30297104@prevas.dk> (raw)

I was running strings(1) on my SPL to see if there was something obvious
I could find and compile away. To my surprise, I found strings such as

altr,socfpga-dw-mshc
altr,socfpga-fpga2hps-bridge
altr,socfpga-fpga2sdram0-bridge
altr,socfpga-fpga2sdram1-bridge

which are of course quickly tracked to the compat_names array in
lib/fdtdec.c. I don't understand why that exists? It doesn't seem to
scale very well that every random driver would put some compatible
strings in there and use an indirection via an enum. Obviously, not
every driver does that, so I must be missing something.

Take the fpga2sdram* for example. They are only used by
arch/arm/mach-socfpga/reset_manager_arria10.c, and it seems that the
"int compat_id" might as well be a "const char *compat" directly, with
the fdtdec_next_compatible() call changed to
fdt_node_offset_by_compatible().

Now, in my case [and probably also for everyone else that don't use one
of those few drivers that use a "enum fdt_compat_id"] all the functions
that actually refer to the compat_names[] array get garbage collected
away by the linker. Unfortunately, due the .fixup section on powerpc,
the same cannot be said of the compat_names[] array or the pointed-to
string literals - otherwise I wouldn't have stumbled on this. A small
translation unit that shows the problem/phenomenon is this:

=== foo.c ===
#include <common.h>
static const char *const foo_strings[] = {
	"this won't be garbage collected",
	"neither will this be garbage collected",
};

int foo_func(int x)
{
	printf("the function foo_func will be gc'ed\n");
	printf("so will these format strings\n");
	printf("%s\n", foo_strings[x]);
	return 0;
}
=== foo.c ===

Adding foo.o to the link (u-boot or SPL, doesn't matter), inspecting the
.map file and/or running strings(1) or nm(1) on the binary shows that
despite all public symbols provided by foo.o being gc'ed, the final
binary is still bloated by the foo_strings array and the literals.

Does it make sense to try to convert the enum fdt_compat_id users to use
the compatible strings directly with the fdt_* functions?

Rasmus

             reply	other threads:[~2020-03-17  0:10 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-17  0:10 Rasmus Villemoes [this message]
2020-03-17 16:11 ` fdtdec: what is the purpose of the compat_names array Simon Glass

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=50288d08-3ab8-ef3c-5118-f74e30297104@prevas.dk \
    --to=rasmus.villemoes@prevas.dk \
    --cc=u-boot@lists.denx.de \
    /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).