ide driver code - still problems

[Peter Mueller]

Hi all,

I still have problems and have no idea how to track them down.
Here is a more detailled descrtion (see also the 1st mail):

I have integrated Thomas' IDE driver and built a small C example program that works.
Then I want to build a small C++ example because my final system should run under C++.

I moved the OS initialization stuff in a seperate C file. In C++ there is nothing but Init() at the moment.

In the IDE init code I now have the following effects:
- a pointer to unsigned char which I set to zero is not known by the debugger
- malloc of 512 bytes seems to work. I know that because
I stepped in the function that gets this pointer as a parameter. The strange thing is now
that when i make a memory dump of the area the pointer points to, ddd shows that it is the area where doneConstructor, bdctx ... and other symbols reside.

On the other hand I have checked that there is enough workspace available (as described in the FAQ). So I assume no problem with stack size etc.

Is this really a problem of switching to C++ or only a wrong assumption?
How can I go on to find the problem - ideas?

Peter



On Wed, 28 Aug 2002 08:21:21 +0200
"Thomas Doerfler" <Thomas.Doerfler at imd-systems.de> wrote:

> Hi Peter,
> 
> all you describe sounds (at least partly) like a visualization 
> problem between gdb and gcc. At least in some verions gdb is 
> not so aware which processor registers keep which variables.
> 
> The array "data" should be located on the stack (So you might 
> run into problems, if the stack size is too small). I would 
> try to look into the array "data" at the end of function 
> "read_block", chances are good for GDB to locate the buffer 
> variable properly there.
> 
> wkr,
> 	Thomas.
> 
> 
> > Hi all,
> > 
> > I'm currently using the ide driver from Thomas to access an IDE drive from my 68332 CPU. So far everthing seems to be fine. I have managed to read out the directory of hda1. Unfortunately this works only with a very small C program. If I build a bigger application the following occures:
> > 
> > I already had a strange effect while adapting the driver code to my system. In the ide code there is a routine loading the MBR to check whether there is a valid partition available etc. Therefore a buffer of 512 bytes is required. In the original code from Thomas this looks like:
> > 
> > ....
> >         rtems_unsigned8 data[SECTOR_DATA_SIZE];
> > ....
> >         if(read_block(hd, SECTOR_MBR, (rtems_unsigned16 *)data, SECTOR_DATA_SIZE) == 0)
> > 
> > This looks ok but "data" was always corrupt (seems to point in the code area). I changed the code then to 
> > 
> >         rtems_unsigned16 *data;
> > 	...
> >         data = malloc(512);
> > 
> >         if(read_block(hd, SECTOR_MBR, data, SECTOR_DATA_SIZE) == 0){
> > 
> > This has worked for my small C test programm bug fails if I have a bigger application. In my opinion both should work. In the bigger application the debugger (ddd) does not even show me  "data". Gdb says the symbol is not available. I assume this indicates that I have a problem with my stack 
> ...
> > 
> > I'm not sure if the problem is really related to applicatio size. Any idea how to tackle the problem? Can I use malloc in this early stage of OS initialization? How can I find out the amount of stack, data etc. is available for the OS and application during OS boot?
> > 
> > Any hints welcome,
> > Peter
> > 
> 
> --------------------------------------------
> IMD Ingenieurbuero fuer Microcomputertechnik
> Thomas Doerfler           Herbststrasse 8
> D-82178 Puchheim          Germany
> email:    Thomas.Doerfler at imd-systems.de
> PGP public key available at: http://www.imd-
> systems.de/pgp_key.htm
> 


-- 
"This is an object-oriented system.
If we change anything, the users object."

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 00000000.mimetmp
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/users/attachments/20020829/34c7327b/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/users/attachments/20020829/34c7327b/attachment-0003.bin>