memcpy auf ARM Cortex A9 & Linaro

[olpo (Gast)]

Hallo zusammen,


ich habe ein Programm, das memcpy verwendet.
Allerdings stuerzt das Programm ab, was, glaube ich, an "region overlap" 
bei der Funktion memcpy() liegt.

memcpy(80006e80, 80006e84, 4):

Da ein "region overlap" bei memcpy() zu Problemen fuehren kann, soll man 
wohl eher memmove() verwenden.
Ich habe ebenfalls gelesen, dass die meisten Prozessoren oder Compiler 
memcpy() wie memmove() behandeln, um solch ein Laufzeitfehler 
auszuschliessen.

Ich benutze einen ARM Cortex A9 und Linaro-gcc.
Hier wird leider nichts wegoptimiert und ich laufe ich den Fehler.

Ich habe hier legacy SW, die ich nur ungern veraendern moechte.

Weiss jmd ob ich Compiler-Flags setzen kann, die mir das Problem loesen?
Oder muss ich fuer diese Plattform den Code umschreiben?


DANKE!

[user (Gast)]

wie wäre es mit einem #define

#define memcpy memmove

oder beim gcc Aufruf

gcc -Dmemcpy=memmove

[Markus F. (mfro)]

Das Verhalten von memcpy() ist bei überlappenden Speicherbereichen 
tatsächlich undefiniert.

olpo schrieb:
> memcpy(80006e80, 80006e84, 4):

Hier kann ich allerdings beim besten Willen keine Überlappung erkennen - 
memmove() wird da nichts besser machen, würde ich mal unterstellen.

[PittyJ (Gast)]

Ich habe das hier mal auf einem ARM mit Linaro-Compiler getestet.

Das Programm macht exakt das, was es soll. Der memcpy() funktioniert. 
Die richtigen Bytes werden kopiert. Nichts stürzt ab.

Von daher glaube ich nicht an ein memcpy Problem. Zumal memcpy ja in 
tausenden Programmen benutzt wird.
Ich denke mehr, dein Problem liegt in den Zeilen, die du hier nicht 
gepostet hast.

[Markus F. (mfro)]

PittyJ schrieb:
> Das Programm macht exakt das, was es soll. Der memcpy() funktioniert.
> Die richtigen Bytes werden kopiert. Nichts stürzt ab.
>
Der einzige Unterschied zwischen memcpy() und memmove() ist der, daß 
Letzteres vor dem Kopieren auf Überlappung der Speicherbereiche prüft 
und entsprechend "aufwärts" oder "abwärts" kopiert, um sich nicht selbst 
die Quelle zu überschreiben.

Da hier nichts überlappt, macht es keinen Unterschied (außer, daß 
memmove() hier unnötigerweise ein klein wenig langsamer ist).

[(prx) A. K. (prx)]

Ich kann überdies auch keinen Grund erkennen, weshalb memcpy bei 
Überlappung die Grätsche machen sollte, so hier eine gewesen wäre. Es 
kommt bloss nicht unbedingt das raus, was man haben will.

[Markus F. (mfro)]

A. K. schrieb:
> Ich kann überdies auch keinen Grund erkennen, weshalb memcpy bei
> Überlappung die Grätsche machen sollte, so hier eine gewesen wäre. Es
> kommt bloss nicht unbedingt das raus, was man haben will.

Wenn wir schon dabei sind: manchmal bin ich mir nicht sicher, ob 
bestimmte Fragen wirklich so ernst gemeint sind, wie's auf den ersten 
Blick aussieht.

Ich persönlich käme beispielsweise nicht unbedingt (zumindest nicht auf 
einem 32-bit Dualcore) auf die Idee, ein - offensichtlich perfekt 
ausgerichtetes - int per memcpy() zu kopieren oder vielleicht doch 
lieber per memmove(), weil es sich ja selber überlappen könnte.

Ein einfaches

* (int *) 0x80006e80 = * (int *) 0x80006e84;

würde hier ohne große Diskussion dasselbe (richtige) tun, bloß viel 
schneller...

[Peter II (Gast)]

