runtime_loader error

[xspager]

I got this errot in runtime loader, calling a program compiled by me:

~/src/VisualBoyAdvance-1.7.2/src/sdl> ./VisualBoyAdvance
runtime_loader: unhandled pheader type 0x68003300
runtime_loader: Troubles parsing Program headers, numRegions = -2147483632

i had a lot of trouble to get VisualBoyAdvande to compile, but the link process don't emit any warning, so i suppose that the binnary is ok. As sugested by DeadYak i put here the output of

objdump -x VisualBoyAdvance

VisualBoyAdvance:     file format elf32-i386
VisualBoyAdvance
architecture: i386, flags 0x00000150:
HAS_SYMS, DYNAMIC, D_PAGED
start address 0x000128d4

Program Header:
    LOAD off    0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**12
         filesz 0x000f5684 memsz 0x000f5684 flags r-x
    LOAD off    0x000f5684 vaddr 0x000f6684 paddr 0x000f6684 align 2**12
         filesz 0x0000701c memsz 0x0010999c flags rw-
 DYNAMIC off    0x000f6f60 vaddr 0x000f7f60 paddr 0x000f7f60 align 2**2
         filesz 0x00000100 memsz 0x00000100 flags rw-

Dynamic Section:
  NEEDED      libSDL.so
  NEEDED      libpng.so
  NEEDED      libgame.so
  NEEDED      libmedia.so
  NEEDED      libGL.so
  NEEDED      libbe.so
  NEEDED      libdevice.so
  NEEDED      libtextencoding.so
  NEEDED      libz.so
  NEEDED      libnetwork.so
  NEEDED      libroot.so
  SYMBOLIC    0x0
  INIT        0x1204c
  FINI        0xedb10
  HASH        0x94
  STRTAB      0x81c4
  SYMTAB      0x2754
  STRSZ       0x6217
  SYMENT      0x10
  PLTGOT      0xf8060
  PLTRELSZ    0x3c0
  PLTREL      0x11
  JMPREL      0x11c8c
  REL         0xe3dc
  RELSZ       0x38b0
  RELENT      0x8
  RELCOUNT    0x70c

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .hash         000026c0  00000094  00000094  00000094  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  1 .dynsym       00005a70  00002754  00002754  00002754  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .dynstr       00006217  000081c4  000081c4  000081c4  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .rel.dyn      000038b0  0000e3dc  0000e3dc  0000e3dc  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .rel.plt      000003c0  00011c8c  00011c8c  00011c8c  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .init         0000001e  0001204c  0001204c  0001204c  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  6 .plt          00000790  0001206c  0001206c  0001206c  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  7 .text         000db310  00012800  00012800  00012800  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  8 .fini         00000019  000edb10  000edb10  000edb10  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  9 .rodata       00007b44  000edb40  000edb40  000edb40  2**5
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 10 .eh_frame     000018c4  000f6684  000f6684  000f5684  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 11 .ctors        00000010  000f7f48  000f7f48  000f6f48  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 12 .dtors        00000008  000f7f58  000f7f58  000f6f58  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 13 .dynamic      00000100  000f7f60  000f7f60  000f6f60  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 14 .got          00000d8c  000f8060  000f8060  000f7060  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 15 .data         000048a0  000f8e00  000f8e00  000f7e00  2**5
                  CONTENTS, ALLOC, LOAD, DATA
 16 .bss          00102980  000fd6a0  000fd6a0  000fc6a0  2**5
                  ALLOC
 17 .comment      000006c0  00000000  00000000  000fc6a0  2**0
                  CONTENTS, READONLY
 18 .debug_aranges 00000060  00000000  00000000  000fcd60  2**0
                  CONTENTS, READONLY, DEBUGGING
 19 .debug_pubnames 00000106  00000000  00000000  000fcdc0  2**0
                  CONTENTS, READONLY, DEBUGGING
 20 .debug_info   00002e0d  00000000  00000000  000fcec6  2**0
                  CONTENTS, READONLY, DEBUGGING
 21 .debug_abbrev 0000044c  00000000  00000000  000ffcd3  2**0
                  CONTENTS, READONLY, DEBUGGING
 22 .debug_line   00001932  00000000  00000000  0010011f  2**0
                  CONTENTS, READONLY, DEBUGGING

