Rusty Russell wrote:
On Wed, 2007-04-04 at 23:14 -0400, Steven Rostedt wrote:
On Wed, 2007-04-04 at 23:06 -0400, Kyle Moffett wrote:
(Erk, I wonder what I was thinking when I wrote that?) Can I ask
for %#x (or 0x%x)? I'm easily confused.
How about %p for pointers?
But that would require
H. Peter Anvin wrote:
Rusty Russell wrote:
On Wed, 2007-04-04 at 23:14 -0400, Steven Rostedt wrote:
On Wed, 2007-04-04 at 23:06 -0400, Kyle Moffett wrote:
(Erk, I wonder what I was thinking when I wrote that?) Can I ask
for %#x (or 0x%x)? I'm easily confused.
How about %p for pointers?
The patch looks nice and clean. However, it does not relocate the symbol
table(s) values. I thought that was done in an earlier version of this I
saw, but I might be misremembering. Though not fatal, this is a regression
from the previous CONFIG_COMPAT_VDSO behavior. It will show up in things
Roland McGrath wrote:
The patch looks nice and clean. However, it does not relocate the symbol
table(s) values. I thought that was done in an earlier version of this I
saw, but I might be misremembering. Though not fatal, this is a regression
from the previous CONFIG_COMPAT_VDSO behavior.
+static __cpuinit void reloc_dyn(Elf32_Ehdr *ehdr, unsigned offset)
+{
+ Elf32_Dyn *dyn = (void *)ehdr + offset;
+
+ for(; dyn-d_tag != DT_NULL; dyn++)
+ switch(dyn-d_tag) {
+ case DT_PLTGOT:
+ case DT_HASH:
+ case DT_STRTAB:
+
Jeremy Fitzhardinge [EMAIL PROTECTED] 05.04.07 09:31
Jan Beulich wrote:
While there's a certain level of control on what DT_* may appear in the
vDSO, not even considering other than the above types seems fragile to
me. Since future additions to the set are supposedly following a fixed
scheme
Dear All,
In this few days, I got emails from this list. I tried to exclude thru
majordomo, but it failed.
Kindly need your help to exclude me from this list.
Thank You,
CR
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jeremy
Fitzhardinge
Sent:
In addition to Roland's remarks about missing symbol table relocation, I
would also assume section headers, if present, should be relocated.
Yes, and also the .symtab as well as .dynsym just in case one ever has one
(though I think they are built stripped now, it's not hard to check sh_type
for
I did the second patch because I could, and to see if it would provoke
some comment. But effectively removing a kernel config option seems
like a good idea to me.
Well, it provoked me to care whether the first patch the relocation
really right.
Thanks,
Roland
Roland McGrath wrote:
In addition to Roland's remarks about missing symbol table relocation, I
would also assume section headers, if present, should be relocated.
Yes, and also the .symtab as well as .dynsym just in case one ever has one
(though I think they are built stripped now, it's
+ for(; dyn-d_tag != DT_NULL; dyn++)
+ switch(dyn-d_tag) {
+ case DT_PLTGOT:
+ case DT_HASH:
+ case DT_STRTAB:
+ case DT_SYMTAB:
+ case DT_RELA:
+ case DT_INIT:
+ case DT_FINI:
+
and here's the new patch, merging rusty's suggestions and some more on my own.
May I upload this, or does Rusty (or any other) has some more suggestions?
On 4/4/07, Rusty Russell [EMAIL PROTECTED] wrote:
On Wed, 2007-04-04 at 13:03 -0300, Glauber de Oliveira Costa wrote:
This is a new version
Now that relocation of the VDSO for COMPAT_VDSO users is done at
runtime rather than compile time, it is possible to enable/disable
compat mode at runtime.
This patch allows you to enable COMPAT_VDSO mode with vdso=2 on the
kernel command line, or via sysctl. (Switching on a running system
Some versions of libc can't deal with a VDSO which doesn't have its
ELF headers matching its mapped address. COMPAT_VDSO maps the VDSO at
a specific system-wide fixed address. Previously this was all done at
build time, on the grounds that the fixed VDSO address is always at
the top of the
Zachary Amsden wrote:
H. Peter Anvin wrote:
http://www.kernel.org/pub/linux/kernel/people/hpa/new-cpuid-msr.patch
The requested URL /pub/linux/kernel/people/hpa/new-cpuid-msr.patch
was not found on this server.
Fixed.
It's not *quite* that easy. The assembly code around this is
H. Peter Anvin wrote:
This code is almost entirely identical to the setgpr_wrapper in the
patch (except for the fact that setgpr_wrapper sets and captures *ALL*
the GPRs), and it seems rather pointless to use another wrapper. It
takes a pointer to an entrypoint (default to cpuid; ret in
Glauber noticed long delays between hitting a key, and seeing data come
up on the virtual console. Looking into this, I found that the
wake_parent routine that reads from all devices was actually starving
out the parent after sending the parent a signal to wake up.
The thing is, the child which
Zachary Amsden wrote:
H. Peter Anvin wrote:
This code is almost entirely identical to the setgpr_wrapper in the
patch (except for the fact that setgpr_wrapper sets and captures *ALL*
the GPRs), and it seems rather pointless to use another wrapper. It
takes a pointer to an entrypoint
Zachary Amsden wrote:
H. Peter Anvin wrote:
This code is almost entirely identical to the setgpr_wrapper in the
patch (except for the fact that setgpr_wrapper sets and captures *ALL*
the GPRs), and it seems rather pointless to use another wrapper. It
takes a pointer to an entrypoint
H. Peter Anvin wrote:
I guess what I was trying to say was that we'd use setgpr_wrapper in
the case where you have an entrypoint with native (non-C) semantics;
in the other case we'd use an alternative to setgpr_wrapper. Either
way, it sounds like we're talking about implementing
Zachary Amsden wrote:
Or implement anything useful at all ... perhaps it might be useful to
simply wrap them with an -ENOSYS in some cases.
Rusty, Jeremy. Chris - any feedback on MSR support?
I've looked at hpa's patch a bit, but I don't quite get what the point
is yet. Is it that
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
Or implement anything useful at all ... perhaps it might be useful to
simply wrap them with an -ENOSYS in some cases.
Rusty, Jeremy. Chris - any feedback on MSR support?
I've looked at hpa's patch a bit, but I don't quite get what the point
H. Peter Anvin wrote:
Yes, pretty much. There are enough evidence that you can't trust CPU
architecture to stay sane. Inside Transmeta it was a constant battle,
and we were a small company.
Is there any indication that the msr or cpuid instructions will change
in this way? rd/wrmsr is
Rusty Russell wrote:
There is now more than one place where we use the fact that bit 9 of
eflags is the interrupt-enabled flag, so define EFLAGS_IF. We make it
512 so it can be used in asm, too.
How about defining all the other EFLAGS in one place?
-hpa
H. Peter Anvin wrote:
Rusty Russell wrote:
There is now more than one place where we use the fact that bit 9 of
eflags is the interrupt-enabled flag, so define EFLAGS_IF. We make it
512 so it can be used in asm, too.
How about defining all the other EFLAGS in one place?
That
Jeremy Fitzhardinge wrote:
That patch got dropped, and replaced by one which pulled all the flags
definitions out of asm/processor.h
Saw that a little too late :)
In general, it would be nice if the various CPU constants were all
defined in one place, so I'd rather suggest protecting the
On Thu, Apr 05, 2007 at 05:29:52PM -0700, H. Peter Anvin wrote:
Jeremy Fitzhardinge wrote:
That patch got dropped, and replaced by one which pulled all the flags
definitions out of asm/processor.h
Saw that a little too late :)
In general, it would be nice if the various CPU constants
Andi Kleen wrote:
No processor.h is such a hodgepodge of unrelated stuff that any
splitting up is a good thing.
Fair enough. However, I'd still like to see the X86_CR* constants
moved, too (and constants added for at least CR0 as well.)
-hpa
On Thu, 2007-04-05 at 11:43 -0300, Glauber de Oliveira Costa wrote:
and here's the new patch, merging rusty's suggestions and some more on my own.
May I upload this, or does Rusty (or any other) has some more suggestions?
This looks excellent!
There are a couple of extra spaces floating
On Thu, 2007-04-05 at 16:40 -0400, Steven Rostedt wrote:
Glauber noticed long delays between hitting a key, and seeing data come
up on the virtual console. Looking into this, I found that the
wake_parent routine that reads from all devices was actually starving
out the parent after sending
30 matches
Mail list logo