Markus F. schrieb:
> Ein einfaches
> * (int *) 0x80006e80 = * (int *) 0x80006e84;
>
> würde hier ohne große Diskussion dasselbe (richtige) tun, bloß viel
> schneller...

und da bist du dir sicher? Eventuell wird ja erst ins Register geladen, 
dann wieder an die neue stelle geschrieben.

beim memcopy kann es die cpu direkt im ram machen.

Ich finde memcopy hier besser und lesbarer.

[Markus F. (mfro)]

Lach! 8-)

Dann werde ich künftig keine direkten Zuweisungen in der Form

int i = 4711;

mehr machen (ist ja irgendwie auch viel zu einfach). Bloß noch:

int i;
const int c = 4711;

memcpy(&i, &c, sizeof(int));

Ist ja auch viel lesbarer. Wenn's hilft...

[Peter II (Gast)]

Markus F. schrieb:
> Lach! 8-)
>
> Dann werde ich künftig keine direkten Zuweisungen in der Form
> int i = 4711;
>
> mehr machen (ist ja irgendwie auch viel zu einfach). Bloß noch:
> int i;
> const int c = 4711;
>
> memcpy(&i, &c, sizeof(int));
>
> Ist ja auch viel lesbarer. Wenn's hilft...

einmal sind es variabel die schon im Register sind, einmal ist es nur 
RAM. Das ist der unterschied.

Außerdem würde memcpy auch auf 8 und 16bit cpus laufen, ohne das man 
etwas ändern muss.

[Markus F. (mfro)]

Wir kommen jetzt ein wenig ins philosophische. Ich bin kein 
ARM-Spezialist, aber wenn ich micht nicht ganz täusche, kennt die 
ARM-Plattform keine Addressierungsart memory-to-memory. Da ist immer ein 
Register beteiligt.

[Klaus W. (mfgkw)]

klar, daß memcpy auch nicht zaubern kann.
Besser als ein guter Compiler mit Codeoptimierung wird die Funktion 
nicht sein können...

[(prx) A. K. (prx)]

Peter II schrieb:
> beim memcopy kann es die cpu direkt im ram machen.

Nicht bei einem ARM. Mem->Mem hat der nicht.

Und bei x86 ist es eine hochkomplexe Angelegenheit, zu bestimmen, wann 
auf welchem Prozessor bei welcher Datenmenge welche Kopierversion 
schneller ist.

[(prx) A. K. (prx)]

Klaus Wachtler schrieb:
> Besser als ein guter Compiler mit Codeoptimierung wird die Funktion
> nicht sein können...

Es gibt ein paar Optimierungsmöglichkeiten, die einem Optimizer nicht so 
recht liegen, wie breite SIMD Register, Cache Optimierung, Prefetch etc.

[Rolf M. (rmagnus)]

Markus F. schrieb:
> Ich persönlich käme beispielsweise nicht unbedingt (zumindest nicht auf
> einem 32-bit Dualcore) auf die Idee, ein - offensichtlich perfekt
> ausgerichtetes - int per memcpy() zu kopieren oder vielleicht doch
> lieber per memmove(), weil es sich ja selber überlappen könnte.
>
> Ein einfaches
> * (int *) 0x80006e80 = * (int *) 0x80006e84;
>
> würde hier ohne große Diskussion dasselbe (richtige) tun, bloß viel
> schneller...

Warum sollte das schneller sein? Vermutlich wird der Code genau der 
selbe sein. Zumindest auf dem x86 ist er es.

[(prx) A. K. (prx)]

Rolf Magnus schrieb:
> Warum sollte das schneller sein? Vermutlich wird der Code genau der
> selbe sein. Zumindest auf dem x86 ist er es.

Nur wenn der Compiler sich wie GCC die Mühe macht, die Funktionalität 
von memcpy zu kennen und ggf. selbst zu implementieren. Ruft er hingegen 
unabhängig von Randbedingungen einfach nur ebendiese Lib-Funktion auf, 
wird die explizite Umgehung von memcpy bei wenigen Bytes stets erheblich 
schneller sein.

