pdf viewer for pdaxrom?

[offroadgeek]

FYI - I've split the pdf viewer posts from the 'status update' thread, as they really belong in their own thread.

[amrein]

Thanks offroadgeek. I couldn't add any other post in the other thread without been of topic.

The xpdf crashing on pdaXrom is a memory access processor issue. This is related to the ARM processor design. Those kind or bugs are hard to find in source code, even hardder when the source code is not yours, even harder when there are a lot of memory pointer for document handling.

I'm not a gnu debugger virtuoso so the copyrigthed sentence "Soon! Keep tuned" is certainly a good one to say.

[alan]

FYI - I've split the pdf viewer posts from the 'status update' thread, as they really belong in their own thread.

I think Laze and Sash should think about all this : did you notice how implicated we are in this rom ? You say " think about a pdf viewer", and everyone post here their own idea... I mean, that is wonderful ! Maybe you should rely on us a little bit more when you think about progs that you don't have time to work on.

I think everyone can understand you  and your close team want to keep the rom itself under your own controle : it's difficult enough to have two developpers agree ! But when you think about a program that is needed, just say it !

[sonicbuddha]

Has anyone worked with compiling ghostscript for the pdaXrom?  I use it at work all the time to read pdfs on my Linux box.   If I have time later, I might work on it myself, but I thought I'd throw it out there as a suggestion for anyone else working on this project.

Allow me to add:  As I have been using it, gs is actually being called from kghostview, part of the kde desktop, when used as a pdf viewer.  But it can also be used from the command line, so a wrapper can easily be used.  There is also gv and ghostview as graphical front ends.

[Laze]

offroadgeek: Thanks for splitting i haven't had the time yet..

Basically anyone is free to build a PDF reader or anything for the pdaXrom - Sash has been looking at the xpdf reader and as amrein states its basically a mem problem. Anyone who has a small (<1-2 MB) pdf file which is causing problems?

[ikm]

The xpdf crashing on pdaXrom is a memory access processor issue. This is related to the ARM processor design. Those kind or bugs are hard to find in source code, even hardder when the source code is not yours, even harder when there are a lot of memory pointer for document handling.

Yep, these problems seem likely to be caused by the unaligned memory accesses, which are not handled correctly by the ARM processor. There is a handy gcc's option to hunt down memory alignment problems such as these:

Code: [Select]

      -Wcast-align
           Warn whenever a pointer is cast such that the required alignment of
           the target is increased.  For example, warn if a "char *" is cast
           to an "int *" on machines where integers can only be accessed at
           two- or four-byte boundaries.
It creates much false positives, but it still is easier than just reading all the code

[amrein]

Here is what happened so far in my spare time trying to debug xpdf:

_ First, I compiled xpdf for pdaXrom using the official rc5 cross-compiler. The resulting xpdf was doing illegal memory access too while loading specific pdf file (mean killed with segmentation fault).  To try to correct this, I used patches from Debian Unstable but xpdf was still segfault. Used patches from Mandrakelinux. Same thing. Used both patches . No change.

_ So I really needed to find a way to debug the application. As I didn't know gdb at all I played with it a bit on x86 PC. Loading, running, breaking, stepping, listing... used gdb graphical front-end like kdbg or ddd too. All this worked well (even if the gdbui provided with my Linux distribution gdb x86 package segfault too on x86 .

_ Back on xpdf debuging for pdaXrom. There is no gdb for arm in pdaxromsdk-1.1.0-softfloat.tar.bz2. This is a missing application for the x86 sdk. To correct this, I recompiled gdb with "./configure --target armv5tel-cacko-linux". But there is a problem with the resulting armv5tel-cacko-linux-gdb: only “target sim” (mean arm simulator) will work to debug arm program directly on x86 machine. To use this arm simulator, gdb need to load a complete pdaXrom image. This mean to recompile a kernel  without specific patches at least. To use remote X11, would need to build a small filesystem with default libraries (without specific Zaurus patches), a network simulated card to be able debug remote X11 connection of xpdf or to find a way to have a simulated  framebuffer...  To big to do so I tryied other solutions.

_ Tried to run gdb arm coming from the rc5 feed. This is a Zaurus package (installed with “ipkg install gdb”). Problem: I can load and run xpdf in this Zaurus gdb version but but I didn't succeed in adding a break point. I can list the source with the list command but “break 132” “run” will just run the program straight to the end.  Breakpoints are just ignored. So now I needed to debug gdb to find how to fix this issue before been able to debug xpdf. A jocke . Well, let see if I can find other solution.

