All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Smith <dsmith@redhat.com>
To: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Roland McGrath <roland@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, systemtap@sources.redhat.com
Subject: Re: [PATCH] markers: modpost
Date: Thu, 08 Nov 2007 13:45:00 -0600	[thread overview]
Message-ID: <4733673C.6010904@redhat.com> (raw)
In-Reply-To: <20071108193617.GA31172@Krystal>

Mathieu Desnoyers wrote:
> * David Smith (dsmith@redhat.com) wrote:
>> Mathieu Desnoyers wrote:
>>> * Roland McGrath (roland@redhat.com) wrote:
>>>>> If we want to do it safely, I think we should iterate from
>>>>> __start___markers to __stop___markers symbols of vmlinux and get the
>>>>> pointers to the name/format string pairs.
>>>>>
>>>>> The same can then be done with modules using the __markers section.
>>>>>
>>>>> Or maybe is there some reason not to do that ?
>>>> It's just rather a pain in the ass, a whole lot more fiddly work.
>>>> cf "somewhat crude" and "foreseeable future" in my patch's log entry.
>>>> Knock yourself out if you're looking for more tedious hacking to do in
>>>> modpost.c, but I say fix it when it breaks.
>>>>
>>> Hmmmm, I have rarely seen code go into mainline without addressing valid
>>> technical criticism first. Please fix.
>>>
>>> I'll look into it if I find the time.
>>>
>>> Mathieu
>> Mathieu,
>>
>> Here's an updated patch, written by Roland (that I tested for him), that
>> looks for all marker symbols in the __markers_strings section.  It doesn't
>> get the pointers from the __markers section because that is very difficult
>> to do in modpost (having to handle the architecture-dependent relocations
>> applied to those pointers).
>>
> 
> Hrm, what would happen if a gcc optimization eventually decides to mix
> the memory layout of the strings ? Is there something that specifies
> that they won't ?

I don't believe there is anything in gcc that specifies that the strings
won't get mixed around.  But, I believe this code is good for the
foreseeable future.  We could fix this code if the future breakage does
happen.

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)

  reply	other threads:[~2007-11-08 19:45 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-18 21:13 [patch 0/4] Linux Kernel Markers for 2.6.23-rc6-mm1 Mathieu Desnoyers
2007-09-18 21:13 ` [patch 1/4] Linux Kernel Markers - Architecture Independent Code Mathieu Desnoyers
2007-09-19 11:37   ` Mathieu Desnoyers
2007-09-19 13:53     ` Frank Ch. Eigler
2007-09-19 20:32       ` Denys Vlasenko
2007-09-21 12:58         ` Mathieu Desnoyers
2007-09-21 13:07           ` Christoph Hellwig
2007-09-21 13:30           ` Frank Ch. Eigler
2007-09-21 13:38             ` Mathieu Desnoyers
2007-10-15 19:41               ` Frank Ch. Eigler
2007-10-15 23:12                 ` Mathieu Desnoyers
2007-10-15 23:50                   ` Roland McGrath
2007-10-25 19:17                     ` Mathieu Desnoyers
2007-10-26 14:28                       ` Frank Ch. Eigler
2007-11-01  1:06                         ` [PATCH] markers: modpost Roland McGrath
2007-11-01  2:46                           ` Mathieu Desnoyers
2007-11-01  9:37                             ` Roland McGrath
2007-11-01 11:24                               ` Mathieu Desnoyers
2007-11-08 19:31                                 ` David Smith
2007-11-08 19:36                                   ` Mathieu Desnoyers
2007-11-08 19:45                                     ` David Smith [this message]
2007-11-09 16:36                                     ` David Smith
2007-11-11 23:24                                       ` Mathieu Desnoyers
2007-09-19 17:32     ` [patch 1/4] Linux Kernel Markers - Architecture Independent Code Denys Vlasenko
2007-09-19 18:46       ` Mathieu Desnoyers
2007-09-19 18:50         ` Mathieu Desnoyers
2007-09-21  0:58   ` Steven Rostedt
2007-09-21 13:45     ` Mathieu Desnoyers
2007-09-18 21:13 ` [patch 2/4] Linux Kernel Markers - Use instrumentation kconfig menu Mathieu Desnoyers
2007-09-18 21:13 ` [patch 3/4] Linux Kernel Markers - Documentation Mathieu Desnoyers
2007-09-18 23:22   ` Randy Dunlap
2007-09-19 11:18     ` Mathieu Desnoyers
2007-09-18 21:13 ` [patch 4/4] Port of blktrace to the Linux Kernel Markers Mathieu Desnoyers
2007-09-21  1:03   ` Steven Rostedt
2007-09-21 13:46     ` Mathieu Desnoyers

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=4733673C.6010904@redhat.com \
    --to=dsmith@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@polymtl.ca \
    --cc=roland@redhat.com \
    --cc=systemtap@sources.redhat.com \
    /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.