Auch bei grossen Datenmengen war und ist es trotz prozessorspezifischer 
Implementierung per Microcode über die Generationen der Prozessoren 
hinweg keineswegs selbstverständlich, dass der REP MOVS Befehl den 
schnellsten Weg darstellt. Erst recht nicht, wenn der Programmierer über 
den Kontext des Transfers mehr weiss, als es Compiler/Microcode können.

[Markus F. (mfro)]

Mein m68k-gcc z.B. hat offensichtlich Befürchtungen, daß die Adresse 
auch ungerade sein könnte und kopiert (mit -O3) bei memcpy() 
(__builtin_memcpy()) lieber vier Einzelbytes als ein int.

Mit -ffrestanding (nicht ganz unsinnvoll bei embedded Controllern) ist 
er ganz vorsichtig und ruft auch mit -O3 lieber memcpy() auf (wie sich 
das in dem Fall gehört).

[(prx) A. K. (prx)]

Markus F. schrieb:
> Mein m68k-gcc z.B. hat offensichtlich Befürchtungen, daß die Adresse
> auch ungerade sein könnte und kopiert (mit -O3) bei memcpy()
> (__builtin_memcpy()) lieber vier Einzelbytes als ein int.

Hängt davon ab, wieviele Parameter der Programmierer des Compilers bei 
der Optimierung des Builtins berücksichtigt.

[Markus F. (mfro)]

A. K. schrieb:
> Hängt davon ab, wieviele Parameter der Programmierer des Compilers bei
> der Optimierung des Builtins berücksichtigt.

... oder anders gesagt davon, für wie wichtig es eben jener erachtet, 
einen memcpy()-Aufruf, der eigentlich ein int kopiert, soweit zu 
optimieren, daß er nur noch ein int kopiert (mir persönlich wär' offen 
gestanden lieber, er würde seine Kreativität an ein paar anderen, 
realeren Optimierungsfällen auslassen).

Womit wir wieder am Anfang der Schleife wären ;-).

[casud (Gast)]

Manchmal macht memcpy für 4 bytes sehr wohl Sinn, nämlich dann wenn man 
"type punning" machen will.

Folgender Code ist böse!

float f(unsigned *p)
{
    return *(float *)p;
}

Dieser dagegen tut was er soll.
(voraussgesetzt sizeof(float) == sizeof(unsigned))
In den meisten Fällen wird das memcpy wegoptimiert.

float f(unsigned *p)
{
    float fl;
    memcpy(&fl, p, sizeof(fl))
    return fl;
}

[Daniel A. (daniel-a)]

casud schrieb:
> Manchmal macht memcpy für 4 bytes sehr wohl Sinn, nämlich dann wenn man
> "type punning" machen will.

Dafür gibt es aber bereits unions:

float f(unsigned x){
  union { 
    unsigned u;
    float f;
  } c;
  c.u=x;
  return f;
}

Oder darf der compiler dass wegen der aliasing rule wegobtimieren?

[Rolf M. (rmagnus)]

A. K. schrieb:
> Rolf Magnus schrieb:
>> Warum sollte das schneller sein? Vermutlich wird der Code genau der
>> selbe sein. Zumindest auf dem x86 ist er es.
>
> Nur wenn der Compiler sich wie GCC die Mühe macht, die Funktionalität
> von memcpy zu kennen und ggf. selbst zu implementieren.

Ja. Wir reden hier ja auch über GCC. Inwieweit das andere Compiler auch 
machen, weiß ich nicht.

> Auch bei grossen Datenmengen war und ist es trotz prozessorspezifischer
> Implementierung per Microcode über die Generationen der Prozessoren
> hinweg keineswegs selbstverständlich, dass der REP MOVS Befehl den
> schnellsten Weg darstellt. Erst recht nicht, wenn der Programmierer über
> den Kontext des Transfers mehr weiss, als es Compiler/Microcode können.

