<div dir="ltr"><div>You said win32.h doesn't include windows.h, but main.cpp does. So what's the disadvantage of just including it in win32.h anyway, since it's already going to be in every translation unit? (Unless you didn't mean to #include it in main.cpp)</div><div><br></div><div><br></div>I guess all I can do is warn you how bad of an idea this is. For starters, I already found a bug in your code ;-)<div><br></div><div>// stdint.h<br></div><div><div>typedef int int32_t;</div></div><div><br></div><div>// winnt.h</div><div><div>typedef long LONG;</div></div><div><br></div><div>// windef.h</div><div><div>typedef struct tagPOINT<br></div><div>{</div><div> LONG x; // long x</div><div> LONG y; // long y</div><div>} POINT, *PPOINT, NEAR *NPPOINT, FAR *LPPOINT;</div></div><div><br></div><div>// win32.h</div><div><div>typedef int32_t LONG;<br></div><div><br></div><div>struct POINT</div><div>{</div><div><span style="white-space:pre"> </span>LONG x; // int x</div><div><span style="white-space:pre"> </span>LONG y; // int y</div><div>};</div></div><div><br></div><div>So POINT is defined two different ways. In your minimal interface, it's declared as 2 int32's, which are int. In the actual Windows header files, it's declared as 2 longs.</div><div><br></div><div>This might seem like a unimportant bug since int and long are the same size, but int and long also mangle differently and affect overload resolution, so you could have weird linker errors or call the wrong function overload.</div><div><br></div><div>Plus, it illustrates the fact that this struct *actually is* a different type from the one in the windows header.</div><div><br></div><div>You said at the end that you never intentionally import win32.h and windows.h from the same translation unit. But then in this example you did. I wonder if you could enforce that by doing this:</div><div><br></div><div>// win32.h</div><div>#pragma once</div><div><br></div><div>// Error if windows.h was included before us.</div><div>#if defined(_WINDOWS_)<br></div><div>#error "You're including win32.h after having already included windows.h. Don't do this!"</div><div>#endif</div><div><br></div><div>// And also make sure windows.h can't get included after us</div><div>#define _WINDOWS_</div><div><br></div><div>For the record, I tried the test case you linked when windows.h is not included in main.cpp and it works (but still has the bug about int and long).</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jan 22, 2018 at 2:23 PM Leonardo Santagada <<a href="mailto:santagada@gmail.com">santagada@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>It is super gross, but we copy parts of windows.h because having all of it if both gigantic and very very messy. So our win32.h has a couple thousands of lines and not 30k+ for windows.h and we try to have zero macros. Win32.h doesn't include windows.h so using ::BOOL wouldn't work. We don't want to create a namespace, we just want a cleaner interface to windows api. The namespace with c linkage is the way to trick cl into allowing us to in some files have both windows.h and Win32.h. I really don't see any way for us to have this Win32.h without this cl support, so maybe we should either put windows.h in a compiled header somewhere and not care that it is infecting everything or just have one place we can call to clean up after including windows.h (a massive set of undefs).<br><br></div><div>So using can't work, because we never intentionally import windows.h and win32.h on the same translation unit.<br></div></div><div class="gmail_extra"></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 22, 2018 at 7:08 PM, Zachary Turner <span dir="ltr"><<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">This is pretty gross, honestly :)<div><br></div><div>Can't you just use using declarations?</div><div><br></div><div><div>namespace Win32 {</div><div>extern "C" { </div><div><br></div><div>using ::BOOL;</div><div>using ::LONG;</div><div>using ::POINT;</div><div>using ::LPPOINT;</div><div><br></div><div>using ::GetCursorPos;</div><div>}</div><div>}</div></div><div><br></div><div>This works with clang-cl.</div></div><div class="m_6098347775258118141HOEnZb"><div class="m_6098347775258118141h5"><br><div class="gmail_quote"><div dir="ltr">On Mon, Jan 22, 2018 at 5:39 AM Leonardo Santagada <<a href="mailto:santagada@gmail.com" target="_blank">santagada@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Here it is a minimal example, we do this so we don't have to import the whole windows api everywhere.<br><div><br><a href="https://gist.github.com/santagada/7977e929d31c629c4bf18ebb987f6be3" target="_blank">https://gist.github.com/santagada/7977e929d31c629c4bf18ebb987f6be3</a><br></div></div><div class="gmail_extra"></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jan 21, 2018 at 2:31 AM, Zachary Turner <span dir="ltr"><<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Clang-cl maintains compatibility with msvc even in cases where it’s non standards compliant (eg 2 phase name lookup), but we try to keep these cases few and far between.<br><br>To help me understand your case, do you mean you copy windows.h and modify it? How does this lead to the same struct being defined twice? If i were to write this:<br><br>struct Foo {};<br>struct Foo {};<br><br>Is this a small repro of the issue you’re talking about?<div class="m_6098347775258118141m_8303529303722936371m_4449077111515507084HOEnZb"><div class="m_6098347775258118141m_8303529303722936371m_4449077111515507084h5"><br><div class="gmail_quote"><div dir="ltr">On Sat, Jan 20, 2018 at 3:44 PM Leonardo Santagada <<a href="mailto:santagada@gmail.com" target="_blank">santagada@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I can totally see something like incremental linking with a simple padding between obj and a mapping file (which can also help with edit and continue, something we also would love to have). <br><br>We have another developer doing the port to support clang-cl, but although most of our code also goes trough a version of clang, migrating the rest to clang-cl has been a fight. From what I heard the main problem is that we have a copy of parts of windows.h (so not to bring the awful parts of it like lower case macros) and that totally works on cl, but clang (at least 6.0) complains about two struct/vars with the same name, even though they are exactly the same. Making clang-cl as broken as cl.exe is not an option I suppose? I would love to turn on a flag --accept-that-cl-made-bad-decisions-and-live-with-it and have this at least until this is completely fixed in our code base.<br><br></div>the biggest win with moving to cl would be a better more standards compliant compiler, no 1 minute compiles on heavily templated files and maybe the holy grail of ThinLTO.<br></div><div class="gmail_extra"></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jan 20, 2018 at 10:56 PM, Zachary Turner <span dir="ltr"><<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">10-15s will be hard without true incremental linking.<div><br></div><div>At some point that's going to be the only way to get any faster, but incremental linking is hard (putting it lightly), and since our full links are already really fast we think we can get reasonably close to link.exe incremental speeds with full links. But it's never enough and I will always want it to be faster, so you may see incremental linking in the future after we hit a performance wall with full link speed :)</div><div><br></div><div>In any case, I'm definitely interested in seeing what kind of numbers you get with /debug:ghash after you get this llvm-objcopy feature implemented. So keep me updated :)</div><div><br></div><div>As an aside, have you tried building with clang instead of cl? If you build with clang you wouldn't even have to do this llvm-objcopy work, because it would "just work". If you've tried but ran into issues I'm interested in hearing about those too. On the other hand, it's also reasonable to only switch one thing at a time.</div></div><div class="m_6098347775258118141m_8303529303722936371m_4449077111515507084m_6328300659575866201m_3251013050043970285HOEnZb"><div class="m_6098347775258118141m_8303529303722936371m_4449077111515507084m_6328300659575866201m_3251013050043970285h5"><br><div class="gmail_quote"><div dir="ltr">On Sat, Jan 20, 2018 at 1:34 PM Leonardo Santagada <<a href="mailto:santagada@gmail.com" target="_blank">santagada@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">if we get to < 30s I think most users would prefer it to link.exe, just hopping there is still some more optimizations to get closer to ELF linking times (around 10-15s here).<br></div><div class="gmail_extra"></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jan 20, 2018 at 9:50 PM, Zachary Turner <span dir="ltr"><<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Generally speaking a good rule of thumb is that /debug:ghash will be close to or faster than /debug:fastlink, but with none of the penalties like slow debug time <br><div class="m_6098347775258118141m_8303529303722936371m_4449077111515507084m_6328300659575866201m_3251013050043970285m_4290125905266486172m_-4983865677775689192HOEnZb"><div class="m_6098347775258118141m_8303529303722936371m_4449077111515507084m_6328300659575866201m_3251013050043970285m_4290125905266486172m_-4983865677775689192h5"><div class="gmail_quote"><div dir="ltr">On Sat, Jan 20, 2018 at 12:44 PM Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Chrome is actually one of my exact benchmark cases. When building blink_core.dll and browser_tests.exe, i get anywhere from a 20-40% reduction in link time. We have some other optimizations in the pipeline but not upstream yet.<br><br>My best time so far (including other optimizations not yet upstream) is 28s on blink_core.dll, compared to 110s with /debug<br><div class="gmail_quote"><div dir="ltr">On Sat, Jan 20, 2018 at 12:28 PM Leonardo Santagada <<a href="mailto:santagada@gmail.com" target="_blank">santagada@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">On Sat, Jan 20, 2018 at 9:05 PM, Zachary Turner <span dir="ltr"><<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>></span> wrote:<br></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">You probably don't want to go down the same route that clang goes through to write the object file. If you think yaml2coff is convoluted, the way clang does it will just give you a headache. There are multiple abstractions involved to account for different object file formats (ELF, COFF, MachO) and output formats (Assembly, binary file). At least with yaml2coff <br></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I think your phrase got cut there, but yeah I just found AsmPrinter.cpp and it is convoluted.<br><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>It's true that yaml2coff is using the COFFParser structure, but if you look at the <span style="color:rgb(33,33,33)">writeCOFF function in yaml2coff it's pretty bare-metal. The logic you need will be almost identical, except that instead of checking the COFFParser for the various fields, you'll check the existing COFFObjectFile, which should have similar fields.</span></div><div><span style="color:rgb(33,33,33)"><br></span></div><div><span style="color:rgb(33,33,33)">The only thing you need to different is when writing the section table and section contents, to insert a new entry. </span><span style="color:rgb(33,33,33)">Since you're injecting a section into the middle, you'll also probably need to push back the file pointer of all subsequent sections so that they don't overlap. (e.g. if the original sections are 1, 2, 3, 4, 5 and you insert between 2 and 3, then the original sections 3, 4, and 5 would need to have their FilePointerToRawData offset by the size of the new section).</span></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I have the PE/COFF spec open here and I'm happy that I read a bit of it so I actually know what you are talking about... yeah it doesn't seem too complicated. <br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><span style="color:rgb(33,33,33)"></span></div><div><span style="color:rgb(33,33,33)">If you need to know what values to put for the other fields in a section header, run `dumpbin /headers foo.obj` on a clang-generated object file that has a .debug$H section already (e.g. run clang with -emit-codeview-ghash-section, and look at the properties of the .debug$H section and use the same values).</span></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Thanks I will do that and then also look at how the CodeView part of the code does it if I can't understand some of it. <br><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><span style="color:rgb(33,33,33)"><br></span></div><div><span style="color:rgb(33,33,33)">The only invariant that needs to be maintained is that Section[N]->FilePointerOfRawData == Section[N-1]->FilePointerOfRawData + Section[N-1]->SizeOfRawData</span></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Well, that and all the sections need to be on the final file... But I'm hopeful.<br><br><br></div><div>Anyone has times on linking a big project like chrome with this so that at least I know what kind of performance to expect?<br><br></div><div>My numbers are something like:<br><br></div><div>1 pdb per obj file: link.exe takes ~15 minutes and 16GB of ram, lld-link.exe takes 2:30 minutes and ~8GB of ram<br></div><div>around 10 pdbs per folder: link.exe takes 1 minute and 2-3GB of ram, lld-link.exe takes 1:30 minutes and ~6GB of ram<br></div><div>faslink: link.exe takes 40 seconds, but then 20 seconds of loading at the first break point in the debugger and we lost DIA support for listing symbols.<br></div><div>incremental: link.exe takes 8 seconds, but it only happens when very minor changes happen.<br></div><div><br></div><div>We have an non negligible number of symbols used on some runtime systems.<br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_6098347775258118141m_8303529303722936371m_4449077111515507084m_6328300659575866201m_3251013050043970285m_4290125905266486172m_-4983865677775689192m_1330076587365671697m_3129290989285100139m_8012910641178389879HOEnZb"><div class="m_6098347775258118141m_8303529303722936371m_4449077111515507084m_6328300659575866201m_3251013050043970285m_4290125905266486172m_-4983865677775689192m_1330076587365671697m_3129290989285100139m_8012910641178389879h5"><br><div class="gmail_quote"><div dir="ltr">On Sat, Jan 20, 2018 at 11:52 AM Leonardo Santagada <<a href="mailto:santagada@gmail.com" target="_blank">santagada@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Thanks for the tips, I now have something that reads the obj file, finds .debug$T sections and global hashes it (proof of concept kind of code). What I can't find is: how does clang itself writes the coff files with global hashes, as that might help me understand how to create the .debug$H section, how to update the file section count and how to properly write this back.<br><br></div>The code on yaml2coff is expecting to be working on the yaml COFFParser struct and I'm having quite a bit of a headache turning the COFFObjectFile into a COFFParser object or compatible... Tomorrow I might try the very non efficient path of coff2yaml and then yaml2coff with the hashes header... but it seems way too inefficient and convoluted.<br></div><div class="gmail_extra"></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 19, 2018 at 10:38 PM, Zachary Turner <span dir="ltr"><<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote"><span><div dir="ltr">On Fri, Jan 19, 2018 at 1:02 PM Leonardo Santagada <<a href="mailto:santagada@gmail.com" target="_blank">santagada@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">On Fri, Jan 19, 2018 at 9:44 PM, Zachary Turner <span dir="ltr"><<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote"><span><div dir="ltr">On Fri, Jan 19, 2018 at 12:29 PM Leonardo Santagada <<a href="mailto:santagada@gmail.com" target="_blank">santagada@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi,</div><div><br></div><div>No I didn't, I used cl.exe from the visual studio toolchain. What I'm proposing is a tool for processing .obj files in COFF format, reading them and generating the GHASH part.</div><div><br></div><div>To make our build faster we use hundreds of unity build files (.cpp's with a lot of other .cpp's in them aka munch files) but still have a lot of single .cpp's as well (in total something like 3.4k .obj files).</div><div><br></div><div>ps: sorry for sending to the wrong list, I was reading about llvm mailing lists and jumped when I saw what I thought was a lld exclusive list.<br></div></div></blockquote><div><br></div></span><div>A tool like this would be useful, yes. We've talked about it internally as well and agreed it would be useful, we just haven't prioritized it. If you're interested in submitting a patch along those lines though, I think it would be a good addition.</div><div><br></div><div>I'm not sure what the best place for it would be. llvm-readobj and llvm-objdump seem like obvious choices, but they are intended to be read-only, so perhaps they wouldn't be a good fit.</div><div><br></div><div>llvm-pdbutil is kind of a hodgepodge of everything else related to PDBs and symbols, so I wouldn't be opposed to making a new subcommand there called "ghash" or something that could process an object file and output a new object file with a .debug$H section.</div><div><br></div><div>A third option would be to make a new tool for it.</div><div><br></div><div>I don't htink it would be that hard to write. If you're interested in trying to make a patch for this, I can offer some guidance on where to look in the code. Otherwise it's something that we'll probably get to, I'm just not sure when.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra">
</div></blockquote></div></div>
</blockquote></div></div><div class="gmail_extra"><br></div></div><div dir="ltr"><div class="gmail_extra">I would love to write it and contribute it back, please do tell, I did find some of the code of ghash in lld, but in fuzzy on the llvm codeview part of it and never seen llvm-readobj/objdump or llvm-pdbutil, but I'm not afraid to look :)<br></div></div><div dir="ltr"><div class="gmail_extra"><br></div></div></blockquote><div><br></div></span><div> Luckily all of the important code is hidden behind library calls, and it should already just do the right thing, so I suspect you won't need to know much about CodeView to do this.</div><div><br></div><div>I think Peter has the right idea about putting this in llvm-objcopy.</div><div><br></div><div>You can look at one of the existing CopyBinary functions there, which currently only work for ELF, but you can just make a new overload that accepts a COFFObjectFile.</div><div><br></div><div>I would probably start by iterating over each of the sections (getNumberOfSections / getSectionName) looking for .debug$T and .debug$H sections. </div><div><br></div><div>If you find a .debug$H section then you can just skip that object file. </div><div><br></div><div>If you find a .debug$T but not a .debug$H, then basically do the same thing that LLD does in PDBLinker::mergeDebugT (create a CVTypeArray, and pass it to GloballyHashedType::hashTypes. That will return an array of hash values. (the format of .debug$H is the header, followed by the hash values). Then when you're writing the list of sections, just add in the .debug$H section right after the .debug$T section.</div><div><br></div><div>Currently llvm-objcopy only writes ELF files, so it would need to be taught to write COFF files. We have code to do this in the yaml2obj utility (specifically, in yaml2coff.cpp in the function writeCOFF). There may be a way to move this code to somewhere else (llvm/Object/COFF.h?) so that it can be re-used by both yaml2coff and llvm-objcopy, but in the worst case scenario you could copy the code and re-write it to work with these new structures.</div><div><br></div><div>Lastly, you'll probably want to put all of this behind an option in llvm-objcopy such as -add-codeview-ghash-section</div><div><br></div></div></div>
</blockquote></div><br><br clear="all"><br></div><div class="gmail_extra">-- <br><div class="m_6098347775258118141m_8303529303722936371m_4449077111515507084m_6328300659575866201m_3251013050043970285m_4290125905266486172m_-4983865677775689192m_1330076587365671697m_3129290989285100139m_8012910641178389879m_8441690070965861958m_6919085447883523515gmail_signature" data-smartmail="gmail_signature"><br>Leonardo Santagada</div>
</div></blockquote></div>
</div></div></blockquote></div></div></div><div dir="ltr"><div class="gmail_extra"><br><br clear="all"><br>-- <br><div class="m_6098347775258118141m_8303529303722936371m_4449077111515507084m_6328300659575866201m_3251013050043970285m_4290125905266486172m_-4983865677775689192m_1330076587365671697m_3129290989285100139m_8012910641178389879gmail_signature" data-smartmail="gmail_signature"><br>Leonardo Santagada</div>
</div></div></blockquote></div></blockquote></div>
</div></div></blockquote></div><br><br clear="all"><br></div><div class="gmail_extra">-- <br><div class="m_6098347775258118141m_8303529303722936371m_4449077111515507084m_6328300659575866201m_3251013050043970285m_4290125905266486172m_-4983865677775689192gmail_signature" data-smartmail="gmail_signature"><br>Leonardo Santagada</div>
</div></blockquote></div>
</div></div></blockquote></div><br><br clear="all"><br></div><div class="gmail_extra">-- <br><div class="m_6098347775258118141m_8303529303722936371m_4449077111515507084m_6328300659575866201m_3251013050043970285gmail_signature" data-smartmail="gmail_signature"><br>Leonardo Santagada</div>
</div></blockquote></div>
</div></div></blockquote></div><br><br clear="all"><br></div><div class="gmail_extra">-- <br><div class="m_6098347775258118141m_8303529303722936371m_4449077111515507084gmail_signature" data-smartmail="gmail_signature"><br>Leonardo Santagada</div>
</div></blockquote></div>
</div></div></blockquote></div><br><br clear="all"><br></div><div class="gmail_extra">-- <br><div class="m_6098347775258118141gmail_signature" data-smartmail="gmail_signature"><br>Leonardo Santagada</div>
</div></blockquote></div>