[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: newbie: trying to run ancient ELF 32-bit LSB executable on oBSD 3.3...



nicolas padilla <nicolaspadilla_(_at_)_yahoo_(_dot_)_com> writes:
> Message-ID: <20030705182802_(_dot_)_23259_(_dot_)_qmail_(_at_)_web80505_(_dot_)_mail_(_dot_)_yahoo_(_dot_)_com>
> Received: from [66.183.13.127]
> 	by web80505.mail.yahoo.com via HTTP; Sat, 05 Jul 2003 11:28:02 PDT
> Date: Sat, 5 Jul 2003 11:28:02 -0700 (PDT)
> From: nicolas padilla <nicolaspadilla_(_at_)_yahoo_(_dot_)_com>
> Subject: newbie: trying to run ancient ELF 32-bit LSB executable on oBSD 3.3...
> To: misc_(_at_)_openbsd_(_dot_)_org
> 
> hi there!
> 
> I am trying to run an ancient binary on OBSD 3.3. I
> was able to run it on 3.0 before and now that 3.3
> execs are elf, I just thought it was a no issue,
> however it doesn't work.
> 
> file pnserver
> > pnserver: ELF 32-bit LSB executable, Intel 80386,
> version 1, dynamically linked (uses shared libs),
> stripped
> 
> ./pserver
> Abort
> 
> I installed freebsd_lib, but still it didn't work...
> 
> Am I missing something? should I give up?
> 
> l8r,
> 
> nicopa

Probably your simplest solution would be to find source, rebuild it,
and run that.

ELF is "just" a load format.  To get run-time compatibility, you need
not just the load format, but a whole bunch more in terms of system
calls, supported library functions, "well-known" file names, & more.
Collectively, this is called an "ABI" (application binary interface).
The ability to run canned binary-only application software is mainly
important to the commercial software world, and it is there where you
find a whole bunch of standards organizations that will certify your
ABI against one or more standard tests (for a price) then give you
permission to use their particular registered trademark.

Since OpenBSD is mainly interested in security, not commercial
software, there is little reason to go for the certification.  In
general, the aim is to make openbsd generally standards compliant,
except where it gets in the way of security.  Between that and other
features issues, there are plenty of ways openbsd might manage to not
support some specific feature your software needs.

If you are still interested in this, you could treat this as a
debugging exercise.  You will need to brush up on your assembly
language debugging skills and tools.  Probably, to start with, you
would run this under "ktrace" -- that will tell you how far it got when
it died.  If the issue is missing files, such as lack of the required
ld.so run-time linker, you will get the filename from that, and you can
go look for support for that.  You can also use "strings" and
"objdump".  "strings" may give you interesting clues as to how it was
built; "objdump" can show structure of the ELF file.  If the file won't
load and it's not an ld.so issue, then it may be a more generic load
map issue -- there you'll have to look at the kernel to see if there's
some issue with the program header that the kernel does not like.  If
it fails in ld.so, or it gets past there and dies later, then you'll
need to use a debugger to look at what's happening.  If it's dying
inside ld.so, then you'll probably want to get source to that (if
possible) and you'll probably be learning much about its internal data
structures in any case.

				-Marcus Watts



Visit your host, monkey.org