On Thu, Dec 18, 2008 at 12:51 PM, Alexander van Heukelum
<heukelum@fastmail.fm> wrote:
[...]
quoted text
>> >
>> > Sam, I think eventually we should get something like this:
>> >
>> > - KPROBE will be eliminated and explicit section descriptions
>> >   are to be used
>> > - ENTRY could be used / or renamed for something more descriptive
>> >   and being used aligned jmp targets or in case of procs with
>> >   shared body
>
> I don't think ENTRY should be used for nested procedures. If the
> author wants to do something like that, he better knew something
> about the assembler anyhow.

Author anyway have to knew something. We can't bring some kind
of lexical machine that eliminate this needing :)

quoted text
>
>> > - PROC/ENDPROC are to replace old ENTRY/END for procs being called
>> >   mostly from C code
>
> Currently there is many different patterns. Some functions use ENTRY
> without END, some use ENTRY/ENDPROC, some use ENDPROC without annotation
> at the start...

Alexander, I was just trying to say Sam about what we're planning to get
at the end of all this procedure. I mean I know there are some issues to
be fixed first.

Fix me if I'm wrong.

quoted text
>
>> So what prevents us from extending ENTRY/END instead of introducing
>> another set?
>
> ENTRY/END alone is not enough if one wants to be able to distinguish
> between code (functions) and non-executed data.
>
>> Let us try to extend what we have and not introduce something new.
>
> Agreed. I vote to complement the existing ENDPROC annotation with
> the proposed PROC annotation. Let's call that an extension, not
> something new ;). As it stands it is not impossible to go with
> ENTRY/ENDPROC for code and ENTRY/END for data. However, ENTRY
> implies alignment and the prefered alignment for code and data
> might differ.

If ENTRY will be used for data objects it shouldn't contain any kind of
alignment since in general we could have arrays of bytes, words and so on.

quoted text
>
> Greetings,
>    Alexander
>
>>       Sam
> --
>  Alexander van Heukelum
>  heukelum@fastmail.fm
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/