Messages

1

Zaurus - pdaXrom / Troubleshooting Segmentation Faults

« on: November 03, 2006, 12:39:19 am »

x86 and ARM were designed for different purposes; one is not more right than the other. But it just happens that most of the applications we're compiling for the Z was written and tested on x86. Then if it crashes on the Z, we need to find out why so we can fix it.

As I understand it:
1) When legit x86 code is ported to an ARM device and crashes, unaligned access is likely the issue.
2) Compilers usually align things in memory. Packing code is telling the compiler not to do this, so if the x86 code you are trying to port includes packing, this could well be a reason for unaligned access. Removing the packing from the code could cure the problem.

The reason I want to point this out is that packing the code has appeared as a solution to eliminating unaligned access rather than a source of unaligned access. At least both me and Merli have been adding pack statements to our code in the hope of getting rid of unaligned access. Maybe I misunderstood you, but when you posted code showing how to pack a structure, I took it as a suggestion for something to try to solve my problem. But actually it was a #pragma pack statement in the code that was the whole problem.

Anyway, the code is now fixed and working as intended, so I'm happy.  

2

Zaurus - pdaXrom / Troubleshooting Segmentation Faults

« on: November 02, 2006, 03:11:25 am »

Plus, why wouldn't the compiler align elements when specifically told so.

Please post a complete testcase (a program that can be compiled and run), so we can look at it and try to figure out what's wrong.

Somebody had left a #pragma pack(1) earlier in the code without doing a #pragma pack() later, so compiler was instructed to pack all subsequent code regardless of my effort to align it.

You've said that packing is not at fault and ARM architecture is not at fault. But for a fact, running packed code on ARM devices is a source of crashes. Of course, in the end the programmer is at fault for writing non-portable code, or the user is at fault for trying to run non-portable code on ARM. But knowing that human error is to blame doesn't help you much when troubleshooting.

Thanks for the link. It clarified another thing I hadn't understood - why the uint16_t elements did not need to be on a 4-byte boundary (2-byte elements on 2-byte boundaries are ok).

3

Zaurus - pdaXrom / Troubleshooting Segmentation Faults

« on: November 02, 2006, 01:17:27 am »

Serge:
I appreciate your effort to explain. But the two things I didn't understand was how packing (removing padding) can help when alignment (add padding) is what is needed. Plus, why wouldn't the compiler align elements when specifically told so.

Well, it turned out that earlier in the code (1000s of lines, so I didn't look through it all!) someone had added a #pragma pack(1) without doing a #pragma pack() later, so the compiler had counterinstructions to pack everything regardless of my efforts to align it! Adding a #pragma pack() after the structure to be packed (so that all subsequent  structures were NOT packed) solved the problem too.

Packing code can be necessary for some purposes, but it is not the solution when you're looking to align elements to avoid program crashes. Straight the opposite, it is a source of unalignment. So look out for #pragma pack and __attribute__((packed)) in your code if it's crashing. Removing them and perhaps using __attribute__((align(4))) or compiler flags to help ensure alignment could solve your issues (with the risk of creating others).

Miskinis:
Thanks for clarifying. Adding the filler did work - it was just more cumbersome because I also had to add an element in many other lines of code where the structure is used.

4

Zaurus - pdaXrom / Troubleshooting Segmentation Faults

« on: October 31, 2006, 05:52:06 am »

Good news: I got rid of my seg fault, thanks to miskinis' "shot in the dark". Instead of adding a filler (which would require me to add an element everywhere the structure is used), I changed submenu->type to a 4-byte element, type uint. Voila, alignment achieved and I can finally, finally do remote capture with my Z!  

Bad news: This issue is very confusing, and it certainly was a pain to troubleshoot. Look at the structure:

Code: [Select]

struct submenu {
char   *label;
char  *name;
uint16_t propid;
uint16_t vendorid;
uint16_t type;
get_func getfunc;
put_func putfunc;
};If the function pointers are unaligned, other things would appear to be so as well - the character arrays can be uneven # of bytes, and if propid happens to be aligned, vendorid isn't! For the same reason I did consider miskinis' suggestion very unlikely to work and was close to not even trying. Is it only some types of objects, such as pointers, that need alignment?

It appears that compilers by default will add padding in some places to achieve alignment, and in other places they won't. Inconsistent, but perhaps a compromise between memory efficiency and avoiding crashes. What I really don't understand are the following two things:
1) How is "packing" going to help? Doesn't that tell the compiler not to add any padding, increasing the likelyhood of unaligned accesses? I did try all packing suggestions anyway and, indeed, couldn't make any work.
2) How the heck to make the compiler align the offending elements? You'd think that's what e.g. __attribute__((aligned(4))) is for, but I've applied it both to the function pointers and, to be sure, the element just before them (submenu->type). Still unaligned!!   Finally, the flag -Wcast-align is supposed to warn of possible bad alignments. It did come with warnings, just not where the alignment problem was.

