llvm dev - Mar 2018 - [cfe-dev] [GSOC 2018] Information gathering

Hi,

On 03/20/2018 06:05 AM, Eric Christopher wrote:
> 
> 
> On Fri, Mar 16, 2018 at 1:57 AM Paul Semel <semelpaul at gmail.com 
> <mailto:semelpaul at gmail.com>> wrote:
> 
>     Hi Eric,
> 
> 
>     On 03/15/2018 04:33 PM, Eric Christopher wrote:
>>     Hi Paul,
>>
>>
>>         >> I'm also interested in the command line
replacements for
>>         GNU Binutils :
>>         >>
>>         >> - What tools would you like to replace in priority ?
>>         >> - Does this subject imply to add options/features to
some
>>         of the
>>         >> tools, or is it only about handling command line ?
>>         >
>>
>>
>>     I just replied with this in another thread:
>>
>>     "It's currently still available. The basic idea is that
we'd be
>>     working on getting each of the llvm tools or libraries with a
>>     front end that is command line compatible with the GNU binutils
>>     counterpart to serve as a replacement. Whether or not we made them
>>     output compatible is something else, but we'll probably want to
>>     have a couple different modes there from:
>>
>>     a) The compatible tool,
>>     b) The tool we all want.
>>
>>     A and B could be the same, but then again, they might not. The low
>>     bar for the SoC project is going to be A."
>>
>>     And in priority order I'd probably want to finish off objcopy
>>     support (see the recent thread on llvm-dev) and
>>     objdump/readobj/readelf and then go from there.
>>
>>     Thoughts?
>>
>>     -eric
> 
>     I saw the thread you are talking about. So basically, the idea would
>     be to do the correct calls for either COFF subset of functions of
>     ELF ones wether we have a COFF or ELF file as an input.
>     Am I right ?
> 
> 
> Basically what I'm looking for first is a command line equivalent 
> replacement first for gnu objcopy. I'd focus on ELF first, and then
move
> to COFF/PE. I'd start from the work that Jake (cc'd) has already
done
> and work with Zach (cc'd) on the COFF stuff if he's still
interested. Of
> course, I'll be around for the first bit.
> 
> Then follow up with objcopy, etc as there's time.
> 
I think you meant objdump, right ? (you talked about objcopy in your 
previous paragraph).
>     I am really interested in doing a proposal for this subject. What do
>     you expect to be in it ? I was actually thinking of something like
>     exposing the things I've done in LLVM/CLang, the schedule for the 3
>     months (but for this, I need to talk with you about the high
>     priority tools, as I'm not sure it is possible to do all the
>     frontend tools in such amount of time)..
> 
> 
> Showing off your previous work is absolutely great in a proposal. A 
> timeline and some proof that you've at least looked at what's
missing
> and have ideas at how to do the work would be key. And I don't really 
> expect you to finish all of them - at least not without help, but with 
> some luck there might be other contributors to help :)
> 
Alright, that sounds very good ! For the moment, what I've done is that 
I listed the tools that were needed command line replacements (for some 
of those it is really binign).

Do I need to take LLD into account in my timeline ?

Then, I investigated a bit on the different tools command line, and what 
I have learnt so far is that objdump and objcopy are the ones that 
require the biggest amount of work (again, not took LLD into account so 
far).
> Sound good? We can definitely work on the details as you're interested
-
> I'll also be more responsive in the near future as well.
> 
I have shared my draft in the GSOC 2018 Dashboard, but here is a link so 
that you have it right in the email[0]. I would really like to have 
feedback on it, espacially for the timeline I made. (but I'd really 
appreciate for the rest of the draft too 🙂).

I am actually not sure at all about the time it would take for the 
replacement of llvm-objcopy, so maybe Jake and/or Zach would have an 
idea about it, as they already worked on this subject ! 🙂
> Thanks!
> 
> -eric
Thanks,

-- 
Paul Semel

[0] 
https://docs.google.com/document/d/14gEdNv-X6p_a6Hsqvb1PmQcaXHateCct1yEhLEFb2-I

Hi,

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

Here is the link to the proposal : 
https://docs.google.com/document/d/14gEdNv-X6p_a6Hsqvb1PmQcaXHateCct1yEhLEFb2-I/edit#heading=h.glzr12mhpfei

Thanks,

-- 
Paul

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.

-eric

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