Mike wrote:
The oggplay relies on fork() (superficially if you ask me) and does not
It isn't quite so superficial. The fork is there so that when playing multiple
tracks things don't get clagged up. Was easier doing this than tracking down
all the state destruction and rectifying it. If
Mike wrote:
btw, please dont take this the wrong way. i imagine oggplay does all the
crazy things you say it does, but we just wanted to validate that the tremor
decoding library worked (download an ogg and listen to it on the board). so
everything beyond that is cheese to us ;).
I
Martin Voss wrote:
Any recommendation on how to do this or to profile the actual stack
usage some other way are very welcome.
If you're using uc-libc (new-wave/lib/libc) have a look in misc/probe_stack.c
for some magic code that stuffs the stack full of a magic number and installs
an atexit
Gavin wrote:
The other thing that frequently helps is to disable PIC code, which can be
done by disabling XIP and shared libraries in the vendor config file,
followed by a clean rebuild. Basically you need to make sure that the
resulting binary doesn't have the Has-PIC-GOT flag (according to
Sean wrote:
So which is it? A link script issue or a loader issue? I am hoping this
is just a matter of getting my compiler flags setup correctly and
matching the options used to build the libraries. Building for a flat
memory model seems a bit tricky.
The bug is in the loader - kind of.
What does BINFMT_FLAT: reloc outside program mean, and how do I fix
it?
It means pretty much what it says. A relocation is pointing out program text
and data areas and the kernel is erroring out over it.
The fix is to remove this test from the binfmt_flat loader, it is possible to
have
So basically you're saying C++ works fine, provided that simple test
is removed from the kernel, is that right?
Nope. The message will disappear if the test is removed :-) And if you
*must* get something going that produces this message, this is the first step
along a long and painful path
It seems that the flat loader is pushing some frames(?) onto the stack
for some library initialization. Is this correct? I am a little bit lost
tracking down where this Illegal Instruction is occuring. Any help on
this and the remainder of the file load process will be greatly
appreciated.
John Williams wrote:
At first thought the bare essentials are probably
* 32 bit data path
* hardware interrupt (for the timer)
* and GCC support.
I'd have thought that the first of these wasn't an essential concern re:
getting uClinux going. GCC supports 32 bit types for its
I missed your initial message. I did the m68k shared library work so I ought
to understand this, although it was quite a few years ago now and memory
fades...
My earlier understanding was incorrect. The problem (so far) is not in
the GOT. It is definitely in the relocation table.
[...]
I
10 matches
Mail list logo
