<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>
simply:<BR>
probably: calls to finally blocks must not go through PLT<BR>
definitely: calls to finally blocks must successfully pass the static link (assuming any locals/parameters are used, and don't bother otherwise); perhaps they just be inlined and not even calls; of course it's a bit more than that, I'd have to try except and actually raising exceptions, but as a start, successful runs of finally blocks need to work, they don't currently on AMD64 due to the call through PLT trashing r10<BR>
optionally: calls through PLT should be in general decreased as they are just very wasteful; it's disheartening to realize how it currently is<BR>
inlines that are declared in an .i3 should be callable from other .m3 files in the same "library" and even exportable and callable outside the .dll/.so<BR><BR> - Jay<BR><BR>
<BR>
<HR>
<BR>
From: jayk123@hotmail.com<BR>To: hosking@cs.purdue.edu; jkrell@elegosoft.com<BR>Date: Tue, 29 Apr 2008 21:57:45 +0000<BR>CC: m3devel@elegosoft.com<BR>Subject: Re: [M3devel] Your recent change to parse.c<BR><BR>
<META content="Microsoft SafeHTML" name=Generator>
<STYLE>
.ExternalClass .EC_hmmessage P
{padding:0px;}
.ExternalClass body.EC_hmmessage
{font-size:10pt;font-family:Tahoma;}
</STYLE>
Tony, this is a serious problem on AMD64_LINUX.<BR>It is not a problem at all on Win32, as Win32 has a<BR>much better codegen model. It's amazing how Linux works..<BR><BR>Look at the .ms file for ThreadPThread.<BR>I looked on AMD64_LINUX and LINUXLIBC6.<BR><BR>ThreadPThread__InitMutex's call to its own finally<BR>block goes through the PLT and on AMD64_LINUX the static link<BR>in r10 is trashed.<BR><BR>It's possible that if you turn on optimizations, the finally<BR>block is inlined and that hides the problem, but you can't<BR>count on that.<BR><BR>I was experimenting with another fix at the same time,<BR>that of using -fvisibility=hidden on m3cg, but<BR>to me that seems more like a C/C++ front end switch,<BR>even though cm3cg supports it.<BR><BR>I can try again and carefully tweak the two variables,<BR>see if -fvisibility=hidden suffices. At the level<BR>cm3cg operates though, it marks the visibility of everything<BR>explicitly, so again, I think my fix is the way.<BR><BR>As well calls within a file to functions within that file<BR>that aren't in an interface are going through the PLT.<BR>This is just wasteful.<BR><BR>They shouldn't even go through the PLT for calls within the<BR>same "library" (ie: m3core to m3core, libm3 to libm3).<BR><BR>What such indirect calls "buy" is that, e.g. the .exe or libm3<BR>can replace functions in m3core, or such, and function pointer<BR>equality might be achieved. I think the "interposition" feature<BR>is widely accepted on Linux, though it is dodgy.<BR>I think on Linux going through the PLT for exported functions might<BR>be the norm. I'll have to read up more. But going through the PLT<BR>for unexported functions is not the norm. Documentation strongly<BR>encourages marking visibility and saving the PLT indirection.<BR><BR>In C/C++ there's further problems of name uniquess of unexported<BR>functions across the dynamic link. I believe Modula-3 deals with that,<BR>since pretty much every function in the system gets a unique name,<BR>exported or not.<BR> <BR>One or the other or both these changes (public = exported,<BR>or -fvisibilit=hidden) optimizes those calls.<BR><BR>In general going through the PLT is very wasteful when<BR>it isn't necessary. There's a bunch of "literature" about<BR>this on the web.<BR><BR>On Windows, to call a function Foo, you just call Foo.<BR>If Foo ends up imported, the linker generates a single instruction<BR>function for you, Foo, that jumps through __imp__Foo.<BR>If you are absolutely sure Foo will be imported and want to<BR>optimize a little, you can mark Foo as __declspec(dllimport),<BR>however for functions this is totally optional.<BR>To export functions, you either mark them __declspec(dllexport)<BR>or list them in a .def file. For C++, .def files are a pain, but<BR>for C they work just fine, or better.<BR>For importing data, you pretty much have to mark it as __declspec(dllimport).<BR>Importing data is rare.<BR>gcc/ld on Windows have some hack to make this easier that I'm not familiar with.<BR><BR>So in the absence of importing data, there is just one codegen<BR>model that is acceptable -- call Foo.<BR>Most function calls, theoretically, are not imported, and this<BR>ends up as a normal direct call.<BR>There may be issues of position-independence, but on AMD64 this<BR>is not relevant. On AMD64_NT, I believe the vast majority of<BR>code is naturally position-indendent via RIP-relative addressing.<BR>It is true that things like vtables might have relocs.<BR>I think that is unfortunate. It would be nice to have 100%<BR>position independence for .dlls and .exes.<BR> <BR>On Linux, if you are compiling for a .dll, you must be position-independent,<BR>I think fully, and all function calls by default go through the PLT.<BR>Maybe to statics don't. But just sharing across two source files does.<BR>Every call is therefore indirect, subject to loader machinations at<BR>either load or first-call time, and "interposable" -- someone else<BR>can export a function of the same name and take over the function.<BR>As well, someone else can call these internal functions more easily<BR>than otherwise. Granted, anyone can call any of your code at any time, just<BR>by jumping to it. But symbolic exports are considered more attackable<BR>surface area than random code sitting in memory.<BR><BR>If you don't use -fPIC, I think all calls are direct.<BR>And you can't link into a .dll.<BR><BR>And then, really, the truth is in between.<BR>Individual calls can be marked one way or the other.<BR><BR>But Modula-3 is marking everything as public, exported, subject<BR>to dynamic linking, called through the PLT.<BR><BR>As to why only AMD64_LINUX is seeing this, I don't know.<BR>I'd have to check how the static link is passed on others and<BR>if the loader preserves it. Could be it is an extra parameter<BR>on the stack, since x86 has so few registers.<BR><BR>Could be AMD64_LINUX could/should pass it another way, but<BR>really, avoiding the PLT for unexported functions seems like<BR>pure goodness.<BR><BR>I was quite surprised and dismayed to learn about all this last<BR>night when I was debugging.<BR><BR>Why must inline function bodies for unexported functions be preserved<BR>anyway? They are just dead code, right? <BR>Is there another way to preserve them?<BR>If it is <*inline*> on the implementation but listed in the *.i3 file, that should be public/exported. Is it not? I was able to build LINUXLIBC6 this way as far as building on AMD64 gets, which is pretty far -- eventually failing for lack of some X .libs.<BR>Oh, I guess I should be sure optimization is on? I didn't twiddle that. I can try again.<BR> <BR> - Jay<BR><BR><BR>
<BLOCKQUOTE>
<BLOCKQUOTE>
<HR>
From: hosking@cs.purdue.edu<BR>To: jkrell@elegosoft.com<BR>Date: Tue, 29 Apr 2008 11:52:24 -0400<BR>CC: m3devel@elegosoft.com<BR>Subject: [M3devel] Your recent change to parse.c<BR><BR>
<DIV>I don't understand your change to parse.c re TREE_PUBLIC being set on procedure declarations. TREE_PUBLIC just means that it is possible to call the procedure from outside the current compilation unit. It has nothing to do with intra-library visibility.</DIV>
<DIV><BR></DIV><BR>
<DIV><SPAN class=EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV style="WORD-WRAP: break-word"><SPAN class=EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV><FONT class=EC_EC_Apple-style-span color=#0000ff><FONT class=EC_EC_Apple-style-span face="Gill Sans"><SPAN class=EC_EC_Apple-style-span style="COLOR: rgb(0,0,255); FONT-FAMILY: Gill Sans"><SPAN class=EC_EC_Apple-style-span style="COLOR: rgb(0,0,255); FONT-FAMILY: Gill Sans">Antony Hosking</SPAN></SPAN></FONT></FONT><FONT class=EC_EC_Apple-style-span face="Gill Sans"><SPAN class=EC_EC_Apple-style-span style="FONT-FAMILY: Gill Sans"><SPAN class=EC_EC_Apple-style-span style="FONT-FAMILY: Gill Sans"> | </SPAN></SPAN><SPAN class=EC_EC_Apple-style-span style="FONT-FAMILY: Gill Sans"><SPAN class=EC_EC_Apple-style-span style="FONT-FAMILY: Gill Sans">Associate Professor</SPAN></SPAN><SPAN class=EC_EC_Apple-style-span style="FONT-FAMILY: Gill Sans"><SPAN class=EC_EC_Apple-style-span style="FONT-FAMILY: Gill Sans"> | Computer Science | Purdue University</SPAN></SPAN></FONT></DIV>
<DIV><FONT class=EC_EC_Apple-style-span face=GillSans-Light><SPAN class=EC_EC_Apple-style-span style="FONT-FAMILY: GillSans-Light">305 N. University Street | West Lafayette | IN 47907 | USA</SPAN></FONT></DIV>
<DIV><FONT class=EC_EC_Apple-style-span face="Gill Sans" color=#0000ff><SPAN class=EC_EC_Apple-style-span style="COLOR: rgb(0,0,255); FONT-FAMILY: Gill Sans"><SPAN class=EC_EC_Apple-style-span style="COLOR: rgb(0,0,255); FONT-FAMILY: Gill Sans">Office</SPAN></SPAN></FONT><FONT class=EC_EC_Apple-style-span face=GillSans-Light><SPAN class=EC_EC_Apple-style-span style="FONT-FAMILY: GillSans-Light"><SPAN class=EC_EC_Apple-style-span style="FONT-FAMILY: GillSans-Light"> +1 765 494 6001 | </SPAN></SPAN></FONT><FONT class=EC_EC_Apple-style-span face="Gill Sans" color=#0000ff><SPAN class=EC_EC_Apple-style-span style="COLOR: rgb(0,0,255); FONT-FAMILY: Gill Sans"><SPAN class=EC_EC_Apple-style-span style="COLOR: rgb(0,0,255); FONT-FAMILY: Gill Sans">Mobile</SPAN></SPAN></FONT><FONT class=EC_EC_Apple-style-span face=GillSans-Light><SPAN class=EC_EC_Apple-style-span style="FONT-FAMILY: GillSans-Light"><SPAN class=EC_EC_Apple-style-span style="FONT-FAMILY: GillSans-Light"> +1 765 427 5484</SPAN></SPAN></FONT></DIV>
<DIV><FONT class=EC_EC_Apple-style-span face=GillSans-Light><BR class=EC_EC_khtml-block-placeholder></FONT></DIV></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN><BR class=EC_EC_Apple-interchange-newline></SPAN></DIV></SPAN></DIV><BR></BLOCKQUOTE></BLOCKQUOTE></body>
</html>