In the end, only a shot in the dark worked. This doesn't seem right. Do we have a buggy toolchain (zgcc-3.4.5)? Which leads me back to asking: Can the newer GNU ARM toolchain be used to compile programs for the Z and pdaXrom without major difficulties?

P.S. To make sure the post doesn't appear ungrateful I'd like to thank everybody who made suggestions.

5

Zaurus - pdaXrom / Troubleshooting Segmentation Faults

« on: October 26, 2006, 12:21:55 am »

I've tried rebuilding with -mstructure-size-boundary=32, -malignment-traps and mno-alignment-traps for that matter - crashes just the same.

However, according to Merli's link it could likely be an alignment issue. Here is the structure in which the crash happens:

Code: [Select]

struct submenu {
    char      *label;
    char  *name;
    uint16_t    propid;
    uint16_t    vendorid;
    uint16_t    type;
    get_func    getfunc;
    put_func    putfunc;
};

struct menu {
    char  *label;
    char  *name;
    struct    submenu    *submenus;
};
It is the get_func and put_func pointers that are corrupted. I tried putting some __attribute__((packed)) in there, and it did change the invalid values of the pointers, but only to other invalid values  Maybe I'm doing it wrong - can anybody tell how to apply the __attribute__((packed)) on these structures to get a working alignment?

6

Zaurus - pdaXrom / Troubleshooting Segmentation Faults

« on: October 24, 2006, 06:55:59 am »

Yes, it's on the C1000.
I have only run into one command that triggers the crash:
gphoto2 --set-config capture=on
Without this I can't use the camera for remote capture which was the whole plan with my Z.  
It works fine w. Ubuntu 6.06 (Dapper) on my laptop, so the code is ok, except when being compiled on the Z.
An example of ARM architecture issues:
http://www.arm.com/support/faqdev/1228.html  (See last paragraph, 'Porting code...')

But the compile toolchain could be the problem too? Here's an example of what can happen:
http://www.arm.com/support/faqdev/1247.html
I know this applies to a different toolchain, but the symptoms appear to be exactly what I'm seeing. Debugging with GDB I can't trace the code all the way to the actual crash, and backtraces fail, running into null pointers in the stack.

One suggestion I got from the gPhoto people was trying to use different compile flags. I haven't had success, but maybe it could resolve issues for others. Here's a list of ARM specific compile flags:
http://gcc.gnu.org/onlinedocs/gcc-3.4.5/gcc/ARM-Options.html

Finally I have a question. I just stumbled across GNU ARM which is a somewhat newer toolchain than the zgcc-3.4.5 I'm using now. Is it possible (and not overly complicated) to use this to compile programs for pdaXrom on the Z??

7

Zaurus - pdaXrom / Troubleshooting Segmentation Faults

« on: October 23, 2006, 06:45:17 am »

I've compiled the latest version of gPhoto (2.2.0, libgphoto 2.2.1) on my Zaurus, but it crashes with a segmentation fault. Aided by gPhoto developers I've found that the crash happens because the following assignment fails:

Code: [Select]

struct submenu *cursub = menus[menuno].submenus+submenuno;The structure contains pointers to two functions, but above statement assigns invalid pointers, resulting in the seg fault when a function call is performed with an invalid pointer. The relevant source code is found in the libgphoto package, file camlibs/ptp2/library.c, crash happens at line 3727. gPhoto developers suggested that it is an ARM architecture related problem and couldn't help me more.

Isn't it possible to find out what causes such problems so the code can be modified (or compiled differently) to work on the Zaurus? Or does everybody just give up at this point???  

Any troubleshooting advice would be highly appreciated. I really really want this to work.

8

Zaurus - pdaXrom / Libtool For Pdaxrom?

« on: July 28, 2006, 09:33:09 am »

I'm trying to install INDI for control of telescopes etc., but it apparently requires libtool to compile. Is a libtool ipk available, or is there a zgcc image for pdaXrom that contains it?

Perhaps what I really need are just the following files:
config.guess    config.sub    ltmain.sh
Would it be possible to steal these from somewhere?

