bFLT relocation problems when running busybox/uclibc

[Rick Garcia]

David McCullough wrote:
> Jivin Rick Garcia lays it down ...
>>     I'm attempting to run busybox compiled against uClibc in bFLT format 
>> - busybox starts up, the kernel does the relocation, but it appears to 
>> be incomplete.   During debug, I can observe it performing a few hundred 
>> relocations, but I can identify more than a few places where it's using 
>> an invalid non-relocated address, and these all seem to be internal 
>> uClibc symbols.  As far as I can tell, all the busybox symbols are 
>> correctly relocated.
>>     Are there any flags that need to be passed to the uClibc build to 
>> get it to work with flat binary format?  I'm using the -Wl,-elf2flt when 
>> building busybox, but I built uClibc without any extra flags - my 
>> understanding was that they wouldn't be necessary when building a 
>> library like uClibc - I can't even identify a point in the build where 
>> they might be used.  Anyone have any ideas what could be causing this?
> 
> It depends on how you have built your uClibc I guess.  Compare the build
> lines for each and check for differing "-m..." options.

     The only -m.. option is -msep_data.

> What kernel/arch/compilers are you using ?

     It's an m68k clone - kernel is uClinux 2.4.(30?), and the compiler 
is 3.4.4

> Also it's probably better to ask on the uClinux-dev list :-)

     Will do :)

     One question - are you aware of any way to verify that elf2flt has 
relocated all the relevant symbols in an image?  I know there isn't 
exactly a plethora of utilities for examining the bFLT format right now, 
but I need to find a way to check this.
     Right now, the flthdr is telling me that there are 322 relocations 
- the make output logs and some quick checks I slapped into the kernel 
agree, so I'll concede that that much is working.  But 322 relocations 
for a program like busybox?  Every example I've seen online has had 
something on the order of 3000 relocations.  I have a minimal config 
going, but still... that's not a lot of symbols.

> Cheers,
> Davidm
> 

Thanks,
Rick