www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Reading ELF Files

reply =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= <per.nordlow gmail.com> writes:
Have anybody put together some D code for reading out tables from 
ELF files?

A range/slice based version would be nice.
May 01 2014
next sibling parent "Tolga Cakiroglu" <tcak pcak.com> writes:
On Thursday, 1 May 2014 at 11:38:50 UTC, Nordlöw wrote:

 Have anybody put together some D code for reading out tables 
 from ELF files?

 A range/slice based version would be nice.


I don't know this though, in the morning Ubuntu has showed 
updates. One of them was "libelf" which says in its description 
it is used to read and write ELF files. Writing a wrapper class 
for this could be useful.
May 01 2014
prev sibling parent reply "yazd" <yazan.dabain gmail.com> writes:
On Thursday, 1 May 2014 at 11:38:50 UTC, Nordlöw wrote:

 Have anybody put together some D code for reading out tables 
 from ELF files?

 A range/slice based version would be nice.


I have some simple proof of concept code. It is currently able to 
read elf64 (can be easily adjusted to read elf32 too) headers, 
extract sections and read string tables. If this is what you 
need, then I'll upload my code somewhere (although again, it is 
quite simplistic). If you specify what you need a bit more, I 
might be able to provide that.
May 01 2014
next sibling parent =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= <per.nordlow gmail.com> writes:
 I have some simple proof of concept code. It is currently able 
 to read elf64 (can be easily adjusted to read elf32 too) 
 headers, extract sections and read string tables. If this is 
 what you need, then I'll upload my code somewhere (although 
 again, it is quite simplistic). If you specify what you need a 
 bit more, I might be able to provide that.


Seems nice.

I need this for my file scanning/indexing engine, where I 
currently want to extend it to index object file symbols.
May 01 2014
prev sibling parent reply =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= <per.nordlow gmail.com> writes:
 again, it is quite simplistic). If you specify what you need a 
 bit more, I might be able to provide that.


Please, post :)
May 01 2014
parent reply "yazd" <yazan.dabain gmail.com> writes:
On Thursday, 1 May 2014 at 13:10:33 UTC, Nordlöw wrote:

 again, it is quite simplistic). If you specify what you need a 
 bit more, I might be able to provide that.


 Please, post :)


Here you go, https://github.com/yazd/elf-d.
May 01 2014
parent reply =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= <per.nordlow gmail.com> writes:
 Here you go, https://github.com/yazd/elf-d.


Thanks!
May 01 2014
parent reply "yazd" <yazan.dabain gmail.com> writes:
On Thursday, 1 May 2014 at 17:31:52 UTC, Nordlöw wrote:

 Here you go, https://github.com/yazd/elf-d.


 Thanks!


Anytime. By the way, if you need more stuff out of it or help, 
post an issue on github. I think I'll be able to help a bit more. 
But if this library is to move forward, the API will need a 
redesign. You might want to keep that in mind.
May 02 2014
parent reply =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= <per.nordlow gmail.com> writes:
On Friday, 2 May 2014 at 10:42:40 UTC, yazd wrote:

 On Thursday, 1 May 2014 at 17:31:52 UTC, Nordlöw wrote:

 Here you go, https://github.com/yazd/elf-d.


 Thanks!


 Anytime. By the way, if you need more stuff out of it or help, 
 post an issue on github. I think I'll be able to help a bit 
 more. But if this library is to move forward, the API will need 
 a redesign. You might want to keep that in mind.


Ok. Great!

Some reflections:

