Jump to content
Sign in to follow this  
LasseT

Struct/struct Addressing Problem

Recommended Posts

Bug description:

I'm reusing a C-program that is compiled with a GNU C compiler and the program works ok in that environment. No problems what so ever.

When I try to compile the same program in BoostC IDE design environment it seems to work alright because I will not receive any warnings or errors. The program does not work ok when it runs on a PIC circuit. After some debugging sessions I have identified som addressing problems of "structs in structs" (or what I shall call it? pointers to structs in structs maybe).

 

I use this quite often in my program:

(&pointer_to_mainstructure->another_struct)->local_1 = "data";

and I hope this is alright according to the C language :-).

No warning/no error from compiler so this is hopefully OK ? :-)

comment: I have a hard time to explain this in writening but I think you can follow this in my very simple test program.

======= T E S T P R O G R A M B L O C K =====================

#include <system.h>

#include <boostc.h>

== Program description

/* * The intention is to fill the "mainstruct" defined below with this data

* $0/1 = object_first = 0x1111

* $2/3 = "struct a" local_1 = 0x5555;

* $4 = "struct a" local_2 = 0x66;

* $5/6 = "struct b" local_1 = 0x7777;

* $7 = "struct b" local_2 = 0xEE;

* $8/9 = object_1 = 0x1234;

* $A/B = object_2 = 0x5678;

* $C/D = object_3 = 0x9ABC;

* $E/F = "struct c" local_1 = 0xCCCC;

* $10 = "struct c" local_2 = 0xDD;

* $11/12 = object_last = 0xAAAA;

* But the result is like this

* $0/1 = object_first = 0x1111

* $2/3 = "struct a" local_1 = 0x0000;

* $4 = "struct a" local_2 = 0x00;

* $5/6 = "struct b" local_1 = 0x0000;

* $7 = "struct b" local_2 = 0x00;

* $8/9 = object_1 = 0x1234;

* $A/B = object_2 = 0x5678;

* $C/D = object_3 = 0x9ABC;

* $E/F = "struct c" locall_1 = 0x0000;

* $10 = "struct c" local_2 = 0x00;

* $11/12 = object_last = 0xAAAA;

==============================================================*/

 

struct smallstruct {

int local_1;

char local_2;

};

 

struct mainstruct{

int object_first;

struct smallstruct a;

struct smallstruct b;

int object_1;

int object_2;

int object_3;

struct smallstruct c;

int object_last;

};

 

struct mainstruct first; //create the first struct of mainstruct type :-)

struct mainstruct *First; //Pointer

//========================================================================

void main(void) {

 

First = &first;

 

for (;;){

First->object_first = 0x1111;

First->object_last = 0xAAAA;

(&First->a)->local_1 = 0x5555; // No warning from compiler and target wrong memory address

(&First->a)->local_2 = 0x66; // No warning from compiler and target wrong memory address

(&First->B)->local_1 = 0x7777; // No warning from compiler and target wrong memory address

(&First->B)->local_2 = 0xEE; // No warning from compiler and target wrong memory address

First->object_1 = 0x1234;

First->object_2 = 0x5678;

First->object_3 = 0x9ABC;

(&First->c)->local_1 = 0xCCCC; // No warning from compiler and target wrong memory address

(&First->c)->local_2 = 0xDD; // No warning from compiler and target wrong memory address

// Test another way to access the structure objects ==========================

First->a.local_1 = 0xa1a1; //Correct address in struct, OK

First->b.local_1 = 0xb1b1; //Correct address in struct, OK

First->c.local_1 = 0xc1c1; //Correct address in struct, OK

First->c.local_2 = 0xc2; //Correct address in struct, OK

First->b.local_2 = 0xb2; //Correct address in struct, OK

First->a.local_2 = 0xa2; //Correct address in struct, OK

}

}

 

// END OF TESTPROGRAM =======================================

Steps to reproduce:

 

Run the testprogram and look into the memory area to see the result.

(I will try to upload the project and c code file later today)

 

Expected behaviour:

