maria-developers team mailing list archive

[Sylvain Raybaud <sylvain.raybaud@xxxxxxxxxxxxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi! I'm finally working on this again.

On 14/08/2014 14:48, Sergei Golubchik wrote:
>> It seems that STACK_DIRECTION is not automatically determined
>> when
>>> cross-compiling. I may determine the correct value for a given
>>> target. But if I need a portable solution (and I need one in
>>> order to create a buildroot package so that I can build for
>>> many different target without too much hassle) I'm not sure
>>> what my options are. It seems that the toolchain is aware of
>>> this value since stack direction (or more precisely
>>> STACK_GROWS_DOWNWARD) is set in 
>>> ./output/host/opt/ext-toolchain/lib/gcc/arm-none-linux-gnueabi/4.8.1/plugin/include/config/arm/arm.h
>>
>>> 
> Maybe there is a way to use this somehow? What do you think? May
> be... These files are for building gcc plugins. How do I get to
> this STACK_GROWS_DOWNWARD? And what if it's not defined or the file
> doesn't exist?
> 

After discussing this issue with the buildroot community it seems that
it's not a good idea to try to use this file, at least with buildroot.
Since most modern architectures have a stack that grows down. The only
exception I know of is PA-RISC and it seems it's not supported by
buildroot. Therefore I'll juste hardcode the correct value (-1). I'm
sorry I can't propose a better solution :(

However I've read here and there (for example [1]) that trying to
determine to automatically determine the stack direction wasn't too
reliable... So really, I don't know, but maybe this value should be
harcoded? For example in an lsit of pairs (arch,stack_direction)?

[1]
http://stackoverflow.com/questions/664744/what-is-the-direction-of-stack-growth-in-most-modern-systems

Regards,

- -- 
Sylvain Raybaud
www.green-communications.fr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJUPQ7nAAoJEEkkwl4JtJ9ygQkP/1wifqn7zQdByOvr+RTejfhS
fYBIxgZ/HTfZAM0RpaIaJdcuTtfU++ITWr9NFQ/V/PNvSququ6NzRgTD2w5D+2ob
nSj60uSCWDFkpwyMMQEhei9tZRZiMj+uaLCULkWDJwvsVLZ89uxGzOeW0YtFRAAA
NStD1BPv8QzksRftDVZ/sLcImlhLvy+TsFrht8Ol48gOdQAtkWRVBu4FSUS0kyEF
sXm12Ms9fr3bQyCkfm0FaWzUdrSvT74Mag6j2cbNB9pPRGzX3+I+mj4tTYHEqKx1
agK/hokFFFtEtPrYHo2aBVXy7TqoUg7Ra2kI5Vum9aJFnhdOBmxFzBKCKL/AdbeH
s0B9X1WX6vYCN3o18EhUKJvun9yBtxDVVySxsMc/JWFU+UNqYsQe1eMm9r0qCpJQ
6CLff/NsNlNAjiBfDkR+SR0aUaMP6hYNBMb0O6u5W2LQhvlF0T42XYtlRqrnYsHn
Ye8IDDMesmheSt5r4FpmZWANqcpiSw+/ZSucIc5qP9wRlSVj50n9r3vvZ48a13Pq
qEaC6g/rZbQo++dXRMa8CbRxefSrYaZqwMJVXO3S/nvulPeQAu86iVISh3dcGl8Q
D9kvC5owyW54psKcE34XgTQ+Bfb7/2Ij1dZ/0QTZSEqX0HW0WcLWD25zyWsRDJVp
L9bwOtcNyAu2HYfpwOqx
=FDe0
-----END PGP SIGNATURE-----