headers
Randolph Chung | 11 Mar 17:28

Re: [parisc-linux] Re: gcj can't make shared libs on hppa

> The reason for the segmentation fault is the R_PARISC_IPLT isn't
> being handled correctly and the indirect call to the constructor
> for the library branches to the wrong location.

here's what i see....

__do_global_ctors_aux is trying to load a value from the GOT
(__CTORS_LIST i think). I'm seeing that it loads some garbage value
(0x4fd23f01 in my case), and then it tries to do a $dyncall on that.

__do_global_ctors_aux does something like:

addil 0(%r19),%r1
ldw 28(%r1),%ret0
ldw -4(%ret0),%r3
...
copy %r3,%r22
b,l $$dyncall, %r31

$r19+0x28 is 0x41896830; points inside the .plt. seems reasonable

but *(%ret0-4) points inside the text section, so r22 eventually gets 
loaded with an instruction value (0x4fd23f01 == ldw,mb -80(sp),r18)

dunno if this helps with anything... have to think about it somemore to 
see what's happening...

randolph
(Continue reading)

Permalink | Reply | 0 comments |
headers
John David Anglin | 12 Mar 03:10
Picon

Re: [parisc-linux] Re: gcj can't make shared libs on hppa

> but *(%ret0-4) points inside the text section, so r22 eventually gets 
> loaded with an instruction value (0x4fd23f01 == ldw,mb -80(sp),r18)

r22 should be pointing to a function descriptor and have the plabel
bit set.  It's a relative rare situation when an indirect call can
be made directly (no shared libraries).

Dave
--

-- 
J. David Anglin                                  dave.anglin <at> nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
Permalink | Reply | 0 comments |
headers
Miklos Szeredi | 13 Mar 12:26
Picon

Re: Example filesystem fail to init on parisc

> On Fri, Mar 10, 2006 at 12:16:46PM +0100, Miklos Szeredi wrote:
> > Can you try the following patch to the library?
> > 
> > It initializes the memory to some random value (0x28) before the
> > read(), to check if the kernel sets the memory to zero or it doesn't
> > touch the buffer at all.
> 
> Interesting, the kernel is not setting the memory.

OK.  I'm out of ideas, CC-ing parisc-linux, maybe they can help shed
some light on this.

A short summary of the problem:

(for the full thread see:
http://thread.gmane.org/gmane.comp.file-systems.fuse.devel/2833)

FUSE doesn't seem to work on PA-RISC (2.6.15 + pa4 patchset)

The reason appears to be that when the userspace filesystem reads from
the FUSE device, the kernel doesn't copy any data to the userspace
read buffer, though the correct size is returned by read().

FUSE uses a combination of get_user_pages(), kmap_atomic() and
memcpy().  After kunmap_atomic(), flush_dcache_page() is called to
avoid virtual aliasing.  The data in the read buffer is totally
untouched.

Can anyone confirm the above behavior of FUSE on PA-RISC?
(Continue reading)

Permalink | Reply | 0 comments |
headers
John David Anglin | 14 Mar 01:39
Picon

Re: [parisc-linux] Re: gcj can't make shared libs on hppa

> please see http://bugs.debian.org/353346

Should be fixed.  See http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00815.html

Dave
--

-- 
J. David Anglin                                  dave.anglin <at> nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
Permalink | Reply | 0 comments |
headers
Matthias Klose | 14 Mar 12:29
Picon

Re: [parisc-linux] Re: gcj can't make shared libs on hppa

John David Anglin writes:
> > please see http://bugs.debian.org/353346
> 
> Should be fixed.  See http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00815.html

thanks! will be in the next set of packages

  Matthias
Permalink | Reply | 0 comments |
headers
Joel Soete | 14 Mar 17:00
Picon

Re: [parisc-linux] Re: gcj can't make shared libs on hppa

Matthias, JDA,

> John David Anglin writes:
> > > please see http://bugs.debian.org/353346
> > 
> > Should be fixed.  See http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00815.html
> 
> thanks! will be in the next set of packages
> 
isn't there a small typo in clobber part:
+		:					\
+		: "r1", "r2", "r4", "r20", "r21",	\
+		  "r22", "r24", "r24", "r25", "r26",	\
                         ^^^^^  ^^^^^
Even though I never understand the meaming of this option,
 I suppose that the first r24 should be actualy r23?

TIA,
    Joel

-------------------------------------------------------
NOTE! My email address is changing to ... @scarlet.be
Please make the necessary changes in your address book.
Permalink | Reply | 0 comments |
headers
Matthias Klose | 16 Mar 12:49
Picon

Re: [parisc-linux] Re: gcj can't make shared libs on hppa

John David Anglin writes:
> > please see http://bugs.debian.org/353346
> 
> Should be fixed.  See http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00815.html

with this change (and the typo fix), gcj-dbtool segfaults:

(gdb) run -n classmap.db
Starting program: /usr/bin/gcj-dbtool-4.1 -n classmap.db
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 6962)]
[New Thread 32769 (LWP 6965)]
[New Thread 16386 (LWP 6966)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 6962)]
linear_search_fdes (ob=0xbff02054, this_fde=0x4291a780, pc=0x427ed7f3)
    at unwind-dw2-fde.c:776
