search for: jakehehrlich

...ry case is different, but yes, as I said - I would like to take a closer look at the problem again, it might be the case that we don't need this complexity in this particular case, but want to double check. But yeah, in general I agree with you! On Thu, May 9, 2019 at 6:09 PM Jake Ehrlich <jakehehrlich at google.com> wrote: > I think that pretty much hits the nail on the head. The llvm-objcopy code > is for when you need to perform mutations primarily. A common mistake (well > a mistake in my opinion) I see is people wanting a one size fits all > solution when one doesn't exis...

On Tue, Jun 25, 2019 at 4:05 PM Jake Ehrlich <jakehehrlich at google.com> wrote: > Syscalls are operating system specific and architecture dependent so I > think we'll want an abstraction layer around the fundamental operations the > syscalls support anyway. Some things like open aren't even syscalls on all > operating > Right,...

That's something I want to do as well for several reasons. That's an orthogonal issue however. On Tue, Oct 2, 2018, 10:21 AM Eric Christopher <echristo at gmail.com> wrote: > I'd give some consideration to moving the objcopy support itself into a > library inside llvm (possibly lib/Object as that makes the most sense) and > then the tool is just a thin wrapper on top

On Mon, Jun 24, 2019 at 3:37 PM Jake Ehrlich <jakehehrlich at google.com> wrote: > disclaimer: I work at Google so don't take my +1 as an independent vote > forward. > > We would like to use this on Fuchsia and I am particularly interested in > creating a dynamic linking library for ELF with Roland McGrath's guidance. > We spo...

...us things can be simpler. I'd like to think a bit more about it to make sure I'm not missing anything important here. But anyway, I think it's very useful to discuss this problem, many thanks for your comments! Kind regards, Alex On Thu, May 9, 2019 at 4:34 PM Jake Ehrlich <jakehehrlich at google.com> wrote: > A) It sounds like you're pretty sure that llvm-objcopy style code could be > correctly reused here. Assuming that's the case this is probably not the > ideal option > > B) This is something we want to do anyway and sounds like the most ideal > s...

...I keep up to date on the symbolizer status? Our symbolizer is provided by the Myriad vendor and integrated into its host test environment. It doesn't do much: just look for PC string patterns and symbolize them using addr2line. Thanks, Walter On Fri, May 4, 2018 at 5:36 PM Jake Ehrlich <jakehehrlich at google.com> wrote: > Hey, > I work on fuchsia symbolizer stuff. I don't know if you guys already have an external symbolizer but I'm working on making one right now and I plan on making one backed by LLVM that can be run host-side or target-side. I'd like to contribute tha...

Woah this is a good idea. I'd ask that alignment come in different bit sizes and endienesses so that we can add an alignment type to ELF types. I would love to review this and add it to llvm-objcopy. We have special functions to handle all of these 'zero' cases. Several other bits of code I've seen/written have to find maximum alignment and I'd imagine the mistake of not

Hi Jake, Thank you for your reply! That would explain a lot. What are some ways in which llvm-object still could use work? Depending on how much work remains, maybe it would be an interesting GSOC project? Kind Regards, Sebastiaan Peters ________________________________ From: Jake Ehrlich <jakehehrlich at google.com> Sent: Monday, March 19, 2018 19:49 To: Sebastiaan Peters Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] [GSOC 2018] GNU Binutils replacement Hi Sebastiaan, I'm not the creator of the this GSOC project but I might be able to help. I'm the author of llvm-objcopy, a...

Great to hear, thanks! On Thu, Sep 20, 2018 at 1:56 PM Jake Ehrlich <jakehehrlich at google.com> wrote: > A member of my team +Armando Montanez <amontanez at google.com> is going to > drop a proposal for the ELF part of this soon (like sometime next week) and > will be working on the implementation. I'll be one of the reviewers for > anything that comes...

