[Libre-soc-bugs] [Bug 1169] Add ELF and mmap support to ISACaller -- no dynamic linking

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=1169

--- Comment #12 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Dmitry Selyutin from bug #981 comment #8)
> (In reply to Jacob Lifshay from comment #7)
> > (In reply to Dmitry Selyutin from comment #6)
> > > Deal?
> > 
> > ok with me
> > 
> > > I'd say it fits bug #982.
> > 
> > i was thinking #982 would only end up with a few syscalls implemented since
> > luke was advocating for just open/openat, close, exit, read, and write (or
> > something), so the additional budget here would allow implementing a lot
> > more.
> 
> mmap. This is a blocker. It needs to be done. Plus free pages list,
> basically a trivial allocator.

yeah, it's part of bug #1169. I have implemented simple memory allocators
before, we don't need anything all that complex.
>  
> > > I don't expect much to be done there; also parts
> > > of it fit ELF support which I, frankly speaking, find to be underrated.
> > 
> > what do you mean by underrated? that the 1900 EUR estimate is too big? that
> > it's too small? something else?
> 
> Too small, rationale below.

yeah, I tried to make the budget smaller before i looked at how much is
available. I will probably re-estimate to around eur 3000 since i forgot a few
things like setting up auxv and stuff.
> 
> > keep in mind there is 6000 eur available in the ELF task's budget parent and
> > since the statically-linked ELF task is too small I want to add
> > dynamically-linked executable support as a separate task and implement more
> > syscalls ... if there's not enough work to take up the 2mo of funds then
> > I'll add more.
> 
> I expect several problems there. First of all, you'll have to implement mmap
> support, and this includes introducing something like a free list for
> bookkeeping the memory allocations, even if these are backed just by the big
> mapping.

yup, i was expecting that (though i might use something different than a
free-list), hence why this bug is both ELF *and* mmap.

> Second, you'll have to support different sections differently, not
> just "parse and map at fixed offset".

implementing LOAD program headers isn't too difficult. the kernel ignores
sections entirely and just follows the program headers.

> Third, I expect some challenges in
> ISACaller

I'm expecting bug #982 to have handled the issue of enabling/disabling syscall
emulation.

I already figured out replacing the simulated memory with the mmap-ped block
and luke verified in bug #982 comment 65 that i don't have to worry about
needing to pretend to be a dict too.

> and a learning curve with pyelf (if we take it; if not, this is
> even worse).

luckily there's readelf.py that already displays basically everything we need:
https://github.com/eliben/pyelftools/blob/cf814b7adaebb0d336e863d834964b3f4b4e48e1/scripts/readelf.py#L322

> I'd say with all the stuff I mentioned it's already no less
> than 4-5K. But, as I said, it's up to task owner to rate it budget-wise, I'm
> just expressing my considerations.
> 
> And, since you mentioned dynamic linkage. I expect it to be damn hard and
> time-nsuming based on my experience with relocations. Most of the task will
> be reading ELF and architecture specs. The code size won't be that huge; but
> the amount of time will... Again, your estimations might be different.

well, based on my testing, the kernel doesn't actually need to process any
relocations for dynamically-linked executables... see comment #11

the dynamic linker is what processes all the relocations for dynamically-linked
executables from what i can tell, which makes it really easy since we just load
ld.so and it does all the work for us.

-- 
You are receiving this mail because:
You are on the CC list for the bug.