Das hat dann aber nichts mit der Frage zu tun, ob eine Zuweisung 
schneller ist als ein memcpy. Einige Programme auf dem PC, die große 
Datenmengen im Speicher schnell kopieren müssen, machen beim Start 
Performance-Tests, um zu ermitteln, welche Variante die schnellste ist. 
Gerade auf dem PC gibt es etliche verschiedene Möglichkeiten. REP MOVS 
ist schon lange nicht mehr die schnellste.

Markus F. schrieb:
> Mein m68k-gcc z.B. hat offensichtlich Befürchtungen, daß die Adresse
> auch ungerade sein könnte und kopiert (mit -O3) bei memcpy()
> (__builtin_memcpy()) lieber vier Einzelbytes als ein int.

Welche Adresse? Oben wird die Adresse ja direkt als Zahl angegeben. Daß 
die nicht ungerade sein kann, sollte der Compiler eigentlich erkennen 
können.

> Mit -ffrestanding (nicht ganz unsinnvoll bei embedded Controllern) ist
> er ganz vorsichtig und ruft auch mit -O3 lieber memcpy() auf (wie sich
> das in dem Fall gehört).

Das ist auch der große Nachteil von -ffreestanding. Es unterbindet 
einige Optimierungen, da der Compiler nicht mehr davon ausgehen darf, 
daß sich Funktionen wie memcpy() so verhalten, wie das in ISO-C 
festgelegt ist.

Daniel A. schrieb:
> casud schrieb:
>> Manchmal macht memcpy für 4 bytes sehr wohl Sinn, nämlich dann wenn man
>> "type punning" machen will.
>
> Dafür gibt es aber bereits unions:

Nein, genau dafür sind sie nicht gedacht. Du darfst in C eigentlich nur 
das Union-Element lesen, das du als letztes geschrieben hast. Davon 
abgeshen sieht es meiner Meinung nach auch nicht sonderlich elegant und 
eher umständlich aus, sich extra einen Typ und eine Variable definieren 
zu müssen und dann die Daten da rein und wieder rauszukopieren.

[Markus F. (mfro)]

Rolf Magnus schrieb:
> Welche Adresse? Oben wird die Adresse ja direkt als Zahl angegeben. Daß
> die nicht ungerade sein kann, sollte der Compiler eigentlich erkennen
> können.

Haha, tut er aber nicht, der blöde Hund.

Die Einzelbytekopiererei wird erst dann durch eine schnelle int-Kopie 
ersetzt, wenn -mno-strict-align in der Kommandozeile steht.

