[llvm-dev] GSoC19: Improve LLVM binary utilities

Tue Mar 26 15:40:28 PDT 2019

(Adding just a bit to Jake's response)

On Tue, Mar 26, 2019 at 11:31 AM Jake Ehrlich via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi Seiya,
>
> What should I prioritize? I suppose that improving llvm-objcopy is the
>> most crucial work in this summer.
>
>
> This is an opinion that will vary a lot from person to person.
>
+1! And don't forget that one of those people is you -- I don't think it
would be useful to start a gsoc project on something you don't enjoy just
because others think it's important. I would agree about objcopy :) but I'm
also happy to help you figure out what project you'd like for any other
tool.

At the top of my list is improvements to llvm-objdump and working on MachO
> backends for LLD and llvm-objcopy. The critical thing to avoid IMO is
> implementing features without a direct use case in mind. I've let myself
> fall victim to this mistake many times before. I would ask the community
> for improvements they want to see and especially relay on your host to
> guide the direction you take. If you and your host feel that llvm-objcopy
> is the most critical then I certainly know some people and use cases that
> would be interested and will respond to an email on llvm-dev asking what
> you could work on. Several people have been adding bugs for llvm-objcopy
> recently and you should be able to find things to do there.
>

I think objcopy has the *most* things that have left to be done, but
there's plenty of work in other binutils. I'm not sure if any particular
bit would be called "crucial" however.
A couple ideas that have been kicked around for llvm-objcopy are:
* Librarify it (https://bugs.llvm.org/show_bug.cgi?id=41044)
* Improve MachO/COFF support (COFF support is pretty good, MachO is barely
there).
* Support ihex (https://bugs.llvm.org/show_bug.cgi?id=39841) or efi (
https://bugs.llvm.org/show_bug.cgi?id=40618) [Not that many people are
probably asking for these though]

> How can I avoid proposing functionalities that others are already working
>> on? It seems that the tools have been still actively developed.
>>
>
> The bug tracker is one way to look at this, people will say if they're
> working on any open bugs there. In practice I found that if I have a real
> use case and the feature I need hasn't been implemented, no one is likely
> to be currently working on it. For bigger features you should email
> llvm-dev. Many people are likely to have thought about how bigger features
> should be implemented and there's a better chance that someone is already
> actively working on things.
>
> Are there good first issues related to the project? This is the first time
>> for me to dig into the LLVM source code so currently I cannot show
>> convincing evidence that I'm able to work on the project.
>
> Well I have biased opinions. I'd like alignment to be better handled in
> llvm-objdump, I'd like for symbol references to be resolved in an easier to
> parse fashion, and for module and function offsets to be output in a way
> that makes them easy to jump between.
>
> Many bugs (though not enough) are tagged with the "beginner" keyword:
https://bugs.llvm.org/buglist.cgi?quicksearch=keyword%3Abeginner&list_id=157827.
That's usually a good start.

> On Tue, Mar 26, 2019 at 3:34 AM Seiya Nuta via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi all,
>>
>> My name is Seiya Nuta. I'm studying for my master's degree in University
>> of Tsukuba and interested in the project named "Improve LLVM binary
>> utilities". I've skimmed through llvm-objcopy/llvm-objdump, commit logs,
>> and Bugzilla to figure out what should I do.
>>
>> I have some questions about the project:
>>
>> - What should I prioritize? I suppose that improving llvm-objcopy is the
>>    most crucial work in this summer.
>> - How can I avoid proposing functionalities that others are already
>>    working on? It seems that the tools have been still actively
>>    developed.
>> - Are there good first issues related to the project? This is the first
>>    time for me to dig into the LLVM source code so currently I cannot
>>    show convincing evidence that I'm able to work on the project.
>>
>> Best regards,
>> Seiya
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190326/efa63838/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4849 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190326/efa63838/attachment-0001.bin>