[anevilyak]

Update platform, we don't have an x64 rev at the moment.

[mmlr]

How did you compile the binary? What compiler were you using? When you say you had a lot of trouble compiling, what kind of trouble do you mean? This rather looks like an incorrectly built binary and not like a runtime loader issue.

[anevilyak]

That's why I had him objdump it, I would've assumed if it was incorrectly built somehow then objdump would've complained also, but it seems to have parsed all the program headers without any problems.

[mmlr]

That depends. The problem reported is that a certain program header was not understood (the negative value there translates to B_BAD_DATA and is returned in that case). So it is possible that there is a header that our runtime_loader doesn't support but objdump does. That's why I ask about the compiler version, as using our standard compilers this shouldn't happen.

Checking elf specs the range 0x60000000 to 0x6fffffff where the indicated header (0x68003300) falls into are "reserved for OS specific semantics". So it seems that this is a header that was put there intentionally when generating the binary. Probably this is specific to another OS but was not disabled when compiling for Haiku. Objdump either does not understand and therefore skip it or it ignores it as OS specific.

[xspager]

Replying to mmlr:

That depends. The problem reported is that a certain program header was not understood (the negative value there translates to B_BAD_DATA and is returned in that case). So it is possible that there is a header that our runtime_loader doesn't support but objdump does. That's why I ask about the compiler version, as using our standard compilers this shouldn't happen.

Checking elf specs the range 0x60000000 to 0x6fffffff where the indicated header (0x68003300) falls into are "reserved for OS specific semantics". So it seems that this is a header that was put there intentionally when generating the binary. Probably this is specific to another OS but was not disabled when compiling for Haiku. Objdump either does not understand and therefore skip it or it ignores it as OS specific.

mmlr, i use the default that is installed by the haiku build process (gcc version 2.95.3-haiku-080323)

i build the VisualBoyAdvance-1.7.2 using:

CXXFLAGS='-O0 -lnetwork' ./configure --build=i586-pc-beos --enable-c-core --without-mmx --disable-rpath --disable-sdltest --disable-profilings
make

i also build pkg-config and SDL myself, but i don't know if has something to do with

[axeld]

Can you provide the executable, or a link to it? (upload limit is 500K)

[xspager]

Replying to axeld:

Can you provide the executable, or a link to it? (upload limit is 500K)

yes

[scottmc]

If you need libsdl and pkg-config to test this out there's binaries of each posted at: ​http://ports.haiku-files.org/downloads

[axeld]

With the archive posted I get a different error, though:

runtime_loader: elf_resolve_symbol: found symbol 'debugger' in shared image but wrong type

I used libSDL.so from HaikuPorts above, but also the BeOS one doesn't change this.

[xspager]

Replying to axeld:

With the archive posted I get a different error, though:

runtime_loader: elf_resolve_symbol: found symbol 'debugger' in shared image but wrong type

I used libSDL.so from HaikuPorts above, but also the BeOS one doesn't change this.

axeld, it is why i build SDL myself.

In the Haiku gcc4+gcc2 i got a litlle diferent error message, runtime loader also say that had trouble realloking libbe.so too. In gcc2 i use SDL that i build myself, but in the gcc4+gcc2('cause of the lack of gcc. it is right?) i use the same SDL, from haikuports, too, and i get the unresovable symbol as with you, in Haiku gcc2 and in the mixed gcc4 using the Haikuport or bebits prebuid libSDL.

[axeld]

Since you already had to compile SDL yourself, I think there is just something wrong with your setup. I just have no idea what this could be.

[xspager]

Replying to axeld:

Since you already had to compile SDL yourself, I think there is just something wrong with your setup. I just have no idea what this could be.

may be, but i don't believe so, at least to SDL and pkg-config. I use this to both:

./configure --build=i586-pc-beos --prefix=/boot/home/config && make install

to VBA i got a lot of compilation error, so i try many configure flags options, until i found one that build.

CXXFLAGS='-O1 -lnetwork'  ./configure --build=i586-pc-beos --disable-sdltest --enable-c-core --disable-profiling --without-mmx && make

thanks for helping axeld! ;)

