<div dir="ltr">FWIW I'm happy enough with the proposal and while the timeline isn't necessarily the best - it's not like we have particular amazing thoughts here either.<div><br></div><div>-eric</div></div><br><div class="gmail_quote"><div dir="ltr">On Sun, Mar 25, 2018 at 8:39 AM Paul Semel <<a href="mailto:semelpaul@gmail.com">semelpaul@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
On 03/20/2018 03:06 PM, Paul Semel wrote:<br>
> Hi,<br>
><br>
> On 03/20/2018 06:05 AM, Eric Christopher wrote:<br>
>><br>
>><br>
>> On Fri, Mar 16, 2018 at 1:57 AM Paul Semel <<a href="mailto:semelpaul@gmail.com" target="_blank">semelpaul@gmail.com</a><br>
>> <mailto:<a href="mailto:semelpaul@gmail.com" target="_blank">semelpaul@gmail.com</a>>> wrote:<br>
>><br>
>>     Hi Eric,<br>
>><br>
>><br>
>>     On 03/15/2018 04:33 PM, Eric Christopher wrote:<br>
>>>     Hi Paul,<br>
>>><br>
>>><br>
>>>         >> I'm also interested in the command line replacements for<br>
>>>         GNU Binutils :<br>
>>>         >><br>
>>>         >> - What tools would you like to replace in priority ?<br>
>>>         >> - Does this subject imply to add options/features to some<br>
>>>         of the<br>
>>>         >> tools, or is it only about handling command line ?<br>
>>>         ><br>
>>><br>
>>><br>
>>>     I just replied with this in another thread:<br>
>>><br>
>>>     "It's currently still available. The basic idea is that we'd be<br>
>>>     working on getting each of the llvm tools or libraries with a<br>
>>>     front end that is command line compatible with the GNU binutils<br>
>>>     counterpart to serve as a replacement. Whether or not we made them<br>
>>>     output compatible is something else, but we'll probably want to<br>
>>>     have a couple different modes there from:<br>
>>><br>
>>>     a) The compatible tool,<br>
>>>     b) The tool we all want.<br>
>>><br>
>>>     A and B could be the same, but then again, they might not. The low<br>
>>>     bar for the SoC project is going to be A."<br>
>>><br>
>>>     And in priority order I'd probably want to finish off objcopy<br>
>>>     support (see the recent thread on llvm-dev) and<br>
>>>     objdump/readobj/readelf and then go from there.<br>
>>><br>
>>>     Thoughts?<br>
>>><br>
>>>     -eric<br>
>><br>
>>     I saw the thread you are talking about. So basically, the idea would<br>
>>     be to do the correct calls for either COFF subset of functions of<br>
>>     ELF ones wether we have a COFF or ELF file as an input.<br>
>>     Am I right ?<br>
>><br>
>><br>
>> Basically what I'm looking for first is a command line equivalent<br>
>> replacement first for gnu objcopy. I'd focus on ELF first, and then<br>
>> move to COFF/PE. I'd start from the work that Jake (cc'd) has already<br>
>> done and work with Zach (cc'd) on the COFF stuff if he's still<br>
>> interested. Of course, I'll be around for the first bit.<br>
>><br>
>> Then follow up with objcopy, etc as there's time.<br>
>><br>
><br>
> I think you meant objdump, right ? (you talked about objcopy in your<br>
> previous paragraph).<br>
><br>
>>     I am really interested in doing a proposal for this subject. What do<br>
>>     you expect to be in it ? I was actually thinking of something like<br>
>>     exposing the things I've done in LLVM/CLang, the schedule for the 3<br>
>>     months (but for this, I need to talk with you about the high<br>
>>     priority tools, as I'm not sure it is possible to do all the<br>
>>     frontend tools in such amount of time)..<br>
>><br>
>><br>
>> Showing off your previous work is absolutely great in a proposal. A<br>
>> timeline and some proof that you've at least looked at what's missing<br>
>> and have ideas at how to do the work would be key. And I don't really<br>
>> expect you to finish all of them - at least not without help, but with<br>
>> some luck there might be other contributors to help :)<br>
>><br>
><br>
> Alright, that sounds very good ! For the moment, what I've done is that<br>
> I listed the tools that were needed command line replacements (for some<br>
> of those it is really binign).<br>
><br>
> Do I need to take LLD into account in my timeline ?<br>
><br>
> Then, I investigated a bit on the different tools command line, and what<br>
> I have learnt so far is that objdump and objcopy are the ones that<br>
> require the biggest amount of work (again, not took LLD into account so<br>
> far).<br>
><br>
>> Sound good? We can definitely work on the details as you're interested<br>
>> - I'll also be more responsive in the near future as well.<br>
>><br>
> I have shared my draft in the GSOC 2018 Dashboard, but here is a link so<br>
> that you have it right in the email[0]. I would really like to have<br>
> feedback on it, espacially for the timeline I made. (but I'd really<br>
> appreciate for the rest of the draft too 🙂).<br>
><br>
> I am actually not sure at all about the time it would take for the<br>
> replacement of llvm-objcopy, so maybe Jake and/or Zach would have an<br>
> idea about it, as they already worked on this subject ! 🙂<br>
><br>
>> Thanks!<br>
>><br>
>> -eric<br>
><br>
> Thanks,<br>
><br>
<br>
I am really sorry to go for it again, but I would really appreciate to<br>
have feedbacks on my Timeline 🙂<br>
<br>
Here is the link to the proposal :<br>
<a href="https://docs.google.com/document/d/14gEdNv-X6p_a6Hsqvb1PmQcaXHateCct1yEhLEFb2-I/edit#heading=h.glzr12mhpfei" rel="noreferrer" target="_blank">https://docs.google.com/document/d/14gEdNv-X6p_a6Hsqvb1PmQcaXHateCct1yEhLEFb2-I/edit#heading=h.glzr12mhpfei</a><br>
<br>
Thanks,<br>
<br>
--<br>
Paul<br>
</blockquote></div>