776     unwind-dw2-fde.c: No such file or directory.
        in unwind-dw2-fde.c
(gdb) bt
#0  linear_search_fdes (ob=0xbff02054, this_fde=0x4291a780, pc=0x427ed7f3)
    at unwind-dw2-fde.c:776
#1  0x400af174 in linear_search_fdes (ob=0xbff02054, this_fde=0x4291a780,
    pc=0x427ed7f3) at unwind-dw2-fde.c:794
Previous frame identical to this frame (corrupt stack?)
Permalink | Reply | 0 comments |
headers
Miklos Szeredi | 16 Mar 14:13
Picon

Re: Example filesystem fail to init on parisc

Jick, Chris,

Can you please try the following module containing the simplified
versions of the fuse device read/write routines?

Copy the attached files into an empty directory, then do 'make' and
'insmod copytest.ko'.

Then do

  cat /proc/fs/test
  echo hello > /proc/fs/test
  dmesg | tail

I get something like this:

~$ cat /proc/fs/test
Hello!
~$ echo hello > /proc/fs/test
~$ dmesg | tail
test_read 0804d848 1024 0
dst: 0804d848 page: c13a9f40 offset: 2120 mapaddr: dd4fa000 ptr: dd4fa848
  test_read: 7
test_read 0804d848 1024 7
  test_read: 0
test_write 080e9008 6 0
src: 080e9008 page: c1167560 offset: 8 mapaddr: cb3ab000 ptr: cb3ab008
<hello
>
  test_write: 6
(Continue reading)

Permalink | Reply | 0 comments |
headers
Grant Grundler | 16 Mar 17:13

Re: [parisc-linux] Re: Example filesystem fail to init on parisc

On Mon, Mar 13, 2006 at 12:26:34PM +0100, Miklos Szeredi wrote:
> OK.  I'm out of ideas, CC-ing parisc-linux, maybe they can help shed
> some light on this.

Miklos,
I took a quick look last week but didn't see anything obvious.
I was suspicious of the memcopy() calls to copy stuff to
user space. But willy me told those are fine if using the
result of kmap() (and then kunmap'ing when done).

In a private conversation someone else said they would
look at it on the weekend.

thanks,
grant

> 
> A short summary of the problem:
> 
> (for the full thread see:
> http://thread.gmane.org/gmane.comp.file-systems.fuse.devel/2833)
> 
> FUSE doesn't seem to work on PA-RISC (2.6.15 + pa4 patchset)
> 
> The reason appears to be that when the userspace filesystem reads from
> the FUSE device, the kernel doesn't copy any data to the userspace
> read buffer, though the correct size is returned by read().
> 
> FUSE uses a combination of get_user_pages(), kmap_atomic() and
> memcpy().  After kunmap_atomic(), flush_dcache_page() is called to
(Continue reading)

Permalink | Reply | 0 comments |
headers
James Bottomley | 16 Mar 17:58
Favicon

Re: [parisc-linux] Re: Example filesystem fail to init on parisc

On Thu, 2006-03-16 at 09:13 -0700, Grant Grundler wrote:
> On Mon, Mar 13, 2006 at 12:26:34PM +0100, Miklos Szeredi wrote:
> > OK.  I'm out of ideas, CC-ing parisc-linux, maybe they can help shed
> > some light on this.
> 
> Miklos,
> I took a quick look last week but didn't see anything obvious.
> I was suspicious of the memcopy() calls to copy stuff to
> user space. But willy me told those are fine if using the
> result of kmap() (and then kunmap'ing when done).

Sorry, meant to reply earlier.

> > The reason appears to be that when the userspace filesystem reads from
> > the FUSE device, the kernel doesn't copy any data to the userspace
> > read buffer, though the correct size is returned by read().
> > 
> > FUSE uses a combination of get_user_pages(), kmap_atomic() and
> > memcpy().  After kunmap_atomic(), flush_dcache_page() is called to
> > avoid virtual aliasing.  The data in the read buffer is totally
> > untouched.

This is wrong.  A VIPT cache requires a mapping to flush on.  If you
kunmap, you've lost the mapping.  What you should do is

kmap()
operate on data
flush_kernel_dcache_page()
kunmap()
(Continue reading)

Permalink | Reply | 0 comments |

Gmane