Hello Neider, hello all,

I changed the subject in order to create a new thread for discussing these compiling issues.

I am using an up-to-date Ubuntu Edgy (kernel 2.6.17-10) in an AMD64.

I got the latest svn version of SDCC and tried the usual installation process: ./configure ; make ; sudo make install

When running make everything seems to compile fine until it enters the folder device/lib and tries to use ../../bin/sdcc to compile the libraries. The last error message I get looks like this:
make[2]: Entering directory `/home/guerra/sdcc-svn/device/lib'
mkdir -p build/ds390
../../bin/sdcc -I../../device/include -I../../device/include/mcs51 -mds390 --nostdinc --std-sdcc99 -c _autobaud.c -o build/ds390/_autobaud.rel
Caught signal 11: SIGSEGV
make[2]: *** [build/ds390/_autobaud.rel] Error 1
make[2]: Leaving directory `/home/guerra/sdcc-svn/device/lib'
make[1]: *** [model-ds390] Error 2
make[1]: Leaving directory `/home/guerra/sdcc-svn/device/lib'
make: *** [sdcc-device-lib] Error 2

I started reverting to the previous releases with "svn up -r ####" until I found the most up to date which compiles in my machine, which was the SDCC 2.6.3 r4562

I tried GCC 4.1.2 20060928 in all releases from r4563 until r4573, and I also tried both GCC 4.0.4 20060630 and GCC 3.4.6 with each of r4563 and r4573. All give the same error above.


On 1/15/07, Raphael Neider < rneider@web.de> wrote:
Hi Rodrigo,

> I never tried the simulator, but I will give it a shot later. I
> checked out the SDCC 2.6.4 r4570 yesterday but it didn't compile...
> just now I tried r4573 and it still didn't compile. I get "Caught
> signal 11: SIGSEGV" when it tries to compile the device libs... Anyway
> I think it would be more appropriate to discuss compilation problem in
> a different thread.

What platform are you compiling on? Some PowerPC or Sparc, i.e.
big-endian, I guess? There have been unresolved issues reported a while
back, but myself not having access to such a machine, I was/am unable to
resolve them. The libs compile fine on my Intel/AMD Linux boxes.

> I use two LEDs to debug my program in the device. I have one green LED
> in RA4 and another orange LED in RB4. The green LED goes on with PORTA
> = 0x00 and goes off when PORTA = 0x10. The same for the orange LED
> with PORTB.
> I initialize both PORTA and PORTB with 0x10 and then I did something
> like this to test the value in *p:

Maybe this should be LATA and LATB; write to the latches, read from the
port. However, this probably does not cure the problem.

> I am sure the value is neither 0x34 nor 0x12 after assignment with
> general pointer. I also suspect there was some data memory corruption
> because when I first noticed the problem in the actual application
> some very unrelated variable seemed messed up... but I didn't isolate
> that problem to be sure... (difficult to reproduce).

Memory corruption? You may need to use a larger stack:
        #pragma stack 0x200 0x100
added in the single (!) file containing 'void main(void)' should do the
trick, giving you a 256 byte stack located at 0x200..0x2FF.
You may also have a look at the linker-generated .map file (use sdcc
-Wl,-m ... or gplink -m ... to create it) to see if wherever p points to
is close to the lower stack boundary (defaults to 0x200) and thus might
have been destroyed by calling __gptrget().


Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
Sdcc-user mailing list

Rodrigo da Silva Guerra
PhD Student

Department of Adaptive Machine Systems
Graduate School of Engineering
Osaka University - Japan