On Thu, 18 Dec 2008 15:03:25 +0300, "Cyrill Gorcunov" <gorcunov@xxxxxxxxx> said: > On Thu, Dec 18, 2008 at 12:51 PM, Alexander van Heukelum > <heukelum@xxxxxxxxxxx> wrote: > [...] > >> > > >> > 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 :) > > > > >> > - 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. I understood, but I wanted to avoid the meme that this procedure is just ebout renaming ENTRY->PROC and END->ENDPROC ;). > Fix me if I'm wrong. > > > > >> 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. I would suggest using sizeof(long) alignment for data. Greetings, Alexander -- Alexander van Heukelum heukelum@xxxxxxxxxxx -- http://www.fastmail.fm - mmm... Fastmail... -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
