Write new code?
May 6, 2009, 09:34 PM
#16
Evolving Member
Thread Starter
iTrader: (4)
Join Date: Apr 2008
Location: Germany
Posts: 186
Likes: 0
Received 0 Likes
on
0 Posts
can some one help me setting up a linux box with the kpit stuff or something else that works.
and show me the 5 magic commands?
i can't get the kpit to install on debian.
i don't know if its the windows machine or me, but i won't work either.
i have a linux box running, but now i'm lost.
and show me the 5 magic commands?
i can't get the kpit to install on debian.
i don't know if its the windows machine or me, but i won't work either.
i have a linux box running, but now i'm lost.
May 7, 2009, 05:17 AM
#17
I'm a Fedora guy, so I've been installing the KPIT tools via the supplied RPM; on Debian, the main thing I'd be checking is whether the glibc version you have is the one the KPIT tools are expecting. Run "ldd /path/to/gnush_v0901_elf/bin/sh-elf-as" (change that path to where you've installed the tools; on my system, it defaults to /usr/share/gnush_v0901_elf-1), and see if you see any "not found" messages, especially for the libc.so or libz.so lines, you've got a library mismatch, and will need to resolve it. On Fedora, we usually have "compat" packages, which package up old libraries that some programs need to function correctly, and I'd assume Debian has something similar.
For reference, the version of glibc that the KPIT tools are using on my system is 2.9 (/lib/libc.so.6). Depending on your version of Debian, you might have a newer or older version available. My version of zlib is 1.2.3 (/lib/libz.so.1).
On Windows...frankly, that was about the easiest install I've ever done; I can't really speak to why it might not have worked for you.
I think we need more information, in general: when you say "it won't work", what exactly do you mean? Screenshots, error messages, etc. would be very helpful.
For reference, the version of glibc that the KPIT tools are using on my system is 2.9 (/lib/libc.so.6). Depending on your version of Debian, you might have a newer or older version available. My version of zlib is 1.2.3 (/lib/libz.so.1).
On Windows...frankly, that was about the easiest install I've ever done; I can't really speak to why it might not have worked for you.
I think we need more information, in general: when you say "it won't work", what exactly do you mean? Screenshots, error messages, etc. would be very helpful.
May 7, 2009, 11:55 AM
#18
Evolving Member
Thread Starter
iTrader: (4)
Join Date: Apr 2008
Location: Germany
Posts: 186
Likes: 0
Received 0 Likes
on
0 Posts
1.)
ldd /path/to/gnush_v0901_elf/bin/sh-elf-as shows "not a dynamic executable"
if i try run sh-elf-as:
-bash: /usr/share/gnush_v0901_elf-1/bin/sh-elf-as: No such file or directory
i think it's the glibc thing. thats a part i never understood in linux.
2.) Windows kpit works now, but i get lots of errors about "pcrel to far"
Is KPIT working for a complete rom assembly or just for some parts?
If its working with some aditional scripts i think i go the windows way.
The pcrel_filter.sh only writes the same adress into the mov instructions.
Do i understand right:
for: mov.l @(0x1E0,pc), r10 ! [0000B778] = sub_400
I should change to:
mov.l (loc_B778), r10
ldd /path/to/gnush_v0901_elf/bin/sh-elf-as shows "not a dynamic executable"
if i try run sh-elf-as:
-bash: /usr/share/gnush_v0901_elf-1/bin/sh-elf-as: No such file or directory
i think it's the glibc thing. thats a part i never understood in linux.
2.) Windows kpit works now, but i get lots of errors about "pcrel to far"
Is KPIT working for a complete rom assembly or just for some parts?
If its working with some aditional scripts i think i go the windows way.
The pcrel_filter.sh only writes the same adress into the mov instructions.
Do i understand right:
for: mov.l @(0x1E0,pc), r10 ! [0000B778] = sub_400
I should change to:
mov.l (loc_B778), r10
May 7, 2009, 01:41 PM
#19
Regarding #1: yep, sounds like a glibc mismatch. I actually meant for you to run "ldd /usr/share/gnush_v0901_elf-1/bin/sh-elf/as" (ie. replace "/path/to" with the actual path to your installation). That'll tell you what version of glibc you're looking for, and will give us a clue as to what package you'll need to install.
Regarding #2: "pcrel too far" is a problem I've fought with quite a bit, and it's "normal", for some demented version of normal. GNU as seems to have an off-by-one or off-by-two problem with the PC-relative references that IDA spits out; I'm not sure if it's binutils bug, or just me being stupid.
Which leads me to ask: are you trying to re-assemble the entire output from IDA? If so, you might want to look at the wiki development tips page; there's an sh and awk script called "pcrel_filter.sh" there that does a "pretty good" job of automatically converting PC-relative references into label-relative references, which gets you very close to something that can be assembled into a usable ROM.
If you're just getting started with this, though, I would strongly advise trying to get smaller chunks of code to build first.
Regarding #2: "pcrel too far" is a problem I've fought with quite a bit, and it's "normal", for some demented version of normal. GNU as seems to have an off-by-one or off-by-two problem with the PC-relative references that IDA spits out; I'm not sure if it's binutils bug, or just me being stupid.
Which leads me to ask: are you trying to re-assemble the entire output from IDA? If so, you might want to look at the wiki development tips page; there's an sh and awk script called "pcrel_filter.sh" there that does a "pretty good" job of automatically converting PC-relative references into label-relative references, which gets you very close to something that can be assembled into a usable ROM.
If you're just getting started with this, though, I would strongly advise trying to get smaller chunks of code to build first.
May 7, 2009, 02:18 PM
#21
Evolving Member
Thread Starter
iTrader: (4)
Join Date: Apr 2008
Location: Germany
Posts: 186
Likes: 0
Received 0 Likes
on
0 Posts
1.) i did replace the "path/to" the the real installation path.
I tried smaller code fragments, and they work.
now i only have to get it working on linux.
Code:
srv03:~# ldd /usr/share/gnush_v0901_elf-1/bin/sh-elf-as
not a dynamic executable
I tried smaller code fragments, and they work.
now i only have to get it working on linux.
May 7, 2009, 04:21 PM
#23
Evolving Member
Thread Starter
iTrader: (4)
Join Date: Apr 2008
Location: Germany
Posts: 186
Likes: 0
Received 0 Likes
on
0 Posts
i used rpm to install the rpm file. i tried alien didn't worked.
Code:
srv03:~# file /usr/share/gnush_v0901_elf-1/bin/sh-elf-as /usr/share/gnush_v0901_elf-1/bin/sh-elf-as: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped
May 7, 2009, 04:42 PM
#24
Okay, that looks fine; it looks like everything was installed fine, at least.
When you say it didn't work with alien, what specifically failed? If memory serves, alien tries to resolve the dependencies that your RPM has (ie. the right libc version), which means if your distribution didn't have the necessary libraries installed, it would have thrown up a few errors.
Architecture? "uname -a" I'm assuming you're not running a 64-bit distribution, but it's worth asking; you'd see similar behavior running 32-bit apps (like KPIT) on a 64-bit platform without the necessary 32-bit libraries installed.
What version of glibc? "ls /lib/libc.so*" should give you an idea (or "dpkg -l | grep glibc").
Actually, what version of Debian is this? I don't think you ever mentioned it above, and Lenny at the very least ought to have a recent version of libc6 available...
(Sorry for all the questions, I'm just happy to see another Linux guy around here.)
When you say it didn't work with alien, what specifically failed? If memory serves, alien tries to resolve the dependencies that your RPM has (ie. the right libc version), which means if your distribution didn't have the necessary libraries installed, it would have thrown up a few errors.
Architecture? "uname -a" I'm assuming you're not running a 64-bit distribution, but it's worth asking; you'd see similar behavior running 32-bit apps (like KPIT) on a 64-bit platform without the necessary 32-bit libraries installed.
What version of glibc? "ls /lib/libc.so*" should give you an idea (or "dpkg -l | grep glibc").
Actually, what version of Debian is this? I don't think you ever mentioned it above, and Lenny at the very least ought to have a recent version of libc6 available...
(Sorry for all the questions, I'm just happy to see another Linux guy around here.
)
May 7, 2009, 04:49 PM
#25
Evolving Member
Thread Starter
iTrader: (4)
Join Date: Apr 2008
Location: Germany
Posts: 186
Likes: 0
Received 0 Likes
on
0 Posts
alien:
Yes, its a amd64 platform.
It debian lenny, a xen guest on my webserver.
Code:
srv03:~# alien --to-deb --keep-version --scripts gnush_v0901_elf-1-1.i386.rpm
Package build failed. Here's the log:
dh_testdir
dh_testdir
dh_testroot
dh_clean -k -d
dh_installdirs
dh_installdocs
dh_installchangelogs
find . -maxdepth 1 -mindepth 1 -not -name debian -print0 | \
xargs -0 -r -i cp -a {} debian/gnush-v0901-elf
dh_compress
dh_makeshlibs
dh_installdeb
dh_shlibdeps
dpkg-shlibdeps: failure: couldn't find library libc.so.6 needed by debian/gnush- v0901-elf/usr/share/gnush_v0901_elf-1/bin/sh-elf-gcc (its RPATH is '').
Note: libraries are not searched in other binary packages that do not have any s hlibs or symbols file.
To help dpkg-shlibdeps find private libraries, you might need to set LD_LIBRARY_ PATH.
dh_shlibdeps: dpkg-shlibdeps returned exit code 2
make: [binary-arch] Error 1 (ignored)
dh_gencontrol
dpkg-gencontrol: error: current host architecture 'amd64' does not appear in pac kage's architecture list (i386)
dh_gencontrol: dpkg-gencontrol returned exit code 255
make: *** [binary-arch] Error 1
find: `gnush_v0901_elf-1': No such file or directory
srv03:~#
Code:
srv03:~# uname -a Linux srv03.die-allianzen.de 2.6.26-1-xen-amd64 #1 SMP Sat Jan 10 20:39:26 UTC 2009 x86_64 GNU/Linux
Code:
srv03:~# dpkg -l | grep glibc srv03:~# ls /lib/libc.so* /lib/libc.so.6 srv03:~#
May 7, 2009, 05:08 PM
#27
Evolving Member
Thread Starter
iTrader: (4)
Join Date: Apr 2008
Location: Germany
Posts: 186
Likes: 0
Received 0 Likes
on
0 Posts
great on step further. :-) but new error.
Code:
srv03:~# alien --to-deb --keep-version --scripts gnush_v0901_elf-1-1.i386.rpm
Package build failed. Here's the log:
dh_testdir
dh_testdir
dh_testroot
dh_clean -k -d
dh_installdirs
dh_installdocs
dh_installchangelogs
find . -maxdepth 1 -mindepth 1 -not -name debian -print0 | \
xargs -0 -r -i cp -a {} debian/gnush-v0901-elf
dh_compress
dh_makeshlibs
dh_installdeb
dh_shlibdeps
dpkg-shlibdeps: warning: dependency on libnsl.so.1 could be avoided if "debian/gnush-v0901-elf/usr/share/gnush_v0901_elf-1/bin/sh-elf-run" were not uselessly linked against it (they use none of its symbols).
dh_gencontrol
dpkg-gencontrol: error: current host architecture 'amd64' does not appear in package's architecture list (i386)
dh_gencontrol: dpkg-gencontrol returned exit code 255
make: *** [binary-arch] Error 1
find: `gnush_v0901_elf-1': No such file or directory
srv03:~# apt-get install libnsl
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Couldn't find package libnsl
srv03:~#
May 7, 2009, 05:20 PM
#29
Evolving Member
Thread Starter
iTrader: (4)
Join Date: Apr 2008
Location: Germany
Posts: 186
Likes: 0
Received 0 Likes
on
0 Posts
No, i didn't.
But now it seems to work. No errors running sh-elf-as.
Thank you very much giving me a hand. I'm not good at the linux thing, when it comes to errors.
But now it seems to work. No errors running sh-elf-as.
Thank you very much giving me a hand. I'm not good at the linux thing, when it comes to errors.
