[llvm-dev] Modifying objects with MC

Thu Aug 27 08:49:06 PDT 2015

> On Aug 26, 2015, at 8:33 PM, Sean Silva <chisophugis at gmail.com> wrote:
> 
> 
> 
> On Wed, Aug 26, 2015 at 7:07 PM, Jim Grosbach via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> A mutable interface to object files would be great to have but doesn't exist in any meaningful sense in LLVM today. David's hack and similar tricks are what's necessary right now.
> 
> I'd love to fix that as its a question that comes up not infrequently.
> 
> Unfortunately this is a pretty tough problem to do in any generality. Anything that isn't simply overwriting the contents of sections in the file can effectively require rewriting the entire file. One of my realizations when writing `yaml2obj -format=elf` was how intricately tied all the offsets are; if you search for every use of ContiguousBlobAccumulator::getOSAndAlignedOffset, essentially any or all of those will need to be edited when making any nontrivial modification of an ELF object file (and this isn't even considering e.g. PHDRS covering sections etc.).

Yep, exactly. It’s a crazy hard problem in the general case, without always even having a clear right answer to some questions. For example, if I’m inserting a few bytes into a function, do I want to find and update all of the relative branch offsets and other such things to account for the extra size? Depends on what I want.

I suspect we could build something far less than the general case that’d still be useful, though. Defining it in such a way that you get intelligent failures back when asking it to do something it can’t handle may still be tricky. There’s definitely reasons this hasn’t been done yet.

>  (there's a reason that most of this functionality is usually in a program called objCOPY; basically objcopy is a program that copies an object file in a semantic way (e.g. logically section by section or whatever); it then has some if's and for's sprinkled in at various key places to handle the various different options it has).
> 
> -- Sean Silva
>  
> 
> Sent from my iPhone
> 
> > On Aug 25, 2015, at 2:44 AM, David Chisnall via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> >
> >> On 25 Aug 2015, at 10:30, Simon Cook via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> >>
> >> I've been trying to write a tool that reads in an ELF file and modifies
> >> one section within that ELF file based on the data contained within
> >> another section. Using llvm-objdump as a template of how to read an
> >> object file, I've been able to read the latter section that tells me
> >> what to edit, but I haven't found a way to edit the former, as
> >> everything in the MCSection/ELFObjectFile/SectionRef classes seem to be
> >> read-only as far as section contents are concerned.
> >>
> >> The changes I would want to make don't change the size of any section,
> >> all I need to do is for example zero the first n bytes of .text whilst
> >> keeping the rest of the object the same. What would be the recommended
> >> approach to achieving this goal?
> >
> > I have a similar use case and would also be interested in an answer.  In the meantime, I have a horrible hack that may work for you.
> >
> > My current hack works because the returned StringRefs for the SymbolRef::getContents are within the range of the MemoryBuffer and so the offset relative to the memory buffer corresponds to the file offset and this offset can be used to write into the file directly.
> >
> > It’s a horrible hack though, and it would be nice to simply have a mutable memory buffer that can be written back to the file (or to a different file).
> >
> > David
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=BQIGaQ&c=eEvniauFctOgLOKGJOplqw&r=k9CvPunowVJLjY-2Ua_VyCOW6auehHN4cbqltF2kp_A&m=GczEuegfI8sGgibmqcHyOw0fHoAApuDIg-XPJ_y2K_Q&s=au_QoXAJpl_xH8RN_0W4DnzdE3-SZNPJNTAWagUlrbI&e= <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=BQIGaQ&c=eEvniauFctOgLOKGJOplqw&r=k9CvPunowVJLjY-2Ua_VyCOW6auehHN4cbqltF2kp_A&m=GczEuegfI8sGgibmqcHyOw0fHoAApuDIg-XPJ_y2K_Q&s=au_QoXAJpl_xH8RN_0W4DnzdE3-SZNPJNTAWagUlrbI&e=>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=BQMFaQ&c=eEvniauFctOgLOKGJOplqw&r=k9CvPunowVJLjY-2Ua_VyCOW6auehHN4cbqltF2kp_A&m=W4sqPtpYon2COCWXwfM1LmnkincVK9ZwGR_GIYPMw6M&s=_FO6tk7k9yRU8DRPBwhOksvKg5fNiCGcFBac0Kwhyy8&e=>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150827/a4f22016/attachment.html>