This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Using bfd to change the .text section of an executable


Alan Modra <amodra@gmail.com> writes:

> On Wed, Mar 23, 2011 at 02:29:40PM -0600, Eric Schulte wrote:
>> However, any changes which change the size of the .text section (in this
>> case appending four noops to the end) the resulting file is no longer a
>> working executable but rather throws segfaults on execution.
>
> Not surprising.  I suspect you seriously underestimate how much work
> is required to change section VMAs in a final linked executable, and
> have it run afterwards.
>

Hmm, I'm beginning to understand how true your statement is.  I've since
gone back to my own lisp [1] elf parser.  It is now updating all
relevant program and section headers, as well as symbolic entries in the
.dynamic section when there is a change in the size/address of a
section.

Even with every part of the elf file updated appropriately, executables
will not run successfully without changes to the contents of the
compiled assembly code in progbits sections.

As far as I can tell, there is no way to automatically identify
addresses in compiled code, although I suppose it may be possible, as
opcodes does print symbol names on the relevant call lines.

Any suggestions for ways around the need to change addresses embedded in
compiled code?

>
>> After some investigation it appears that while bfd is updating the lma
>> address of all sections following the .text section in memory (as shown
>> in the bfd warnings printed in [1] when running my `copy' program, the
>> source code for which is included below in [2]) bfd is not making
>> similar adjustments to the vma field of these sections.
>> 
>> Is it possible to convince bfd to manage vma addresses for me?
>
> Nope.
>
>>  I've
>> tried setting the `user_set_vma' flag to 0 before making the copy, but
>> to no avail.  Also, attempts to set the vma field of these sections
>> manually before calling bfd_close don't have any effect on the resulting
>> output file.
>
> See objcopy --change-section-vma code.

I'll take a look at this, although I think I have all of the elf
structure (i.e., non-code) changes worked out.

Thanks -- Eric

Footnotes: 
[1]  http://gitweb.adaptive.cs.unm.edu/elf.git


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]