public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
* [ECOS] Eabi error or Compiler Bug?
@ 2016-03-02  8:36 Privat
  2016-03-02  9:25 ` Privat
  0 siblings, 1 reply; 2+ messages in thread
From: Privat @ 2016-03-02  8:36 UTC (permalink / raw)
  To: ecos-discuss, Max Seidenstücker

Hi Max, Hi Edwards,  hi everyone

i ve bumped into some strange behaviour again lately during some code
cleanup.
I can work around it, but i wondered if other before me ran into this
and wether this is UB, a compiler bug or something ecos specific.

My Compiler:
Im compiling under ubuntu 14.04 for the MPC5668x powerpc architecture
with ppc-eabi-gcc 4.8.2 toolchain (if i found the correct compiler there) .

The problem occurs when casting pointers to a smaller size;

Example:
cyg_uint32 testValue = 0x12345678;
cyg_uint8  *ptrToLowestByte;
cyg_uint32 *ptrToWholeValue;

ptrToLowestByte = (cyg_uint8 *) (&testValue);
ptrToWholeValue = (cyg_uint32 *) ptrToLowestByte;

I can work with the ptrToTheWholeValue as long i do not use any binary
operations with a diffrent size
For example

cyg_uint32 container32 = ((*ptrToWholeValue) & 0xFF00 0000)
will return valid Value into the corresponding 32uint container;

cyg_uint8 container8 = (cyg_uint8) ((ptrToWholeValue & 0xFF00 0000 ) >>
24);

However will not.
My assumption is that the endianess of the dereferenced Value is wrong,
a cast pointer does no longer point to the lowest byte, but to the
highest instead.
I worked around it by not using bitops that shift into a diffrently
sized variable from a pointer.

If requested i could upload some dissasembly.

I also experienced some problems using memcpy and strncpy, when using
casted down uint8* ptr to uint8 arrays
- where the values to copy where copyied in at a offset off the original
ptrs data type (uint32*).

This all may be perfectly normal behaviour and i m just lacking
experience- in that case i would be very glad for any explenation.
Anybody experienced something similar?
There seem to be some todos regarding assembly binary operations in the
vle.h still open.
Should i report this to the gnu or will i get trampled by a stampede?

Regards Pica






-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [ECOS] Eabi error or Compiler Bug?
  2016-03-02  8:36 [ECOS] Eabi error or Compiler Bug? Privat
@ 2016-03-02  9:25 ` Privat
  0 siblings, 0 replies; 2+ messages in thread
From: Privat @ 2016-03-02  9:25 UTC (permalink / raw)
  To: ecos-discuss

Sorry, wrong toolchain info:

Target: powerpc-eabi
Configured with: /home/test/src/toolchains/gcc/gcc-4.3.2/configure -v
--target=powerpc-eabi
--prefix=/home/test/build/toolchains/powerpc-eabi/tools --with-newlib
--with-gnu-as --with-gnu-ld --enable-languages=c,c++
--disable-__cxa_atexit --enable-threads
--with-bugurl=http://bugs.ecos.sourceware.org/
--with-pkgversion='eCosCentric GNU tools 4.3.2-sw'
--with-gmp=/opt/gmp-4.2.2 --with-mpfr=/opt/mpfr-2.3.0
Thread model: single
gcc version 4.3.2 (eCosCentric GNU tools 4.3.2-sw)


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2016-03-02  9:25 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-03-02  8:36 [ECOS] Eabi error or Compiler Bug? Privat
2016-03-02  9:25 ` Privat

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).