Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Linux: Kernel

make headers_install headers problem on sparc64

 

 

Linux kernel RSS feed   Index | Next | Previous | View Threaded


andrew at walrond

Oct 18, 2006, 3:37 PM

Post #1 of 9 (737 views)
Permalink
make headers_install headers problem on sparc64

Hi david, lkml.

I found a message where you said

"If you have problems with the exported headers (other
than that some userspace abuses headers which it shouldn't), then
_shout_. Please don't just let them go unreported."

So,

Using headers exported from vanilla linux 2.6.18.1 and compiling the
elftoaout part of the debian sparc-utils package, I get some breakage
here:

In file included from /usr/include/asm/elf.h:5,
from /usr/include/linux/elf.h:7,
from elftoaout.c:24:

due to tlb_type, cheetah et al being undefined in this part of
asm-sparc64/elf.h:


bash-3.1# tail -n30 /pkg/linux/include/asm-sparc64/elf.h

/* This yields a mask that user programs can use to figure out what
instruction set this cpu supports. */

/* On Ultra, we support all of the v8 capabilities. */
static __inline__ unsigned int sparc64_elf_hwcap(void)
{
unsigned int cap = (HWCAP_SPARC_FLUSH | HWCAP_SPARC_STBAR |
HWCAP_SPARC_SWAP | HWCAP_SPARC_MULDIV |
HWCAP_SPARC_V9);

if (tlb_type == cheetah || tlb_type == cheetah_plus)
cap |= HWCAP_SPARC_ULTRA3;
else if (tlb_type == hypervisor)
cap |= HWCAP_SPARC_BLKINIT;

return cap;
}

#define ELF_HWCAP sparc64_elf_hwcap();

/* This yields a string that ld.so will use to load implementation
specific libraries for optimization. This is more specific in
intent than poking at uname or /proc/cpuinfo. */

#define ELF_PLATFORM (NULL)


#endif /* !(__ASM_SPARC64_ELF_H) */



Hope this is useful

Andrew Walrond
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


dwmw2 at infradead

Oct 19, 2006, 12:50 AM

Post #2 of 9 (718 views)
Permalink
Re: make headers_install headers problem on sparc64 [In reply to]

On Wed, 2006-10-18 at 22:37 +0000, andrew [at] walrond wrote:
> Hi david, lkml.
>
> I found a message where you said
>
> "If you have problems with the exported headers (other
> than that some userspace abuses headers which it shouldn't), then
> _shout_. Please don't just let them go unreported."

Thank you.

> So,
>
> Using headers exported from vanilla linux 2.6.18.1 and compiling the
> elftoaout part of the debian sparc-utils package, I get some breakage
> here:
>
> In file included from /usr/include/asm/elf.h:5,
> from /usr/include/linux/elf.h:7,
> from elftoaout.c:24:
>
> due to tlb_type, cheetah et al being undefined in this part of
> asm-sparc64/elf.h:
>
>

Hm, yes. There's still a lot of crap being exposed there that we really
don't need to be showing. Try this entirely untested patch...

The sparc64 version could do with something similar, too.


----
[SPARC] Clean up asm-sparc/elf.h pollution in userspace.

We don't need to export sparc_elf_hwcap() to userspace, and it doesn't
build there. Remove it by moving it inside #ifdef __KERNEL__, along with
some other things which don't need to be exported.

Signed-off-by: David Woodhouse <dwmw2 [at] infradead>

diff --git a/include/asm-sparc/elf.h b/include/asm-sparc/elf.h
index 83a3dd1..aaf6ef4 100644
--- a/include/asm-sparc/elf.h
+++ b/include/asm-sparc/elf.h
@@ -8,11 +8,6 @@ #define __ASMSPARC_ELF_H

#include <asm/ptrace.h>

-#ifdef __KERNEL__
-#include <asm/mbus.h>
-#include <asm/uaccess.h>
-#endif
-
/*
* Sparc section types
*/
@@ -77,6 +72,23 @@ typedef unsigned long elf_greg_t;
#define ELF_NGREG 38
typedef elf_greg_t elf_gregset_t[ELF_NGREG];

