headers
Steve Langasek | 1 May 2006 04:57
Picon
Favicon

Re: Bug#364231: [parisc-linux] Re: Bug#364231: exception catching broken on HPPA

On Sun, Apr 30, 2006 at 06:53:03PM -0400, John David Anglin wrote:
> > Is this acutally decided?  Is it likely to happen soon, or should I
> > build GMP with gcc 3.3 (which doesn't exhibit the problem) in the
> > short term?

> For now, I suggest that you remove gcc-4.1 from your build system.
> Then, GMP should build fine with 4.0.  You might have to reinstall
> 4.0.

Er, no; we're talking about official Debian packages here, and the
libstdc++.so.6 in Debian is now from gcc-4.1.  The problem is precisely that
GMP *is* being built using gcc-4.0, but libstdc++ is from gcc-4.1, resulting
in the double libgcc_s problem.

So "removing gcc-4.1 from his build system" isn't an option unless we find a
way to do this systemically for Debian.

--

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon <at> debian.org                                   http://www.debian.org/
Permalink | Reply | 0 comments |
headers
John David Anglin | 1 May 2006 15:56
Picon

Re: Bug#364231: [parisc-linux] Re: Bug#364231: exception catching

> Er, no; we're talking about official Debian packages here, and the
> libstdc++.so.6 in Debian is now from gcc-4.1.  The problem is precisely that
> GMP *is* being built using gcc-4.0, but libstdc++ is from gcc-4.1, resulting
> in the double libgcc_s problem.

Then, you must build *eveything* for hppa with gcc-4.1 or later.

Unfortunately, there's an ABI break.  Mixing libraries compiled with
4.0 or earlier with libraries compiled with 4.1 or later is just going
to cause unnecessary problems.   3.3 uses libstdc++.so.5, so you
avoid the double libgcc_s problem building GMP.  However, you still
have the ABI change affecting the passing and return of complex types.

At a fundamental level, libstdc++.so.6, libgfortran.so.1.0.0 and any
other gcc libraries built with 4.1 or later need glibc built with 4.1
to function correctly because of the various complex functions in
the math library.

I think there's a dynamic loader bug here as well.  I'm just
guessing but I think the double libgcc_s problem causes a problem
with the handling of .eh_frame data.

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 | 2 May 2006 14:27
Picon

Bug#364231: [parisc-linux] Re: Bug#364231: exception catching

[should we drop parisc-linux?]

John David Anglin writes:
> > Er, no; we're talking about official Debian packages here, and the
> > libstdc++.so.6 in Debian is now from gcc-4.1.  The problem is precisely that
> > GMP *is* being built using gcc-4.0, but libstdc++ is from gcc-4.1, resulting
> > in the double libgcc_s problem.
> 
> Then, you must build *eveything* for hppa with gcc-4.1 or later.
> 
> Unfortunately, there's an ABI break.  Mixing libraries compiled with
> 4.0 or earlier with libraries compiled with 4.1 or later is just going
> to cause unnecessary problems.   3.3 uses libstdc++.so.5, so you
> avoid the double libgcc_s problem building GMP.  However, you still
> have the ABI change affecting the passing and return of complex types.
> 
> At a fundamental level, libstdc++.so.6, libgfortran.so.1.0.0 and any
> other gcc libraries built with 4.1 or later need glibc built with 4.1
> to function correctly because of the various complex functions in
> the math library.
> 
> I think there's a dynamic loader bug here as well.  I'm just
> guessing but I think the double libgcc_s problem causes a problem
> with the handling of .eh_frame data.

Ok, coming back to the question of the system compiler on hppa for
etch. Assuming that hppa does want to do that:

- is glibc buildable with gcc-4.1 on hppa?
- libstdc++6 would need to conflict with libgcc2, which seems to be
(Continue reading)

Permalink | Reply | 0 comments |
headers
John David Anglin | 2 May 2006 15:49
Picon

Re: Bug#364231: [parisc-linux] Re: Bug#364231: exception catching

> Ok, coming back to the question of the system compiler on hppa for
> etch. Assuming that hppa does want to do that:
> 
> - is glibc buildable with gcc-4.1 on hppa?

As far as I know, there's no new problems using 4.1 instead of 4.0.  See
http://lists.parisc-linux.org/pipermail/parisc-linux/2006-April/028894.html
and test results for a gcc 4.2.0 build using this glibc build
http://lists.parisc-linux.org/pipermail/parisc-linux/2006-April/028918.html

> - libstdc++6 would need to conflict with libgcc2, which seems to be
>   doable, but then rules out g++-3.4 and g++-4.0 as a fallback
>   solution, where g++-4.1 fails.

True.

> - is libffi hit by the ABI change as well?

No.  It's not affected because it doesn't support complex types.

I have one libffi fix that's not yet in 4.2.0 that fixes the remaining
Java testsuite failures.  I haven't tested a backport to 4.1.

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
Aurelien Jarno | 5 May 2006 05:48
Picon
Favicon

Bug#364231: [parisc-linux] Re: Bug#364231: exception catching

Matthias Klose wrote:
> [should we drop parisc-linux?]
> 
> John David Anglin writes:
>>> Er, no; we're talking about official Debian packages here, and the
>>> libstdc++.so.6 in Debian is now from gcc-4.1.  The problem is precisely that
>>> GMP *is* being built using gcc-4.0, but libstdc++ is from gcc-4.1, resulting
>>> in the double libgcc_s problem.
>> Then, you must build *eveything* for hppa with gcc-4.1 or later.
>>
>> Unfortunately, there's an ABI break.  Mixing libraries compiled with
>> 4.0 or earlier with libraries compiled with 4.1 or later is just going
>> to cause unnecessary problems.   3.3 uses libstdc++.so.5, so you
>> avoid the double libgcc_s problem building GMP.  However, you still
>> have the ABI change affecting the passing and return of complex types.
>>
>> At a fundamental level, libstdc++.so.6, libgfortran.so.1.0.0 and any
>> other gcc libraries built with 4.1 or later need glibc built with 4.1
>> to function correctly because of the various complex functions in
>> the math library.
>>
>> I think there's a dynamic loader bug here as well.  I'm just
>> guessing but I think the double libgcc_s problem causes a problem
>> with the handling of .eh_frame data.
> 
> 
> Ok, coming back to the question of the system compiler on hppa for
> etch. Assuming that hppa does want to do that:
> 
> - is glibc buildable with gcc-4.1 on hppa?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Carlos O'Donell | 15 May 2006 03:14
Gravatar

[PATCH] Add TLS support for hppa-linux.

The following patches add TLS support for hppa-linux.

The specification draft for TLS support for hppa-linux is located here:
http://parisc-linux.org/documentation/tls/hppa-tls-implementation.pdf

GCC patches for TLS support are already in place.

GLIBC support is setup except for the final addition of the relocs
to elf/elf.h. Patch has been sent to libc-alpha.

Passes without regressions on hppa-linux.
More specific tests still need to be written.

Ok to commit?

Cheers,
Carlos.
Attachment (Changelog.binutils): application/octet-stream, 2315 bytes
Attachment (patch-binutils-tls-2006-05-15.diff): application/octet-stream, 38 KiB
Permalink | Reply | 0 comments |
headers
Carlos O'Donell | 15 May 2006 03:16
Gravatar

[PATCH] Add TLS relocs for hppa.

The following patch adds the TLS relocations required for hppa.

The specification draft for TLS support under hppa-linux is located here:
http://parisc-linux.org/documentation/tls/hppa-tls-implementation.pdf

Original TeX file:
http://cvs.parisc-linux.org/*checkout*/web/src/documentation/tls/hppa-tls-implementation.tex?content-type=text%2Fplain

Binutils patches are sent and awaiting approval.
GCC patches for TLS support are already in place.
GLIBC support is in place in libc-ports.

Please commit.

Cheers,
Carlos.
Attachment (Changelog.libc): application/octet-stream, 557 bytes
Attachment (patch-glibc-elf-2006-05-15.diff): application/octet-stream, 2355 bytes
Permalink | Reply | 0 comments |
headers
Steven Rostedt | 17 May 2006 11:54
Gravatar

[RFC PATCH 00/09] robust VM per_cpu variables

(I tried to include all arch maintianers and memory maintainers, if I
missed someone, please let me know).

OK, as promised, I've got a working VM percpu solution.

A little history: please read the thread http://lkml.org/lkml/2006/4/14/137

Preivously I noticed that the per_cpu variables were implemented with
a little hack that Rusty Russell wrote up.  I call it a hack because,
for modules an arbitrary number was used to hold all per_cpu variables
that would be used in the kernel or in modules.  If this number was too
big, you waste the memory that is allocated for it, and if it were
too small, you wont be able to load all the modules that are required.

My first attempt to fix this introduced another dereference, to allow
for modules to allocate their own memory.  This was quickly shot down,
and for good reason, because dereferences kill performance, and don't
play nice with large SMP systems that depend on per_cpu being fast.

But that first attempt had one benefit.  It had good responses on how
to actually fix the problem.  Without the first try, I would not have
tried this approach.

So what is this solution?

I now place the per_cpu variables into VM, such that the pages are
only allocated when needed. All the architecture needs to do is
supply a VM address range, size for each CPU to use (note this
implementation expects all the VM CPU areas to be together), and
three functions to allow for allocating page tables at bootup.
(Continue reading)

Permalink | Reply | 14 comments |
headers
Steven Rostedt | 17 May 2006 11:56
Gravatar

[RFC PATCH 01/09] robust VM per_cpu core


This is the VM per_cpu core patch.  It includes the mm/per_cpu.c file
that is used to initialize and update per_cpu variables at startup
and module load.

To use this, the arch must define CONFIG_HAS_VM_PERCPU and
__ARCH_HAS_VM_PERCPU.

Also the following must be defined:

PERCPU_START - start of the percpu VM area
PERCPU_SIZE - size of the percpu VM area for each CPU so that the
		total size would be PERCPU_SIZE * NR_CPUS

As well as the following three functions:

pud_t *pud_boot_alloc(struct mm_struct *mm, pgd_t *pgd, unsigned long addr,
                     int cpu);
pmd_t *pmd_boot_alloc(struct mm_struct *mm, pud_t *pud, unsigned long addr,
                     int cpu);
pte_t *pte_boot_alloc(struct mm_struct *mm, pmd_t *pmd, unsigned long addr,
                     int cpu);

The above functions are to allocate page tables from bootmem because the
percpu is initialized right after setup_arch in init/main.c

Signed-off-by: Steven Rostedt <rostedt <at> goodmis.org>

Index: linux-2.6.16-test/mm/percpu.c
===================================================================
(Continue reading)

Permalink | Reply | 3 comments |
headers
Steven Rostedt | 17 May 2006 11:56
Gravatar

[RFC PATCH 01/09] robust VM per_cpu mm header update

This patch declares the three functions needed by the archs to
implement the percpu VM.

Signed-off-by: Steven Rostedt <rostedt <at> goodmis.org>

Index: linux-2.6.16-test/include/linux/mm.h
===================================================================
--- linux-2.6.16-test.orig/include/linux/mm.h	2006-05-17 04:32:27.000000000 -0400
+++ linux-2.6.16-test/include/linux/mm.h	2006-05-17 04:56:52.000000000 -0400
 <at>  <at>  -795,6 +795,15  <at>  <at>  int __pmd_alloc(struct mm_struct *mm, pu
 int __pte_alloc(struct mm_struct *mm, pmd_t *pmd, unsigned long address);
 int __pte_alloc_kernel(pmd_t *pmd, unsigned long address);

+#ifdef CONFIG_HAS_VM_PERCPU
+pud_t *pud_boot_alloc(struct mm_struct *mm, pgd_t *pgd, unsigned long addr,
+		      int cpu);
+pmd_t *pmd_boot_alloc(struct mm_struct *mm, pud_t *pud, unsigned long addr,
+		      int cpu);
+pte_t *pte_boot_alloc(struct mm_struct *mm, pmd_t *pmd, unsigned long addr,
+		      int cpu);
+#endif
+
 /*
  * The following ifdef needed to get the 4level-fixup.h header to work.
  * Remove it when 4level-fixup.h has been removed.

-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 0 comments |

Gmane