...d explain a lot. > > What are some ways in which llvm-object still could use work? > Depending on how much work remains, maybe it would be an interesting GSOC > project? > > Kind Regards, > > Sebastiaan Peters > ------------------------------ > *From:* Jake Ehrlich <jakehehrlich at google.com> > *Sent:* Monday, March 19, 2018 19:49 > *To:* Sebastiaan Peters > *Cc:* llvm-dev at lists.llvm.org > *Subject:* Re: [llvm-dev] [GSOC 2018] GNU Binutils replacement > > Hi Sebastiaan, > > I'm not the creator of the this GSOC project but I might be able...

...r approach than passing a callback to getFileOrSTDIN which perhaps not all tools will use anyway. I am leaning towards doing it outside of getFileOrSTDIN. Does anyone have a preference either way, or a better solution than the above two? Best, Alex On Wed, Jun 26, 2019 at 3:09 PM Jake Ehrlich <jakehehrlich at google.com> wrote: > I think consistency is key and agree that people are likely not using this > anywhere. It's better to go after the ideal at first but we need to be > willing to offer some path forward on these tools if it turns out large > code bases that can't be ea...

Hi Sebastiaan, I'm not the creator of the this GSOC project but I might be able to help. I'm the author of llvm-objcopy, and the soon to be creator of the symlink llvm-strip to llvm-objcopy (which currently doesn't exist). The reason llvm-objcopy and llvm-strip don't have documentation pages is because I haven't written them yet; I'll get on that! 1. The goal is to work

Hey, I work on fuchsia symbolizer stuff. I don't know if you guys already have an external symbolizer but I'm working on making one right now and I plan on making one backed by LLVM that can be run host-side or target-side. I'd like to contribute that back to llvm ideally. What do you guys have so far? I have a prototype in golang that just spins up an instance of llvm-symbolizer

Hey everyone! Objcopy is a powerful tool that allows one to modify object files in various manners, for example, modify symbols / symbol tables or copy / remove particular parts of a binary. It also serves as a basis for the strip tool. Currently, llvm-objcopy only supports ELF files while binutils' objcopy can handle Mach-O files as well. Besides extending the existing tool to support Mach-O

Fantastic! Thanks for all of the input! I'll be considering all of it going forward. The plan right now is just to worry about ELF executables and nothing else. I'm very sympathetic to the "llvm-objtool" change. If everyone is cool with it I'll change the name in the next CL to "llvm-objtool". To start out I implemented a very basic ELF64LE specific bit of code.

...are some ways in which llvm-object still could use work? >> Depending on how much work remains, maybe it would be an interesting GSOC >> project? >> >> Kind Regards, >> >> Sebastiaan Peters >> ------------------------------ >> *From:* Jake Ehrlich <jakehehrlich at google.com> >> *Sent:* Monday, March 19, 2018 19:49 >> *To:* Sebastiaan Peters >> *Cc:* llvm-dev at lists.llvm.org >> *Subject:* Re: [llvm-dev] [GSOC 2018] GNU Binutils replacement >> >> Hi Sebastiaan, >> >> I'm not the creator of the this G...

Hey everyone! In October/November 2018 I started the implementation of llvm-objcopy for MachO with the long-term plan to build some popular binary-level tools on top of it. That effort stopped at the stage where some boilerplate code for reading/writing MachO files was reviewed & committed to LLVM/tools/llvm-objcopy. Later I started working on llvm-lipo (a drop-in replacing for the tool

Hello everyone, My name is Sebastiaan Peters, an undergrad student from The Netherlands. The project for creating drop-in replacements for GNU Binutils peaked my interest. It would make my day (or my summer) being able to contribute to such a project. Since I have no experience with llvm besides some basic usage of clang, the first thing I tried was to find out what llvm tools are out there.

Hey everyone, Sorry to jump in on this so late. My two cents is that it should remain GNU objoppy compatible most likely. It was always vaguely a desire to have command line compatibility but it has turned out over time that this is actually a crucial feature and should be one of the top priorities. You can't just go into a giant build system and swap out all the uses of GNU objcopy with

...;<div dir="auto">Cheers,</div><div dir="auto"><br></div><div dir="auto">John</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Dec 30, 2018 6:09 PM, Jake Ehrlich <jakehehrlich@google.com> wrote:<br type="attribution" /><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Some patches have landed and several are up for review but there's nothing 100% working where you can use it to...