If this is "bad C programming" please issue a warning or error when (&pointer->pointer)->object is used

OR if it is "ok" to use this addressing ...consider it as a candidate for a future release.

 

Is the problem 100% reproduceable:

Yes!

 

IDE version: SourceBoost IDE version 6.91

Compiler: BoostC Optimizing C Compiler Version 6.91(for PIC18 architecture)

Target device: PIC18F4685

OS: Windows XP and Windows Vista (tested on both platforms)

 

Regards,

LasseT

 

I have been trying to upload the projec file and the c code file but it does not work for me :-(.

I hope that you can run my simple test program to verify the problem/bug anyway!

Edited by LasseT

Share this post


Link to post
Share on other sites

Dunno if I'm having the same problem here:

I'm copying some struct data to be send via serial port, but the thing I was getting was wrong data.

I checked all my code and it seems ok, So I started using MPLAB debugger to see what went wrong.

Everything seems nice until a memcpy call, so I check the function again and finally realize the following:

Here is an screenshot:

SourceBoostBug.jpg

As you can see both StoreMsg, and Data->Msg.Time share the same address.

Share this post


Link to post
Share on other sites

Carnage,

As you can see both StoreMsg, and Data->Msg.Time share the same address.
I think this is a different issue. Hard to know whats going wrong here with only such a small snapshot of events.

Looks like the code is entered with a bad pointer, where does that pointer value come from?

 

Regards

Dave

Share this post


Link to post
Share on other sites
Carnage,
As you can see both StoreMsg, and Data->Msg.Time share the same address.
I think this is a different issue. Hard to know whats going wrong here with only such a small snapshot of events.

Looks like the code is entered with a bad pointer, where does that pointer value come from?

 

Regards

Dave

Dave I made a new proyect and found the same isue here is the code (please note debug is on)

The problem again is in the same function (SendData)

Aparently the paramaters and the first local variable StoreMsg (or any variable that take the first place) ocupies the same memory space

A pic of the new proyect same problem

Bug.jpg

Thanks

Edited by Carnage

Share this post


Link to post
Share on other sites

This was a compiler problem that has been fixed by now. The fix will be available in the next release.

 

Though the compiler will handle expressions like this we recommend to use '.' operand where possible. The '.' operand generates much less code than '->'. For example code like :

 

(&First->a)->local_1 = 0x5555;

 

will generate about 18 instructions while code:

 

first.a.local_1 = 0x5555;

 

will producte only 3 instructions.

 

Regards,

Pavel

Share this post


Link to post
Share on other sites
This was a compiler problem that as been fixed by now. The fix will be available in the next release.

 

Though the compiler will handle expressions like this we recommend to use '.' operand where possible. The '.' operand generates much less code than '->'. For example code like :

 

(&First->a)->local_1 = 0x5555;

 

will generate about 18 instructions while code:

 

first.a.local_1 = 0x5555;

 

will producte only 3 instructions.

 

Regards,

Pavel

Pavel or Dave:

Did you got the chance to check the problem I decrive above?

Edited by Carnage

Share this post


Link to post
Share on other sites
I could not open the link http://www.udec.cl/~nafuente/main.c

 

Regards,

Pavel

Pavel:

Strange

I have it attached on this post. Hope this help

Thanks

 

Not sure I understand where the problem is. I compiled the code you sent under SourceBoostIDE and don't see any overlap.The function argument 'Data' occupies 2 bytes at address 0x23 and the first local variable 'StoreMsg' occupies 15 bytes starting from 0x25. No overlapping. Check the ASM file generated by the linker:

 

...

SendData_00000_arg_Data EQU 0x00000023 ; bytes:2

SendData_00000_1_StoreMsg EQU 0x00000025 ; bytes:15

...

 

Regards,

Pavel

Share this post


Link to post
Share on other sites

Strange, let me check it again.

You are right, it appears that was a debugger problem.

BTW will SourceBoost get any hardware debugger?

Edited by Carnage

Share this post


Link to post
Share on other sites

Join the conversation

You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

×
×
  • Create New...