Dann allerdings auch, wenn explizit von/auf ungerade Adressen kopiert 
wird (der Adressfehler-Handler wird's schon richten). :-o

Kenne deinen Compiler - jetzt hab' ich auch was gelernt ;)

[olpo (Gast)]

Hallo,

kann das etwas mit der Byte-Reihenfolge zu tun haben?

Also ich kompiliere auf einer Intel Little-Endian Maschine.
Das ganze laeuft dann auf ARMv7 mit einem BareMetalOS, bei dem ich mir 
nicht sicher bin, ob das nicht doch Big-Endian kompiliert wurde.
Oder wird __BYTE_ORDER zur Laufzeit und nicht vom Compiler festgelegt?

Zumindest kriege ich keinen Error, wenn ich Little-Endian unten 
auskommentiere.

Das verwirrt mich alles...

static inline void store32(unsigned char *const buffer,
                           int offset,
                           uint32_t value)
{
    int i;
    for (i = 3; i >= 0; i--) {
        buffer[offset+i] = (value & 0xff);
        value >>= 8;
    }
}

#if __BYTE_ORDER == __LITTLE_ENDIAN
# define STORE32N(buffer,offset,value)   { printf("Little Endian\n"); memcpy(&buffer[offset], &value, 4); }
#elif __BYTE_ORDER == __BIG_ENDIAN
# define STORE32N(buffer,offset,value)   { printf("Big Endian\n"); store32(buffer, offset, value); }
#else
# error __BYTE_ORDER not defined
#endif

[olpo (Gast)]

hab nochmal einen manuellen Test gemacht, es ist also doch alles 
little-endian.

[olpo (Gast)]

ok, anscheinend hat hat ARM Schwierigkeiten mit unaligned memory. Intel 
buegelt das angeblich aus.

unsigned char *dest;
unsigned long src;
// ...

memcpy(&dest, &src, 4);

Das Problem ist wohl, dass "dest" vom Typ char ist und somit kleiner als 
die zu kopierenden 4 Byte, oder?
Oder kopiere ich an die Adresse vom Pointer *dest?

Egal,
das ganze ist Legacy Code, den ich jetzt auf ARM laufen lassen will.
Wie behebe ich das Problem am saubersten, ohne viel in den Code 
einzugreifen.

[Daniel A. (daniel-a)]

olpo schrieb:
> ok, anscheinend hat hat ARM Schwierigkeiten mit unaligned memory.

unsigned char *dest;
unsigned long src;
memcpy(&dest, &src, 4);

> Das Problem ist wohl, dass "dest" vom Typ char ist.
Nein, dest ist ein pointer auf char daten. wenn du den poiner dest 
referenzierst, hast du einen pointer auf einen pointer auf char daten.
Der wert des Pointers (dessen adresse), welche du überschreibst, wobei 
du annimst, aber nicht prüfst, ob diese grösser oder gleich 4 ist, ist 
garantiert aligned.

[(prx) A. K. (prx)]

olpo schrieb:
> ok, anscheinend hat hat ARM Schwierigkeiten mit unaligned memory.

Nicht generell. Manche können es, manche nicht.
Nur betrifft das den gezeigten Fall nicht.

[Norbert (Gast)]

olpo schrieb:
> Hallo zusammen,
>
> ich habe ein Programm, das memcpy verwendet.
> Allerdings stuerzt das Programm ab, was, glaube ich, an "region overlap"
> bei der Funktion memcpy() liegt.

memcpy(80006e80, 80006e84, 4):

> Da ein "region overlap" bei memcpy() zu Problemen fuehren kann, soll man
> wohl eher memmove() verwenden.
> Ich habe ebenfalls gelesen, dass die meisten Prozessoren oder Compiler
> memcpy() wie memmove() behandeln, um solch ein Laufzeitfehler
> auszuschliessen.

Wahrscheinlich ist es ja nur ein Tipp/Übertragungsfehler, aber...

sind die beiden Werte

80006e80 und 80006e84

 nicht einfach nur float Zahlen und damit für ein memcpy völlig 
ungeeignet?
Sollte es da nicht heftige Warnungen des Compilers geben?

Oder sollte es eigentlich (eventuell mit einem Typecast):

memcpy(0x80006e80, 0x80006e84, 4):

 heissen?

Nur so ein Gedanke.

[olpo (Gast)]

Norbert schrieb:
>
> Wahrscheinlich ist es ja nur ein Tipp/Übertragungsfehler, aber...
>
> sind die beiden Werte80006e80 und 80006e84 nicht einfach nur float
> Zahlen und damit für ein memcpy völlig
> ungeeignet?

Ja, das war nur faul geschrieben und auch mit den falschen Adressen.
Richtig ist es so:

memcpy(0x80004e8e, 0x80004e3c, 4);
// Allignment ERROR at memcpy 0x80004e8e

A. K. schrieb:
> olpo schrieb:
>> ok, anscheinend hat hat ARM Schwierigkeiten mit unaligned memory.
>
> Nicht generell. Manche können es, manche nicht.
> Nur betrifft das den gezeigten Fall nicht.

Also , hier passt alles?
Wie kann es dann zu einem Alignment Error kommen?
Hat jmd Vorschlaege, nach was ich gucken kann?
Genau an dieser memcpy()-Stelle fliegt er raus.

[(prx) A. K. (prx)]

olpo schrieb:
> Wie kann es dann zu einem Alignment Error kommen?

Im memcpy selbst darf kein alignment error ausgelöst werden.

[olpo (Gast)]

Ok, anscheinend laeuft man mit struct (und ARM) gerne in diese 
unalignment Falle.

Bei meinem Fall kommt tatsaechlich ein struct vor. Ich kann aber die 
problematische Stelle nicht ausmachen.
Versucht er das struct auf long zu "alignen"?

struct myBuf
{
 uint32_t size;
 uint32_t used;
 uint32_t flags;
 unsigned char buffer[MAX_BUFF_SIZE];
};


void foo( struct myBuf *buf)
{
 va_list argp;
 unsigned char *dest;
 unsigned long src;

 va_start(argp,buf);
 
 src = (unsigned long) va_arg(argp,unsigned long);

 memcpy(&dest, &src, 4);
}

[Klaus W. (mfgkw)]

Häh?
Was hast du damit vor?

buf ist die Adresse einer struct (hoffentlich, je nachdem, wie du die 
Funktion aufrufst).

Diese Adresse kopierst du über va_arg (merkwürdigerweis als unsigned 
long betrachtet) in die lokale Variable src.
Abgesehen davon, daß die Typen natürlich passen (Adresse in einer 
unsigned long), enthält src jetzt die Adresse der struct des Aufrufers.

Dann übergibst du an memcpy die Adresse der lokalen Variable src. memcpy 
wird also ab der Adresse 4 Byte kopieren - es wird also die Adresse der 
struct kopiert.

Das wolltest so wahrscheinlich nicht haben?

[Markus F. (mfro)]

Klaus Wachtler schrieb:
> Diese Adresse kopierst du über va_arg (merkwürdigerweis als unsigned
> long betrachtet) in die lokale Variable src.

Ähm, nö. Noch schlimmer.

Kopiert wird das auf buf folgende Argument (das möglicherweise da ist 
oder auch nicht).

Die Funktion sollte noch eine Ellipsis bekommen, um anzuzeigen, daß eine 
variable Argumentliste erwartet wird. Außerdem irgendeinen Parameter, 
der ihr sagt, wieviele Argumente grade zu erwarten sind.

So ist das jedenfalls nach Problemen gebettelt.

[Klaus W. (mfgkw)]

Markus F. schrieb:
> Kopiert wird das auf buf folgende Argument (das möglicherweise da ist
> oder auch nicht).

Stimmt, hatte ich ganz übersehen.

Der zusätzliche Versatz macht es dann auch nicht mehr besser :-)

