All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: "Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Julien Grall" <julien@xen.org>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Anthony PERARD" <anthony.perard@vates.tech>,
	"Michal Orzel" <michal.orzel@amd.com>,
	"Roger Pau Monné" <roger.pau@citrix.com>
Subject: [PATCH v2 5/5] symbols: prefer symbols which have a type
Date: Wed, 2 Apr 2025 16:00:25 +0200	[thread overview]
Message-ID: <b7261eaf-b3ce-4b71-aba2-3f40adbbe93e@suse.com> (raw)
In-Reply-To: <ceef1876-8759-465c-9a74-309b6b92f773@suse.com>

... and thus typically also a size. Using global vs local is undesirable
in certain situations, e.g. when a "real" symbol is local and at the
same address as a section start/end one (which are all global).

Note that for xen.efi the checking for "Function" is only forward-
looking at this point: The function-ness of symbols (much like their
size) is lost when linking PE/COFF binaries from ELF objects with GNU ld
up to at least 2.44.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
I didn't see much reason to also check for "Pointer" and "Array" or any
of the basic types. While nm reports pointers and arrays (but not the
basic types) for PE/COFF, making those up when linker input is ELF would
be impossible without further auxiliary (and non-standard) data in the
ELF symbol table. Transforming STT_FUNC, otoh, is in principle possible.

Implicit from the above: Until GNU ld properly transforms STT_FUNC,
symbol conflicts will be resolved differently for functions. Symbol
conflicts will always be resolved differently for data. xen.efi stack
traces may therefore be less informative than xen-syms ones.
---
v2: New.

--- a/xen/tools/symbols.c
+++ b/xen/tools/symbols.c
@@ -45,6 +45,7 @@ struct sym_entry {
 	unsigned int addr_idx;
 	unsigned int stream_offset;
 	unsigned char type;
+	bool typed;
 };
 #define SYMBOL_NAME(s) ((char *)(s)->sym + 1)
 
@@ -180,6 +181,9 @@ static int read_symbol(FILE *in, struct
 		s->type = stype; /* As s->sym[0] ends mangled. */
 	}
 	s->sym[0] = stype;
+	s->typed = strcmp(type, "FUNC") == 0 ||
+	           strcmp(type, "OBJECT") == 0 ||
+	           strcmp(type, "Function") == 0;
 	rc = 0;
 
  skip_tail:
@@ -613,6 +617,13 @@ static int compare_value(const void *p1,
 		return -1;
 	if (sym1->addr > sym2->addr)
 		return +1;
+
+	/* Prefer symbols which have a type. */
+	if (sym1->typed && !sym2->typed)
+		return -1;
+	if (sym2->typed && !sym1->typed)
+		return +1;
+
 	/* Prefer global symbols. */
 	if (isupper(*sym1->sym))
 		return -1;



  parent reply	other threads:[~2025-04-02 14:00 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-02 13:56 [PATCH v2 0/5] symbols: assorted adjustments Jan Beulich
2025-04-02 13:57 ` [PATCH v2 1/5] symbols: add minimal self-test Jan Beulich
2025-08-27 22:20   ` Jason Andryuk
2025-08-29 14:24   ` Roger Pau Monné
2025-09-01  6:38     ` Jan Beulich
2025-04-02 13:58 ` [PATCH v2 2/5] symbols: split symbols_num_syms Jan Beulich
2025-08-27 22:20   ` Jason Andryuk
2025-04-02 13:58 ` [PATCH v2 3/5] symbols: arrange to know where functions end Jan Beulich
2025-04-02 14:08   ` Jan Beulich
2025-08-28  1:03   ` Jason Andryuk
2025-08-28  7:28     ` Jan Beulich
2025-08-28 16:11       ` Jan Beulich
2025-08-28 17:16         ` Jason Andryuk
2025-08-29  6:59           ` Jan Beulich
2025-08-31 14:50             ` Jason Andryuk
2025-04-02 13:59 ` [PATCH v2 4/5] symbols: centralize and re-arrange $(all_symbols) calculation Jan Beulich
2025-08-28  1:05   ` Jason Andryuk
2025-08-29 15:02     ` Roger Pau Monné
2025-04-02 14:00 ` Jan Beulich [this message]
2025-08-28  1:07   ` [PATCH v2 5/5] symbols: prefer symbols which have a type Jason Andryuk
2025-08-29 15:13     ` Roger Pau Monné

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=b7261eaf-b3ce-4b71-aba2-3f40adbbe93e@suse.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=anthony.perard@vates.tech \
    --cc=julien@xen.org \
    --cc=michal.orzel@amd.com \
    --cc=roger.pau@citrix.com \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.