+typedef struct {
+ union {
+ unsigned long pr_regs[32];
+ double pr_dregs[16];
+ } pr_fr;
+ unsigned long __unused;
+ unsigned long pr_fsr;
+ unsigned char pr_qcnt;
+ unsigned char pr_q_entrysize;
+ unsigned char pr_en;
+ unsigned int pr_q[64];
+} elf_fpregset_t;
+
+#ifdef __KERNEL__
+#include <asm/mbus.h>
+#include <asm/uaccess.h>
+
/* Format is:
* G0 --> G7
* O0 --> O7
@@ -99,20 +111,7 @@ do { unsigned long *dest = &(__elf_regs[
dest[34] = src->npc; \
dest[35] = src->y; \
dest[36] = dest[37] = 0; /* XXX */ \
-} while(0); /* Janitors: Don't touch this colon. */
-
-typedef struct {
- union {
- unsigned long pr_regs[32];
- double pr_dregs[16];
- } pr_fr;
- unsigned long __unused;
- unsigned long pr_fsr;
- unsigned char pr_qcnt;
- unsigned char pr_q_entrysize;
- unsigned char pr_en;
- unsigned int pr_q[64];
-} elf_fpregset_t;
+} while(0); /* Janitors: Don't touch this semicolon. */

#define ELF_CORE_COPY_TASK_REGS(__tsk, __elf_regs) \
({ ELF_CORE_COPY_REGS((*(__elf_regs)), (__tsk)->thread.kregs); 1; })
@@ -165,8 +164,8 @@ #define ELF_HWCAP ((ARCH_SUN4C_SUN4) ? 0

#define ELF_PLATFORM (NULL)

-#ifdef __KERNEL__
#define SET_PERSONALITY(ex, ibcs2) set_personality((ibcs2)?PER_SVR4:PER_LINUX)
-#endif
+
+#endif /* __KERNEL__ */

#endif /* !(__ASMSPARC_ELF_H) */


--
dwmw2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


andrew at walrond

Oct 19, 2006, 2:03 AM

Post #3 of 9 (712 views)
Permalink
Re: make headers_install headers problem on sparc64 [In reply to]

On Thu, Oct 19, 2006 at 08:50:22AM +0100, David Woodhouse wrote:
>
> Hm, yes. There's still a lot of crap being exposed there that we really
> don't need to be showing. Try this entirely untested patch...
>
> The sparc64 version could do with something similar, too.
>

I'm on sparc64 (pure 64bit) so I can't test your patch. For reference,
I used this (not as smart as yours) patch:

diff -Naur linux-2.6.18.1/include/asm-sparc64/elf.h linux-2.6.18.1-fix/include/asm-sparc64/elf.h
--- linux-2.6.18.1/include/asm-sparc64/elf.h 2006-09-20 03:42:06.000000000 +0000
+++ linux-2.6.18.1-fix/include/asm-sparc64/elf.h 2006-10-19 08:57:11.000000000 +0000
@@ -142,6 +142,7 @@
#define ELF_ET_DYN_BASE 0x0000010000000000UL
#endif

+#ifdef __KERNEL__

/* This yields a mask that user programs can use to figure out what
instruction set this cpu supports. */
@@ -163,6 +164,8 @@

#define ELF_HWCAP sparc64_elf_hwcap();

+#endif
+
/* This yields a string that ld.so will use to load implementation
specific libraries for optimization. This is more specific in
intent than poking at uname or /proc/cpuinfo. */



Andrew Walrond
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


andrew at walrond

Oct 19, 2006, 3:54 AM

Post #4 of 9 (725 views)
Permalink
Re: make headers_install headers problem on sparc64 [In reply to]

Another problem; when compiling reiserfsprogs 3.6.19 there is a header
missing:

../include/reiserfs_fs.h:41:27: error: asm/unaligned.h: No such file
or directory


I see this file exists in the kernel sources, but not in the exported
headers.