[olpo (Gast)]

Ich raff den Code auch nicht, aber das ist Legacy Code von IBM(!).

Ich habe den Code nochmal um die Zuweisung an Destination erweitert. 
Vielleicht ergibt es so mehr sinn?
Was macht denn va_arg in dem Context?

struct myBuf
{
 uint32_t size;
 uint32_t used;
 uint32_t flags;
 unsigned char buffer[MAX_BUFF_SIZE];
};


void foo( struct myBuf *buf)
{
 va_list argp;
 unsigned char *dest;
 unsigned long src;
 unsigned char *buffer = buf->buffer;

 va_start(argp,buf);
 dest = &buffer[buf->used];
 
 src = (unsigned long) va_arg(argp,unsigned long);

 memcpy(&dest, &src, 4);
}

Aber ein Alignment Fault laesst sich hier nicht erkennen, oder wie?

[Markus F. (mfro)]

olpo schrieb:
> Was macht denn va_arg in dem Context?

Kann man nur sagen, wenn Du auch den Aufruf der Funktion postest.

Wenn da nach buf noch ein Argument kommt, müsste man sich genau 
anschauen, was da gemacht wird.

Wenn nicht, könnte das möglicherweise ein Versuch sein, erstens den 
aufrufenden Stackframe (z.B. für eine Art "setjmp()") zu manipulieren 
und zweitens den eigenen Job bis in alle Ewigkeit zu erhalten (was ja 
offensichtlich nicht funktioniert hat, sonst wär' der, der das 
verbrochen hat, ja noch zu greifen).

[Klaus W. (mfgkw)]

Wie bereits weiter oben steht: in memcpy kann es kein Problem mit 
alignment geben, weil diese Funktion auch mit ungeraden Adressen 
hantieren kann.

