All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paulo Marques <pmarques@grupopie.com>
To: Russell King <rmk+lkml@arm.linux.org.uk>
Cc: Rusty Russell <rusty@rustcorp.com.au>,
	Richard Earnshaw <Richard.Earnshaw@arm.com>,
	lkml - Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	Sam Ravnborg <sam@ravnborg.org>
Subject: Re: [RFC] ARM binutils feature churn causing kernel problems
Date: Thu, 07 Oct 2004 17:39:52 +0100	[thread overview]
Message-ID: <41657158.6000909@grupopie.com> (raw)
In-Reply-To: <20041007160108.B8579@flint.arm.linux.org.uk>

Russell King wrote:
> On Thu, Oct 07, 2004 at 01:35:32PM +0100, Paulo Marques wrote:
> 
>>The patch by Russel King seems ok to me, although I prefer Rusty's idea 
>>of not using any symbol that is not in the form "[A-Za-z0-9_]+". We just 
>>need to check if there are any real world users of these "weird" symbols.
> 
> 
> This may filter out too much - we have symbols starting with a '.' on
> ARM, particularly used in some of the assembly code, which are useful
> to be decoded back to names, such as ".bug".
> 
> However, including "." means that names like "__func__.0" also get
> included, which is probably a bad thing.  So, maybe it needs to be
> 
> [A-Za-z0-9_\.][A-Za-z0-9_]*

I just checked a "nm -n vmlinux" output on a x86 2.6.9-rc3-mm2 defconfig 
kernel and it has stuff like:

...
c01aed13 t .text.lock.transaction
c01b1db3 t .text.lock.checkpoint
...
c03c7708 r single_rates.0
c03c7714 r double_rate_channels.1
...
c0482280 d get_s16_labels.0
c04822c0 d put_s16_labels.1
c0482300 d get_s16_labels.2
c0482340 d put_s16_labels.3
...
c053d780 b nulldevname.1
c053d800 b bootstrap.2
...

Most of these seem like useful information (although I personally don't 
have any use for them).

The 'b' and 'r' types only get in if CONFIG_KALLSYMS_ALL is specified.

There were 572 "__func__.*" symbols all with type 'r'. If we take into 
account that there were a total of 32881 symbols, these 572 are not that 
many. Even more, with the new compression scheme they would probably 
take only about 3 bytes per symbol to store the name and 4 bytes for the 
address (8 on 64 bit architectures) that would require about 4kb of data 
  for users that choose the CONFIG_KALLSYMS_ALL option. Removing the 
"__func__" symbols would represent less than a 2% decrease in size.

So maybe we could use "[A-Za-z0-9_\.]+" ?

-- 
Paulo Marques - www.grupopie.com

To err is human, but to really foul things up requires a computer.
Farmers' Almanac, 1978

  reply	other threads:[~2004-10-07 17:06 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-27 20:03 [RFC] ARM binutils feature churn causing kernel problems Russell King
2004-09-27 20:17 ` Christoph Hellwig
2004-09-27 20:35   ` Russell King
2004-09-27 20:37   ` Nicolas Pitre
2004-10-01 20:11 ` Russell King
2004-10-04 12:01   ` Catalin Marinas
2004-10-04 23:18     ` Rusty Russell
2004-10-05 11:10       ` Richard Earnshaw
2004-10-05 11:53         ` Russell King
2004-10-05 12:57           ` Richard Earnshaw
2004-10-05 13:14             ` Russell King
2004-10-05 13:40               ` Richard Earnshaw
2004-10-05 13:51                 ` Russell King
2004-10-06 10:08                   ` Adrian Cox
2004-10-07 15:02                     ` Russell King
2004-10-12 13:15                     ` Richard Earnshaw
2004-10-07 14:54                   ` Russell King
2004-10-05 23:00               ` Rusty Russell
2004-10-07 12:35                 ` Paulo Marques
2004-10-07 15:01                   ` Russell King
2004-10-07 16:39                     ` Paulo Marques [this message]
2004-10-05 13:02           ` Richard Earnshaw
2004-10-08 15:04 ` Russell King
2004-10-08 16:36   ` Paulo Marques
2004-10-08 18:14     ` Albert Cahalan
2004-10-08 19:43       ` Paulo Marques
2004-10-20 11:38 ` [PATCH] Fix ARM kernel build with permitted binutils versions Russell King
2004-10-26 22:37   ` Sam Ravnborg

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=41657158.6000909@grupopie.com \
    --to=pmarques@grupopie.com \
    --cc=Catalin.Marinas@arm.com \
    --cc=Richard.Earnshaw@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rmk+lkml@arm.linux.org.uk \
    --cc=rusty@rustcorp.com.au \
    --cc=sam@ravnborg.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.