Re: [Elftoolchain-developers] Multiple archs and platforms.

[Chris J. <ch...@rt...>]

On 23/11/11 4:18 PM, Joseph Koshy wrote:
>> I am developing a linker for the RTEMS project to support dynamic
>> loading. ... I am pleased to report there are no problems with the
>> testing I have done.
>
> That's great to know.
>

It is a nice package and seems to be working well. I plan to stress it a 
little more in the linker once I have the Windows port working.

>> You can find the RTEMS project at http://www.rtems.org/ and the linker's
>> code is: [snip]
>
> I will take a look.
>

Thanks.

>> Windows is a little more difficult to support. The couple of issues I
>> have so far are:
>
>> 1. Includes such as "#include<sys/errno.h>", and "#include
>> <sys/cdefs.h>" are not supported. I have worked around this issue with a
>> win32 specific include directory that maps to the standard headers in my
>> application.
>
> I lack clue about program development under Windows.
>

I am no expert, but given a need I will get something working. I have a 
need.

All the code compiles and builds under Windows with a small amount of 
help. This is a credit to the code base.

>> 2. There is no mmap call. I see:
>>
>>   LIBELF_F_RAWFILE_MALLOC | LIBELF_F_SPECIAL_FILE
>>
>> could be used but I am not sure about a couple of things. Does this read
>> the whole ELF file into memory ?
>
> Yes, the RAWFILE_MALLOC case will read the whole ELF object into
> memory.  The motivation for the code was to support reading of an ELF
> object from device files ("/dev/ksyms" in {Free,Net}BSD) and from
> streams (e.g., from sockets and pipes).  Such file descriptors usually
> do not support mmap() or seek(), so ELF object needs to be read in
> sequentially.
>
> One optimization for the RAWFILE_MALLOC case could be to have libelf
> read in portions of the ELF object "on demand".  That said, further
> study would be needed to determine the tradeoffs involved---IIRC the
> default layout puts the section header table at the very end of an ELF
> object, so use cases that access sections could end up reading the
> entire ELF object into memory, even if such an optmization were
> implemented.
>

I think we can avoid any need to mess with this code. See below.

>> Secondly, I really do not like the idea
>> of __WIN32__ all over the place. I can support "HAVE_CONFIG_H" and
>> "HAVE_MMAP" etc. How should I handle this ?
>
> IMHO, an ELFTC_HAVE_MMAP configuration option would be the way to go.
>

I played around and decided touching the code was not a great solution. 
Instead I have written a mmap/munmap pair of functions for Windows based 
on the Python code for the mmap module and I can read elf files without 
a problem on Windows. I do not know if the update code for writes works.

This means I can read an elf file created on MacOS using a m68k 
cross-compiler on Windows. I am happy with this. I have uploaded 
rtl-host-20111123.tar.bz2 with the Windows changes.

> FYI, I have created ticket #366 to track this item:
>
>    http://sourceforge.net/apps/trac/elftoolchain/ticket/366.
>

Thanks. Should I attach patches once I have them ?

Chris