Aber du greifst gezielt neben alle irgendwie definierten Werte zu mit 
deinem verkorksten va_arg-Müll.
Wenn der Rest des Programms genaus schlecht ist, wie das was man hier 
sieht, würde ich auch nicht darauf wetten, daß &buffer[buf->used] 
kleiner gleich 4 Byte vor dem Ende des Puffers landet.
Da ist es sinnlos zu spekulieren, warum etwas schief geht.


Es könnte überschriebene Rücksprungadresse geben, verbogene Stackframes 
oder ziemlich alles andere geben.

Bestenfalls könnte man gezielter spkulieren, wenn man das ganze Programm 
sieht.
Ob sich das jemand antun will, wage ich aber zu bezweifeln.

[(prx) A. K. (prx)]

stdarg.h Kram ohne ... in der Parameterliste zu verwenden fordert 
Probleme heraus. Falls der Code im Original exakt so aussieht: kopierter 
Mist bleibt Mist. Insbesondere wenn der Mist beispielsweise von x86 nach 
ARM kopiert worden sein sollte (andere Technik der Parameterübergabe).

[olpo (Gast)]

Ach mist, ich habe eine Fehler oben in dem Beispiel-Code gemacht.
Es muss so aussehen:

unsigned char *buf;
unsigned long src;

memcpy(&buf[0], &src, 4);

Alignment Error?
buf ist also ein Array von Chars. Und so frisst das ARM nicht, weil Char 
!= 4Byte ist, oder?

[Daniel A. (daniel-a)]

olpo schrieb:
> unsigned char *buf;
> unsigned long src;
>
> memcpy(&buf[0], &src, 4);

Da hier buf keinen definierten Wert hat, also ins nirvana zeigt, ist das 
schreiben nach buf unsinnig. Zeige doch mal den echten gesammten Code 
der Funktion, falls diese existiert, oder zumindest was diese tun soll.

[Markus F. (mfro)]

olpo schrieb:
> Alignment Error?
> buf ist also ein Array von Chars. Und so frisst das ARM nicht, weil Char
> != 4Byte ist, oder?

Nein. memcpy() ist so definiert, daß es void-Zeiger akzeptiert und muß 
(weil die auf jeden beliebigen Datentyp zeigen können) unabhängig von 
der Plattform auch von/auf ungerade Adressen kopieren können.

[Klaus W. (mfgkw)]

olpo schrieb:
> memcpy(80006e80, 80006e84, 4):

olpo schrieb:
> memcpy(&dest, &src, 4);

Daniel A. schrieb:
> unsigned char *dest;
> unsigned long src;
> memcpy(&dest, &src, 4);

olpo schrieb:
> memcpy(0x80004e8e, 0x80004e3c, 4);
> // Allignment ERROR at memcpy 0x80004e8e

olpo schrieb:
> struct myBuf
> {
>  uint32_t size;
>  uint32_t used;
>  uint32_t flags;
>  unsigned char buffer[MAX_BUFF_SIZE];
> };
>
> void foo( struct myBuf *buf)
> {
>  va_list argp;
>  unsigned char *dest;
>  unsigned long src;
>
>  va_start(argp,buf);
>
>  src = (unsigned long) va_arg(argp,unsigned long);
>
>  memcpy(&dest, &src, 4);
> }

olpo schrieb:
> struct myBuf
> {
>  uint32_t size;
>  uint32_t used;
>  uint32_t flags;
>  unsigned char buffer[MAX_BUFF_SIZE];
> };
>
> void foo( struct myBuf *buf)
> {
>  va_list argp;
>  unsigned char *dest;
>  unsigned long src;
>  unsigned char *buffer = buf->buffer;
>
>  va_start(argp,buf);
>  dest = &buffer[buf->used];
>
>  src = (unsigned long) va_arg(argp,unsigned long);
>
>  memcpy(&dest, &src, 4);
> }

olpo schrieb:
> Ach mist, ich habe eine Fehler oben in dem Beispiel-Code gemacht.
> Es muss so aussehen:
> unsigned char *buf;
> unsigned long src;
>
> memcpy(&buf[0], &src, 4);

Wieviele Varianten kommen denn noch?