LPC2129 & GCC - Problemet med variabelt antal argumenter

[p_piotr]

Hej!
Jeg har et problem med brugen af funktioner, der har varierende antal argumenter, for eksempel:
<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr><td> <b>Kode:</b> </td></tr><tr><td class="code"> funktion (char * s, char * fmt, ...); </td></tr></table>
Det viser sig, at der inden for funktioner ikke længere viser det forkerte sted. Ligner et problem med stack. Han mødtes en person med sådan noget og fandt en løsning?
Alt sker på CodeSourcery (2009q1) og for LPC2129.
Jeg formoder det er derfor jeg kan ikke køre printf'a.
Tak på forhånd for din hjælp.
Hilsen.

 

[kordirko]

Sørg for at du kalder funktionen, før du har erklæret,
hvis ikke, så det rette sted at sætte den til at bruge funktionen erklæringen header.
Hvis du bruger det, før du har erklæret, compileren tager
"Standard" form for funktionen: int funktion (int, int, int)
så hvad er sandt en rapport advarsel, men opgør og link-og et program fejl.

 

[p_piotr]

Det faktum, at det ville være en god forklaring ... Men desværre, alt, hvad jeg har og ingen warningów podeklarowane. Anyway, ligesom fusk med disse bogstaver, de parametre, er endnu en arbejder (f.eks f (char *, char *,...), og ikke arbejde for f (char *,...)). Er dette den aktive sag listen indeholder de korrekte værdier er endnu ikke tjekket.

 

[Freddie Chopin]

På samme CodeSourcery, så de kan bare for en anden processor sådanne funktioner arbejde uden et problem for mig. Læg koden, fordi det er 99,666% er ikke en compiler fejl, men din.

4 \ / 3!

 

[markosik20]

<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr><td> <b>p_piotr skrev:</b> </td></tr><tr><td class="quote"> Det viser sig, at der inden for funktioner ikke længere viser det forkerte sted. </td></tr></table>

? Selvfølgelig har nogle operationer på "s"? Hvordan kan du vide, at indekset har den forkerte adresse? Debugging kode?

 

[p_piotr]

Hey! Jeg ved, at 's' dårlige show, fordi jeg udskrive sin værdi efter funktionen indrejse.

Problemet begyndte at forklare. Jeg har bemærket, at værdien af dette forhold som funktion af forskydning er den korrekte værdi ... Jeg kinda så det andet sted ....

Nå, adressen på array, som er gået til funktionen ikke var deleligt med 4 Hvorfor? Array blev placeret på stakken. Adresse toppen af stakken jeg var sat til 3fff udelelige, og derfor værdi på 4, og derfor er mere variabel forsinket ved 4 eller 8 byte af adresserne blev udelelige med 4 Jeg oprettede stakken på 3ffc og alt virker. Ujusterede hukommelse adgang ... Mens ikke alt er her for mig. Den første parameter var en god værdi, indtil han igen blev udsat. Og begge disse parametre var det den samme tabel ...

De præsenteres som du har øverst i stakken adresser?

Nogen er i stand til at forklare det til slutningen af, hvad der foregik?

Med venlig hilsen

 

[Freddie Chopin]

1. Armacham stak er standard "fuld faldende" - så det er forudsat, at SP peger på et sted, der allerede besat. At sætte noget på stakken af SP er reduceret med først, og så er der noget er placeret (på et nyt arbejdssted, nedenfor). Af denne grund, stak de er sat til den adresse RAM_START RAM_SIZE. I dig, jeg som tror det vil være 0x4000, og vil være fint. Når du mister din én hukommelse celle.

2. Den første parameter er god, og den anden forkert, fordi jeg arbejder funktioner med et variabelt antal argumenter. Kun den første parameter er bestået "normal" - registret - alle andre (standard! Herunder) Er igennem stakken.

4 \ / 3!

 

[p_piotr]

Hej!
Nå, det er allerede klart. Interessante oplysninger fra den første parameter, der skal sendes af registreringsdatabasen.

Og det stak er den ene eller den anden, det er bare min mening, ikke afhænger af "domyślego ARMów adfærd" kun fra den, hvordan stakken vil blive organiseret af GNU-værktøjerne i dette særlige tilfælde. Men der er ingen hardware skorsten, ikke?

Regards,

 

[Freddie Chopin]

<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr><td> <b>p_piotr skrev:</b> </td></tr><tr><td class="quote"> Og det stak er den ene eller den anden, det er bare min mening, ikke afhænger af "domyślego ARMów adfærd" kun fra den, hvordan stakken vil blive organiseret af GNU-værktøjerne i dette særlige tilfælde. Men der er ingen hardware skorsten, ikke? </td></tr></table>
Der er dog ARM's officielle anbefalinger om en række mekanismer, der anvendes af compilere - ARM EABI.

4 \ / 3!