Hi Yoshinori,

On 06/01/16 02:54, Yoshinori Sato wrote:
> On Mon, 04 Jan 2016 16:30:24 +0900,
> Greg Ungerer wrote:
>> On 31/12/15 09:55, Waldemar Brodkorb wrote:
>>> From: Yoshinori Sato <ys...@users.souceforge.jp>
>>>
>>> Signed-off-by: Yoshinori Sato <ys...@users.sourceforge.jp>
>>> Signed-off-by: Waldemar Brodkorb <w...@uclibc-ng.org>
>>> ---
>>>  flthdr.c |    8 ++++++++
>>>  1 file changed, 8 insertions(+)
>>>
>>> diff --git a/flthdr.c b/flthdr.c
>>> index 8a8b97c..0401e20 100644
>>> --- a/flthdr.c
>>> +++ b/flthdr.c
>>> @@ -167,8 +167,16 @@ process_file(const char *ifile, const char *ofile)
>>>                             r = ntohl(relocs[i]);
>>>                             raddr = flat_get_relocate_addr(r);
>>>                             printf("    %u\t0x%08lx (0x%08"PRIx32")\t", i, 
>>> r, raddr);
>>> +#if defined(TARGET_h8300)
>>> +                           raddr &= ~0x00000001;
>>> +#endif
>>>                             fseek_stream(&ifp, sizeof(old_hdr) + raddr, 
>>> SEEK_SET);
>>>                             fread_stream(&addr, sizeof(addr), 1, &ifp);
>>> +#if defined(TARGET_h8300)
>>> +                           addr = ntohl(addr);
>>> +                           if (r & 1)
>>> +                                   addr &= 0x00ffffff;
>>> +#endif
>>>                             printf("%"PRIx32"\n", addr);
>>>                     }
>>>  
>>
>> The current flthdr.c code is essentially arch clean at the
>> moment (no other #ifdef arch special cases). Is this change
>> really necessary?
> 
> Yes. Want fix it.
> Current code generate broken relocation information.
> So can't load.

I don't follow. What code generates broken relocation information?

The above modified code is only printing out the relocation
information. If whatever code generated it is wrong then
why not fix that?

I can see an argument for better checking - so that bad
relocs don't cause the seeking and printing out of wrong
information. That would be an improvement, and it wouldn't
be architecture dependent.

Regards
Greg


> I sent fix of latest master.
> 
>> Regards
>> Greg
>>
>>
> 

_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Reply via email to