binary blob conversions/other blob questions

[Michael Hennebry]

On Fri, 20 Feb 2009, Sergey Lapin wrote:

>> If it can be done, I think it can be done with --wrap.
>> That said, it might not be possible:
>> External_fred:
>>    ...
>>    ; don't return yet
>> External_greg:
>>    ...
>>    RET
>> Overriding one without overriding the other might be difficult.
>> Can you ascertain whether there are external
>> references not preceeded by returns?
>> It's even worse if someone does arithmetic on code addresses.
> Well, as this blob was generated from 100% C, using gcc-3.2 for MIPS,
> with simple -O2 options, I hope, there will not be such thing,
> and disassembly found no such problems. And there's no
> arithmetics on code addresses.
>
> So I persist with the same questions. --wrap option requires a symbol as
> argument, which means I have to put lots of stuff on a command line
> which might not be an options in case of big numbers of symbols.

You can put them in a separate file:
ld options @option_file more_options @another_option_file ...

> Well, I think I need to provide more detail.
> Lets suppose, we have blob.o we work with, which implements network
> interface as it were in 2.4.17 kernel, and we want to run it on 2.6
> with API changes. Without much digging around, lets suppose we need to
> wrap structure from some function and provide it to some other function.
> so we have in our .o
> T driver_func
> t driver_func2
> U api_func

If driver_func2 is static in blob.o,
put driver_func2 in globalizees.txt and run blob.o through objcopy:
objcopy --globalize-symbols=globalizees.txt blob.o new_blob.o
If there is already a global driver_func2,
you will need to use objcopy's --redefine-syms first.
If there is more than one static driver_func2,
I don't know what you should do.

Name your own function __wrap_driver_func.
It should not be static.
Refer to the blob version as __real_func.

> For now I need to replace driver_func2, which is executed by driver_func
> by my own code, which uses newer API with structure format changed,
> which then converts this struct back for other binary module parts to
> use, and then call (optionally) call older version of function until it
> is rewritten fully. Is there some options on how to achieve this to a
> few hundreds of global and static functions so that at any step of
> conversion I could check that I did not break anything?
>
> So, as it is being done, I add additional module wrapper.o and rename
> functions in blob.o. But a problem is still there with static functions,
> how do these to be handled for them to be replaced? Especially in case
> when I need to delete it and write version which entirely sits in
> wrapper.o, so in separate .o. Is it will guarantee that there will be no
> references left somewhere for old version (all function names are in
> symbol table and they are called either directly or over function
> pointers (which are directly assigned without calculations).

-- 
Michael   hennebry@web.cs.ndsu.NoDak.edu
"Pessimist: The glass is half empty.
Optimist:   The glass is half full.
Engineer:   The glass is twice as big as it needs to be."