- This is not a robust way of detecting limitations of the 
package (elf.d):

     static assert(is(size_t == ulong), "only 64bit is supported 
for now");

This static assert needs to be called at run-time on the header 
contents of the mmapped file itself.

- It is nice that you use MMFile. I do that too in my engine. 
However, to make cooperation more flexible and efficient class 
ELF should provide a ctor that takes and existing MMfile as 
argument (refernce) during construction, since my file engine 
class RegFile temporarily creates such instances when neeeded. 
BTW: What does package keyword mean in the line

   package MmFile file;
inside the definition of ELF.

For detail see for example:

https://github.com/nordlow/justd/blob/master/fs.d#L1192
May 02 2014
parent reply "yazd" <yazan.dabain gmail.com> writes:
On Friday, 2 May 2014 at 15:25:55 UTC, Nordlöw wrote:

 On Friday, 2 May 2014 at 10:42:40 UTC, yazd wrote:

 On Thursday, 1 May 2014 at 17:31:52 UTC, Nordlöw wrote:

 Here you go, https://github.com/yazd/elf-d.


 Thanks!


 Anytime. By the way, if you need more stuff out of it or help, 
 post an issue on github. I think I'll be able to help a bit 
 more. But if this library is to move forward, the API will 
 need a redesign. You might want to keep that in mind.


 Ok. Great!

 Some reflections:

 - This is not a robust way of detecting limitations of the 
 package (elf.d):

     static assert(is(size_t == ulong), "only 64bit is supported 
 for now");

 This static assert needs to be called at run-time on the header 
 contents of the mmapped file itself.

 - It is nice that you use MMFile. I do that too in my engine. 
 However, to make cooperation more flexible and efficient class 
 ELF should provide a ctor that takes and existing MMfile as 
 argument (refernce) during construction, since my file engine 
 class RegFile temporarily creates such instances when neeeded. 
 BTW: What does package keyword mean in the line

   package MmFile file;
 inside the definition of ELF.

 For detail see for example:

 https://github.com/nordlow/justd/blob/master/fs.d#L1192


You're correct in terms of the check. Anyway, I have just pushed 
some changes to support both 32bit and 64bit elf binary files. 
That required minor changes in the API, but it should still be 
easy.
And I've added a constructor that takes an MmFile.

`package` here is a protection attribute. From the documentation 
on dlang.org, " Package extends private so that package members 
can be accessed from code in other modules that are in the same 
package. This applies to the innermost package only, if a module 
is in nested packages."
May 04 2014
next sibling parent =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= <per.nordlow gmail.com> writes:
On Sunday, 4 May 2014 at 18:11:45 UTC, yazd wrote:

 On Friday, 2 May 2014 at 15:25:55 UTC, Nordlöw wrote:

 On Friday, 2 May 2014 at 10:42:40 UTC, yazd wrote:

 On Thursday, 1 May 2014 at 17:31:52 UTC, Nordlöw wrote:

 Here you go, https://github.com/yazd/elf-d.


 Thanks!


 Anytime. By the way, if you need more stuff out of it or 
 help, post an issue on github. I think I'll be able to help a 
 bit more. But if this library is to move forward, the API 
 will need a redesign. You might want to keep that in mind.


 Ok. Great!

 Some reflections:

 - This is not a robust way of detecting limitations of the 
 package (elf.d):

    static assert(is(size_t == ulong), "only 64bit is supported 
 for now");

 This static assert needs to be called at run-time on the 
 header contents of the mmapped file itself.

 - It is nice that you use MMFile. I do that too in my engine. 
 However, to make cooperation more flexible and efficient class 
 ELF should provide a ctor that takes and existing MMfile as 
 argument (refernce) during construction, since my file engine 
 class RegFile temporarily creates such instances when neeeded. 
 BTW: What does package keyword mean in the line

  package MmFile file;
 inside the definition of ELF.

 For detail see for example:

 https://github.com/nordlow/justd/blob/master/fs.d#L1192


 You're correct in terms of the check. Anyway, I have just 
 pushed some changes to support both 32bit and 64bit elf binary 
 files. That required minor changes in the API, but it should 
 still be easy.
 And I've added a constructor that takes an MmFile.

 `package` here is a protection attribute. From the 
 documentation on dlang.org, " Package extends private so that 
 package members can be accessed from code in other modules that 
 are in the same package. This applies to the innermost package 
 only, if a module is in nested packages."


Ok. Thx!
May 04 2014
prev sibling parent reply =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= <per.nordlow gmail.com> writes:
On Sunday, 4 May 2014 at 18:11:45 UTC, yazd wrote:

 On Friday, 2 May 2014 at 15:25:55 UTC, Nordlöw wrote:

 On Friday, 2 May 2014 at 10:42:40 UTC, yazd wrote:

 On Thursday, 1 May 2014 at 17:31:52 UTC, Nordlöw wrote:

 Here you go, https://github.com/yazd/elf-d.


 Thanks!


 Anytime. By the way, if you need more stuff out of it or 
 help, post an issue on github. I think I'll be able to help a 
 bit more. But if this library is to move forward, the API 
 will need a redesign. You might want to keep that in mind.


 Ok. Great!

 Some reflections:

 - This is not a robust way of detecting limitations of the 
 package (elf.d):

    static assert(is(size_t == ulong), "only 64bit is supported 
 for now");

 This static assert needs to be called at run-time on the 
 header contents of the mmapped file itself.

 - It is nice that you use MMFile. I do that too in my engine. 
 However, to make cooperation more flexible and efficient class 
 ELF should provide a ctor that takes and existing MMfile as 
 argument (refernce) during construction, since my file engine 
 class RegFile temporarily creates such instances when neeeded. 
 BTW: What does package keyword mean in the line

  package MmFile file;
 inside the definition of ELF.

 For detail see for example:

 https://github.com/nordlow/justd/blob/master/fs.d#L1192


 You're correct in terms of the check. Anyway, I have just 
 pushed some changes to support both 32bit and 64bit elf binary 
 files. That required minor changes in the API, but it should 
 still be easy.
 And I've added a constructor that takes an MmFile.

 `package` here is a protection attribute. From the 
 documentation on dlang.org, " Package extends private so that 
 package members can be accessed from code in other modules that 
 are in the same package. This applies to the innermost package 
 only, if a module is in nested packages."


Great work!

One thing though: You cannot call a filename the same as a 
keyword: package.d because

import elf.package;

fails with

fs.d(144,12): Error: identifier expected following package

Thx for the other fixes.
May 05 2014
parent reply Mike Parker <aldacron gmail.com> writes:
On 5/5/2014 8:17 PM, "Nordlöw" wrote:

 One thing though: You cannot call a filename the same as a keyword:
 package.d because

 import elf.package;

 fails with

 fs.d(144,12): Error: identifier expected following package


Actually, package.d is a feature which was added not so long ago. Given:

- foo
-- bar.d
-- baz.d
-- package.d

Where package.d looks like:

module foo.package;
public import foo.bar, foo.baz;

In client code, you can do this:

import foo;

And all of foo.bar and foo.baz will be visible. But you are correct that 
one cannot explicitly import 'foo.package'
May 05 2014
parent =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= <per.nordlow gmail.com> writes:
On Monday, 5 May 2014 at 13:51:12 UTC, Mike Parker wrote:

 On 5/5/2014 8:17 PM, "Nordlöw" wrote:

 One thing though: You cannot call a filename the same as a 
 keyword:
 package.d because

 import elf.package;

 fails with

 fs.d(144,12): Error: identifier expected following package


 Actually, package.d is a feature which was added not so long 
 ago. Given:

 - foo
 -- bar.d
 -- baz.d
 -- package.d

 Where package.d looks like:

 module foo.package;
 public import foo.bar, foo.baz;

 In client code, you can do this:

 import foo;

 And all of foo.bar and foo.baz will be visible. But you are 
 correct that one cannot explicitly import 'foo.package'


Aha!

Thx
May 05 2014