_ Ok. Next, installed gdb-server from rc5 feed to do remote debuggin. The problem: gdb-server is nothing else than a shrank gdb with remote protocol capacity. Used the x86 gdb version compiled for pdaXrom and on the Zaurus the gdb-server. The gdb version doesn't match but the connection is made. This time I can't display the application source code (mean the list command doesn't work). Searched for a solution but nothing found. The debug information are not used. The Zaurus gdb handles correctly the list command but not the gdb-server with my current x86 remote gdb. Without code listing it's a bit difficult to add breakpoints and to step into C source. :/

_ Next step for this afternoon: recompile gdb and gdb-server for pdaXrom using my current gdb source code version. This way, the remote gdb-server and local gdb won't have any excuse for incompatibility. If I still have issue than... well... I will have to ask to you people if you know a gdb version that work. The jocke could have been to try to debug the Zaurus gdb-server or gdb remotely.

If someone want to play too on this, well..., there is space for everyone. I you can espect, I'm not a guru and I'm doing all this for fun (and for yours).

(the last step could be to play with asertion and printf all over the source code... but this takes more time and need)

[amrein]

Ok so:

_ No information about how to get symbols with gdbserver in default gdb info page but http://www.delorie.com/gnu/docs/gdb/gdbserver.1.html show that I needed to run the remote x86 gdb with the binary name. The binary with debug information need to be on the pc. Now I can remote debug xpdf (even if the gdb versions don't match).

_ There is a bug in the arm gdb binary provided in rc5 gdb_6.0_armv5tel.ipk. The fix exist in Linux distributions but haven't been applyied upstream (not applyied on 6.0, nor 6.1 nor 6.2). Recompiled gdb from source and now I can debug on the device too without issue. I guess this will be added to the next native Zaurus gcc package. Keep tuned © TT.

_ Well, no excuse now for not finding the xpdf bug  

[osteron]

My problems with xpdf segfaulting dissappeared as i took the libfreetype.so.6.3.4 from a qpdf package instead of the libfreetype.so.6.3.7 included in pdaxrom

at least i can open the files i need for my studies

only some fonts were not displayed so i copied type1 fonts from my pc to the zaurus and edited the config file

[richardh]

Osteron,

Could you be more specific on the location you found the lib that you changed, fonts added and conf file edited? I would really like to use my zaurus on some SANS security pdfs to study for upcoming exams.. perhaps you have found what I need.

Thanks,

-Richard

[osteron]

i extracted libfreetype.so.6.3.4 from this package
http://prdownloads.sourceforge.net/qpdf2/q...rm.ipk?download
copied it to /usr/lib/ and linked libfreetype.so and libfreetype.so.6 to it

for the fonts i looked in /etc/xpdfrc and copied all displayFontT1 fonts from my pc and uncommented the lines

[omega]

The biggest problem with PDAXROM has now been almost totally fixed. I will elaborate on the work done above, and hopefully someone with more time than I currently will make an ipk of the changes - to provide pdf viewer for all.

First of, stock xpdf 3.00.

Download libfreetype.so.6.3.4 and simlink it to libfreetype.so and libfreetype.so.6... As described above this solves all segmentation faults, loading several different sizes of pdfs up to 5.5megs (all i had handy), including graphics heavy ones.  

Next, when i opened most pdfs i never had text which made it quite useless. I have not had time to completely get all the font files. A ghostscipt fonts package needs to be unpacked and the relevant type 1 font files removed.

I have found fonts with filenames such as n0210031.pfb from google and uncommented / edited the xpdfrc file in /etc to point to these new TYPE1 fonts.

This seems to provide a fully functional pdf viewer... hope it helps everyone.

I miss the text extraction functionality from the qpdf2, any ideas?

[scoutme]

Glad to hear about what you got.

Do you think you could prepare an archive - a simple zip, for example - with the config file, the fonts and the library (and a small readme with the info you already wrote in the last post)?

If you cannot use the forum to share it, and you don't want to spend too much time, just send it to me, and I'll manage to send the file to those interested (I might open a new thread for collecting requests).

Let me know


scoutme

[omega]

I am going to upload it now, give me a few minutes (noisy 28k in the country...)  Got a zip file, and i also wrote a script.

[omega]

I can't upload with either firebird or internet explorer... do i need an account? It comes up with page not displayed... will find some webspace after...