<mwalle>
btw was that optimized to a pure load word?
<larsc>
nope
<larsc>
on big endian systems be32_to_cpu is a noop
<larsc>
so we get the exact opposite of what we want. a le load
<larsc>
my arch/lm32 folder is getting smaller every day :)
<mwalle>
hehe
<mwalle>
btw, have anyone successfully created an initramfs?
<lekernel>
mwalle: btw do you have gcc patches to merge for bflt/fdpic?
<mwalle>
merge?
<lekernel>
yeah, you can simply use an ext2 image
<mwalle>
an ext2 image is a initrd not an initramfs :)
<lekernel>
did you have to modify things in gcc?
<mwalle>
lekernel: two things, bugfix config.gcc and remove fdpic support (for now!)
<mwalle>
mh and patch binutils to not generate fdpic binaries
<mwalle>
if everything works, i'll post my patches and the elf2flt port
<mwalle>
and the uclibc port
<lekernel>
i'll try to become a lm32 maintainer (unless you or larsc wants to do it). seems to be the only way to get the lm32 stuff to move
<mwalle>
feel free ;)
<lekernel>
there isn't even an entry in the MAINTAINERS file for lm32... pft
<kristianpaul>
are you maintaining own gcc vesion? can you put pathches in just one place so i can re-compile the gnu toolchain locally to be update with yours?
<mwalle>
kristianpaul: there is nothing working yet :)
<kristianpaul>
ah ok :-)
<kristianpaul>
rtems repo should be okay then
<mwalle>
the patches affect only linux btw
<kristianpaul>
but linux stabillity gets better then?
<kristianpaul>
what about libc?
<kristianpaul>
"RTEMS toolchain RPMs do not have the divider and sign extended multilib for the libc"
<larsc>
lekernel: if you become the new maintainer i expect you to fix all my problems :p
<lekernel>
I probably won't, but at least you could get your patches merged in 24 hours, which is already a lot given the current situation
<kristianpaul>
so... where is your repo? :-)
<mwalle>
flat loading works, relocation too, but the first syscall of the user binary jumps to nowhere at the end
<larsc>
at the end of the syscall?
<mwalle>
yes
<mwalle>
when it returns to userspace
<mwalle>
it seems that i messed up the syscall handler
<mwalle>
mh no, the ret in tty_ioctl jumps to nowhere
<larsc>
nowhere = random address outside of the kernel image?
<mwalle>
mhh i think qemu's syscall is broken
<larsc>
the lm32 scall emulation?
<mwalle>
doch nicht ;)
<mwalle>
there are two syscalls one from inside the kernel (kernel_execv) which is working, followed by a syscall from the userspace