9

Zaurus - pdaXrom / Help Needed Compiling Gphoto2

« on: June 21, 2006, 12:24:26 pm »

Thanks a lot for clarifying. Now I added libusb (new v.0.1.12) and libexif to my cross compiling environment using:

CC=gcc CXX=g++ F77=g77 ./configure --host=armv5tel-cacko-linux --build=i686-linux prefix=/opt/cross/arm/3.4.5-xscale-softvfp/armv5tel-cacko-linux

This didn't work with libgphoto2. ./configure completes, but then running make I get:

gcc -g -O2 -Wall -g -o .libs/test-gp-port test_gp_port-test-gp-port.o  ../libgphoto2_port/.libs/libgphoto2_port.so ../libltdl/.libs/libltdlc.a -ldl -Wl,--rpath -Wl,/opt/cross/arm/3.4.5-xscale-softvfp/armv5tel-cacko-linux/lib
../libltdl/.libs/libltdlc.a: could not read symbols: Archive has no index; run ranlib to add one

Running ranlib (native or arm version) on libltdlc.a doesn't help.

Creating the libgphoto2 arm binaries by removing flags CC/CXX/F77/prefix fails already at ./configure:

checking for LIBUSB... yes
checking usb.h usability... yes
checking usb.h presence... yes
checking for usb.h... yes
checking for function usb_busses in libusb... no
configure: error:
PKG_CONFIG_PATH=/opt/cross/arm/3.4.5-xscale-softvfp/armv5tel-cacko-linux/lib/pkgconfig
LIBUSB_LIBS=-L/opt/cross/arm/3.4.5-xscale-softvfp/armv5tel-cacko-linux/lib -lusb
LIBUSB_CFLAGS=-I/opt/cross/arm/3.4.5-xscale-softvfp/armv5tel-cacko-linux/include

* Fatal: libgphoto2_port by default requires libusb >= 0.1.5 to build.

What am I doing wrong?  

10

Zaurus - pdaXrom / Help Needed Compiling Gphoto2

« on: June 21, 2006, 03:08:31 am »

New versions of gphoto2 and libgphoto2 are out. I am new to cross compiling and have no luck. I can't seem to explain to ./configure where to find usb.h:

checking for LIBUSB... yes
checking usb.h usability... no
checking usb.h presence... no
checking for usb.h... no
configure: error:
PKG_CONFIG_PATH=/opt/cross/arm/3.4.5-xscale-softvfp/armv5tel-cacko-linux/lib/pkgconfig
LIBUSB_LIBS=-lusb
LIBUSB_CFLAGS=

* Fatal: libgphoto2_port by default requires libusb >= 0.1.5 to build.

File usb.h can be found at
/opt/cross/arm/3.4.5-xscale-softvfp/armv5tel-cacko-linux/include/linux/usb.h
and I've tried using ./configure with both
--x-includes=/opt/cross/arm/3.4.5-xscale-softvfp/armv5tel-cacko-linux/include
--x-includes=/opt/cross/arm/3.4.5-xscale-softvfp/armv5tel-cacko-linux/include/linux
to no avail. How do I make ./configure recognize it?

11

Zaurus - pdaXrom / Python Support

« on: June 17, 2006, 05:29:29 am »

Thanks clofland, sounds good.

To spell out what to do (according to what I found on the web, correct me if wrong):
Find the .pyc files for the modules asked for (on your laptop or on the web, they're platform independent so can be used as is) and copy them to the /usr/lib/python2.* folder on your Zaurus. If you're finding .py files rather than .pyc files, you can generate the .pyc files by compiling the .py files with e.g. "python compileall.py" from a shell prompt.

Well, I'm still stuck. I need the module zlib.py which isn't in the python libraries on my laptop (but test_zlib.py is!?! What is that about?). Found it online, but the very first line in it reads:
from java import util, lang
which generates the error "No module named java". Now the couple of java.py files I have managed to find are different and have no "util" or "lang" in them, so I suspect there is no default java.py module. What is the problem I need to fix here?

12

Zaurus - pdaXrom / Python Support

« on: June 16, 2006, 01:29:29 am »

Installing any Python module on pdaXrom

A Python ignoramus wants to run a Python application (in my case DCD for telescope control) that requires some modules not found in the standard install. What is the way to go about finding and installing the required modules? Do you have to find an ipk that is specific to pdaXrom and the Python version? Can you use the .py-files in the cross compiler environment library and if so, how? I don't know what "installing a python module" actually means...