<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Thanks for the clarification, I've seen
that this is the correct way to do this. I only have a doubt about
it. If none of the entry point symbols (_main, _wMain, etc) are
defined in the input files, the resolve phase will not fail, and
the writer would have the responsibility of throw the
corresponding link error, could be this acceptable?<br>
<br>
<br>
On 23/08/2013 21:46, Nick Kledzik wrote:<br>
</div>
<blockquote
cite="mid:07A7C815-B6EB-41CF-BF9F-871B3E0C4722@apple.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
On Aug 23, 2013, at 10:42 AM, Jesús Serrano <<a
moz-do-not-send="true" href="mailto:dagonoweda@gmail.com">dagonoweda@gmail.com</a>>
wrote:<br>
<div>
<blockquote type="cite">
<div text="#000000" bgcolor="#FFFFFF" style="font-family:
Helvetica; font-size: 12px; font-style: normal;
font-variant: normal; font-weight: normal; letter-spacing:
normal; line-height: normal; orphans: auto; text-align:
start; text-indent: 0px; text-transform: none; white-space:
normal; widows: auto; word-spacing: 0px;
-webkit-text-stroke-width: 0px;">
<div class="moz-cite-prefix">It's perfectly ok to me that
you submit the patch just as it is, as you said, it is
useful.<br>
<br>
In the other hand, I've been thinking how to implement the
final link behavior. The search of the entry point symbol
must be done obviously after the input reading. I think
that also after the resolve phase, since the " _main"
symbol could be defined in a shared library.<span
class="Apple-converted-space"> </span><span
id="result_box" class="" lang="en"><span class="hps">One
possible</span><span class="Apple-converted-space"> </span><span
class="hps">solution would be to</span><span
class="Apple-converted-space"> </span><span
class="hps">search</span><span
class="Apple-converted-space"> </span><span
class="hps">inside</span><span
class="Apple-converted-space"> </span><span class="hps
atn">a new<span class="Apple-converted-space"> </span></span><span
class="">Pass<span class="Apple-converted-space"> </span></span><span
class="hps">before</span><span
class="Apple-converted-space"> </span>the<span
class="Apple-converted-space"> </span><span
class="hps">writing.</span></span> <span
id="result_box" class="short_text" lang="en"><span
class="hps">What do you think</span><span>?</span></span><br>
</div>
</div>
</blockquote>
<div>A pass is too heavy weight, and passes cannot lookup atoms
by name…</div>
<div><br>
</div>
<div>The way to do this is like how the mach-o and ELF writers
find _main. The PECOFF Writer should implement addFiles() to
add a file to the link which has a zero size atom which has
references to UndefinedAtoms for each of those potential entry
points (_main, _wWinMain, etc). These UndefinedAtoms have a
canBeNull() of canBeNullAtBuildTime, so that the resolver will
not error if they are not found. Then when the PECOFF Writer
is told to write the file, it looks back at the magic atom it
added and look to see which of the possible entry points were
found and uses the highest priority one.</div>
<div><br>
</div>
<div>-Nick</div>
<div><br>
</div>
<br>
<blockquote type="cite">
<div text="#000000" bgcolor="#FFFFFF" style="font-family:
Helvetica; font-size: 12px; font-style: normal;
font-variant: normal; font-weight: normal; letter-spacing:
normal; line-height: normal; orphans: auto; text-align:
start; text-indent: 0px; text-transform: none; white-space:
normal; widows: auto; word-spacing: 0px;
-webkit-text-stroke-width: 0px;">
<div class="moz-cite-prefix"><br>
<br>
On 23/08/2013 1:19, Rui Ueyama wrote:<br>
</div>
<blockquote
cite="mid:CAJENXgvrfmaC+tqQMXJZP-x2j9O7yscS2jHLPLr3GkEGuSZyVQ@mail.gmail.com"
type="cite">
<div dir="ltr">Thank you for the investigation. This is
more complex than I thought and very interesting. This
behavior needs to be implemented for link.exe
compatibility. It doesn't make sense to implement this
in the driver as you wrote and should be in the linking
context.
<div><br>
</div>
<div>I want submit your patch for now, as it's useful.
You'll be able to remove the code from the driver and
add new code to the linking context. Does this sound
good?<br>
<div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Aug 20, 2013 at
1:07 PM, Jesús Serrano<span
class="Apple-converted-space"> </span><span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:dagonoweda@gmail.com"
target="_blank">dagonoweda@gmail.com</a>></span><span
class="Apple-converted-space"> </span>wrote:<br>
<blockquote class="gmail_quote" style="margin:
0px 0px 0px 0.8ex; border-left-width: 1px;
border-left-color: rgb(204, 204, 204);
border-left-style: solid; padding-left: 1ex;"><br>
<blockquote class="gmail_quote" style="margin:
0px 0px 0px 0.8ex; border-left-width: 1px;
border-left-color: rgb(204, 204, 204);
border-left-style: solid; padding-left:
1ex;">I've attached a new patch with this
changes. Now the windows driver sets the
entry symbol name according to the
corresponding options. However, this won't
work in all cases. Depending onwhether the
crt is compiled as multibyte or unicode, the
entry point symbol name changes from
"mainCRTStartup" to "wmainCRTStartup", and
the same for the windows subsystem. The
problem with this is that the use of unicode
is unknown at link time (or at least I don't
know how to retrieve this option from object
files). One possible solution would be to
have two entry point names in the linking
context, and find a symbol mathing any of
them, but I don't like it so much. Any ideas
on this?<br>
</blockquote>
<br>
I've looking into this, and seems that
LINK.EXE behavior for executable images is to
"select" the CRT entry point depending on the
symbols defined in the object files.<br>
If neither the subsystem nor the entry point
are defined in command line arguments, the
linker searches for the symbols "_main",
"_wmain", "_WinMain" and "_wWinMain".
Depending on the found symbols, the linker
chooses the subsystem and the CRT entry point,
having "_main" the highest priority and
"_wWinMain" the lesser. This is, if "_main" is
defined, the subsystem will be CONSOLE and the
CRT entry point "_mainCRTStartup", and so on.
If several of these entry point symbols for
the same subsystem are defined, the linker
chooses the symbol of higher priority and
prints a warning.<br>
If the subsystem is defined in the command
line, then the linker searches only for the
corresponding entry point symbols to choose
between the unicode and the multibyte CRT
entry point.<br>
If the entry point symbol is defined in the
command line, but not the subsystem, the
linker forces to choose one and throws an
error.<br>
<br>
If we want to follow this behavior, it has no
sense to let the driver to choose the entry
point symbol name. This could be handled by
the linking context after the file parsing or
the by writer, what do you think about that?<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a moz-do-not-send="true"
href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
<a moz-do-not-send="true"
href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
</div>
</blockquote>
</div>
<br>
</blockquote>
<br>
</body>
</html>