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

["Eric Schulte" <schulte dot eric at gmail dot com>]

Alan Modra <amodra@gmail.com> writes:

> On Mon, Mar 28, 2011 at 04:42:06PM -0600, Eric Schulte wrote:
>> 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.
>
> Right.
>

It's hard to know exactly what the limits of tools like bfd are, but I
expect there is no programmatic support for changing these addresses
embedded in the compiled code.

>
>> 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.
>
> You will also need to update pointers in initialized data, dynamic
> relocations, .got, .plt etc.  Basically you need to do everything that
> the linker does..
>

Yes, and I imagine this is much more difficult (probably not possible)
than the job done by the linker, because in already-compiled code it is
not clear which constants are data and which are memory addresses.

>
>> Any suggestions for ways around the need to change addresses embedded in
>> compiled code?
>
> There is no way to avoid it, except preallocating space at link time
> for your code patches.  Tools like IBM's FDPRPro use ld -q, so you
> have relocations to work with.  However, ld -q isn't well supported on
> many targets.  For example, x86 does not update the emitted relocs to
> suit edited TLS code sequences.

Thanks for your replies.  It is very useful to have feedback on what is
and is not possible with existing tools.  I've found this sort of
information hard to come by on the internet, and hard to verify
personally outside of grabbing libraries like libelf and binutils and
reading their source.

I think for now I'll have to limit myself to updating the structures of
the elf file, and leave code changes to other tools.

Many Thanks -- Eric