From: James Bottomley <James.Bottomley@steeleye.com>
To: PARISC list <parisc-linux@lists.parisc-linux.org>
Subject: [parisc-linux] Fix for local symbols appearing in CONFIG_KALLSYMS traces
Date: 27 Jun 2003 22:37:48 -0500 [thread overview]
Message-ID: <1056771469.1825.210.camel@mulgrave> (raw)
[-- Attachment #1: Type: text/plain, Size: 662 bytes --]
One of the problems with KALLSYMS on parisc is that our toolchain
generates lots of local symbols with names like .LNNN and .LCNNN which
are multiply defined and thus spoil symbolic backtraces.
I suspect the true fix is probably to force the parisc binutils to give
them empty names when it emits elf object, but until binutils does this,
the attached patch eliminates them from the kernel object and from
loaded objects.
The patch is fairly awful, particularly the messing with the contents of
a pointer to a constant area in module_finalize, but it does eliminate
the problem.
Would this be OK to people until binutils sorts out the problem for us?
James
[-- Attachment #2: tmp1.diff --]
[-- Type: text/plain, Size: 3244 bytes --]
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet 1.1466 -> 1.1467
# arch/parisc/Makefile 1.20 -> 1.21
# arch/parisc/kernel/module.c 1.5 -> 1.6
# (new) -> 1.1 arch/parisc/nm
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 03/06/27 jejb@raven.il.steeleye.com 1.1467
# Fix parisc local symbol problem with CONFIG_KALLSYMS
# --------------------------------------------
#
diff -Nru a/arch/parisc/Makefile b/arch/parisc/Makefile
--- a/arch/parisc/Makefile Fri Jun 27 22:29:20 2003
+++ b/arch/parisc/Makefile Fri Jun 27 22:29:20 2003
@@ -16,7 +16,7 @@
# Modified for PA-RISC Linux by Paul Lahaie, Alex deVries,
# Mike Shaver, Helge Deller and Martin K. Petersen
#
-
+NM = sh arch/parisc/nm
ifdef CONFIG_PARISC64
CROSS_COMPILE := hppa64-linux-
UTS_MACHINE := parisc64
diff -Nru a/arch/parisc/kernel/module.c b/arch/parisc/kernel/module.c
--- a/arch/parisc/kernel/module.c Fri Jun 27 22:29:20 2003
+++ b/arch/parisc/kernel/module.c Fri Jun 27 22:29:20 2003
@@ -671,6 +671,11 @@
const Elf_Shdr *sechdrs,
struct module *me)
{
+ int i;
+ unsigned long nsyms;
+ const char *strtab = NULL;
+ Elf_Sym *newptr, *oldptr;
+ Elf_Shdr *symhdr = NULL;
#ifdef DEBUG
struct fdesc_entry *entry;
u32 *addr;
@@ -690,7 +695,49 @@
me->arch.got_count, me->arch.got_max,
me->arch.fdesc_count, me->arch.fdesc_max);
#endif
-
+
+ /* haven't filled in me->symtab yet, so have to find it
+ * ourselves */
+ for (i = 1; i < hdr->e_shnum; i++) {
+ if(sechdrs[i].sh_type == SHT_SYMTAB
+ && (sechdrs[i].sh_type & SHF_ALLOC)) {
+ int strindex = sechdrs[i].sh_link;
+ /* FIXME: AWFUL HACK
+ * The cast is to drop the const from
+ * the sechdrs pointer */
+ symhdr = (Elf_Shdr *)&sechdrs[i];
+ strtab = (char *)sechdrs[strindex].sh_addr;
+ break;
+ }
+ }
+
+ printk("module %s: strtab %p, symhdr %p\n",
+ me->name, strtab, symhdr);
+
+ /* no symbol table */
+ if(symhdr == NULL)
+ return 0;
+
+ oldptr = (void *)symhdr->sh_addr;
+ newptr = oldptr + 1; /* we start counting at 1 */
+ nsyms = symhdr->sh_size / sizeof(Elf_Sym);
+ printk("OLD num_symtab %lu\n", nsyms);
+
+ for (i = 1; i < nsyms; i++) {
+ oldptr++; /* note, count starts at 1 so preincrement */
+ if(strncmp(strtab + oldptr->st_name,
+ ".L", 2) == 0)
+ continue;
+
+ if(newptr != oldptr)
+ *newptr++ = *oldptr;
+ else
+ newptr++;
+
+ }
+ nsyms = newptr - (Elf_Sym *)symhdr->sh_addr;
+ printk("NEW num_symtab %lu\n", nsyms);
+ symhdr->sh_size = nsyms * sizeof(Elf_Sym);
return 0;
}
diff -Nru a/arch/parisc/nm b/arch/parisc/nm
--- /dev/null Wed Dec 31 16:00:00 1969
+++ b/arch/parisc/nm Fri Jun 27 22:29:20 2003
@@ -0,0 +1,6 @@
+#!/bin/sh
+##
+# Hack to have an nm which removes the local symbols. We also rely
+# on this nm being hidden out of the ordinarily executable path
+##
+${CROSS_COMPILE}nm $* | grep -v '.LC*[0-9]*$'
reply other threads:[~2003-06-28 3:37 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=1056771469.1825.210.camel@mulgrave \
--to=james.bottomley@steeleye.com \
--cc=parisc-linux@lists.parisc-linux.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