[bonefish]

Replying to xspager:

may be, but i don't believe so, at least to SDL and pkg-config. I use this to both:

./configure --build=i586-pc-beos --prefix=/boot/home/config && make install

While it might usually work --build=i586-pc-beos is not correct.

to VBA i got a lot of compilation error, so i try many configure flags options, until i found one that build.

CXXFLAGS='-O1 -lnetwork'  ./configure --build=i586-pc-beos --disable-sdltest --enable-c-core --disable-profiling --without-mmx && make

Unless I'm much mistaken CXXFLAGS are the C++ compilation flags. "-lnetwork" is a linker flag (LDFLAGS), though.

[xspager]

Replying to bonefish:

Replying to xspager:

may be, but i don't believe so, at least to SDL and pkg-config. I use this to both:

./configure --build=i586-pc-beos --prefix=/boot/home/config && make install

While it might usually work --build=i586-pc-beos is not correct.

someone on the #haiku give me this "cheat code" :D . what is the right bonefish?

to VBA i got a lot of compilation error, so i try many configure flags options, until i found one that build.

CXXFLAGS='-O1 -lnetwork'  ./configure --build=i586-pc-beos --disable-sdltest --enable-c-core --disable-profiling --without-mmx && make

Unless I'm much mistaken CXXFLAGS are the C++ compilation flags. "-lnetwork" is a linker flag (LDFLAGS), though.

yes, this could be the error... hum... but i did that 'cause ld warns about the lack of symbols, that i judge to be from this lib. when i include that there no warns.

[scottmc]

I have fixed the SDL patch on HaikuPorts: ​http://ports.haiku-files.org/browser/haikuports/trunk/media-libs/libsdl/SDL-1.2.13-haiku.diff To build SDL, grab the source, patch it then:

• cp /boot/home/config/share/libtool/config.guess build-scripts
• cp /boot/home/config/share/libtool/config.sub build-scripts
• cat $(aclocal --print-ac-dir)/libtool.m4 >> acinclude.m4
• libtoolize --force --copy
• aclocal
• automake
• autoconf
• ./configure --prefix=/boot/common
• make
• make install

To build the tests, cd test, then:

• autoconf
• ./configure
• make

Still might be an issue with opengl support, need to look into that further. See Haiku ticket #2196.

From: ​http://ports.haiku-files.org/wiki/media-libs/libsdl/1.2.13/1

Sounds like xspager is using a mixed gcc2-gcc4 haiku? I have not tested that out, so your mileage may vary.

[bonefish]

Replying to xspager:

Replying to bonefish:

Replying to xspager:

may be, but i don't believe so, at least to SDL and pkg-config. I use this to both:

./configure --build=i586-pc-beos --prefix=/boot/home/config && make install

While it might usually work --build=i586-pc-beos is not correct.

someone on the #haiku give me this "cheat code" :D . what is the right bonefish?

i586-pc-haiku describes our platform. Usually one should use the auto tools to replace config.{guess,sub}, so that one wouldn't even need to specify the platform. Aside from that there might be actual porting effort necessary to get the program working correctly.

[scottmc]

@xspager, Have you tried to repeat this with a recent Haiku build?

[scottmc]

I have added a task at HaikuPorts to try running a new build of VisualBoyAdvance to see if there is still an issue here. I suspect it's cleared up in newer SDL builds.

[pulkomandy]

Confirmed that current VisualBoyAdvance recipe results in a running executable.