Andrew
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


andrew at walrond

Oct 19, 2006, 4:10 AM

Post #5 of 9 (709 views)
Permalink
Re: make headers_install headers problem on sparc64 [In reply to]

On Thu, Oct 19, 2006 at 10:54:41AM +0000, andrew [at] walrond wrote:
>
> Another problem; when compiling reiserfsprogs 3.6.19 there is a header
> missing:
>
> ../include/reiserfs_fs.h:41:27: error: asm/unaligned.h: No such file
> or directory
>
>
> I see this file exists in the kernel sources, but not in the exported
> headers.
>

Simply copying asm-generic/unaligned.h into the sanitised header tree
under asm/ solves the problem, so should headers_install just include
unaligned.h ?

> Andrew

PS Great job BTW; I have encountered amazingly few problems using the
sanitised headers created with headers_install.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


dwmw2 at infradead

Oct 19, 2006, 4:34 AM

Post #6 of 9 (708 views)
Permalink
Re: make headers_install headers problem on sparc64 [In reply to]

On Thu, 2006-10-19 at 11:10 +0000, andrew [at] walrond wrote:
> Simply copying asm-generic/unaligned.h into the sanitised header tree
> under asm/ solves the problem, so should headers_install just include
> unaligned.h ?

No. That header should not be exposed to userspace. Just fix
reiserfsprogs instead. It's not as if unaligned access is _hard_ -- you
just have to ask the compiler to do it for you:

http://cvs.fedora.redhat.com/viewcvs/rpms/reiserfs-utils/devel/header-fix.patch?view=markup

--
dwmw2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


andrew at walrond

Oct 19, 2006, 4:37 AM

Post #7 of 9 (704 views)
Permalink
Re: make headers_install headers problem on sparc64 [In reply to]

On Thu, Oct 19, 2006 at 12:34:32PM +0100, David Woodhouse wrote:
>
> No. That header should not be exposed to userspace. Just fix
> reiserfsprogs instead. It's not as if unaligned access is _hard_ -- you
> just have to ask the compiler to do it for you:
>
> http://cvs.fedora.redhat.com/viewcvs/rpms/reiserfs-utils/devel/header-fix.patch?view=markup
>
Thanks for the link

Andrew
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


dwmw2 at infradead

Oct 19, 2006, 4:43 AM

Post #8 of 9 (706 views)
Permalink
Re: make headers_install headers problem on sparc64 [In reply to]

On Thu, 2006-10-19 at 11:37 +0000, andrew [at] walrond wrote:
> On Thu, Oct 19, 2006 at 12:34:32PM +0100, David Woodhouse wrote:
> >
> > No. That header should not be exposed to userspace. Just fix
> > reiserfsprogs instead. It's not as if unaligned access is _hard_ -- you
> > just have to ask the compiler to do it for you:
> >
> > http://cvs.fedora.redhat.com/viewcvs/rpms/reiserfs-utils/devel/header-fix.patch?view=markup
> >
> Thanks for the link

Fedora Core 6 is already shipping with the output of 'make
headers_install'. This means that in general, if userspace is
misbehaving and it's something we ship in Fedora Core, Extras or Livna,
we're going to have fixed it up already. So Fedora CVS is a good place
to look, although such fixes all should have been pushed upstream rather
than just languishing in our packages.

--
dwmw2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


vapier.adi at gmail

Dec 30, 2006, 2:38 AM

Post #9 of 9 (619 views)
Permalink
Re: make headers_install headers problem on sparc64 [In reply to]

On 10/19/06, David Woodhouse <dwmw2 [at] infradead> wrote:
> No. That header should not be exposed to userspace. Just fix
> reiserfsprogs instead. It's not as if unaligned access is _hard_ -- you
> just have to ask the compiler to do it for you:

reiserfsprogs 3.6.20 already handles the case where asm/unaligned.h
isnt installed ... i just wouldnt suggest using that version as it
wont even compile on big endian machines and doesnt work with
non-standard journals ;)
-mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Linux kernel RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.