[Bug libc/5436] New: makecontext doesn't copy longs on x86_64

[Bug libc/5436] New: makecontext doesn't copy longs on x86_64

[rth at gcc dot gnu dot org]

The x86_64 version of makecontext copies ints from va_arg, despite the fact
that copying longs would be just as easy, and more useful.

-- 
           Summary: makecontext doesn't copy longs on x86_64
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: minor
          Priority: P2
         Component: libc
        AssignedTo: drepper at redhat dot com
        ReportedBy: rth at gcc dot gnu dot org
                CC: glibc-bugs at sources dot redhat dot com
GCC target triplet: x86_64-linux


http://sourceware.org/bugzilla/show_bug.cgi?id=5436

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/5436] makecontext doesn't copy longs on x86_64

[jakub at redhat dot com]

------- Additional Comments From jakub at redhat dot com  2007-11-30 20:10 -------
Yeah, I know it sucks, but that's what POSIX requires:
The application  shall  ensure that the value of argc matches the number of
arguments of type int passed to func; otherwise, the behavior is  undefined.

So, we'd need a different entrypoint for this, and libgomp would need to have
a fallback to the standard makecontext anyway.

Can't you use just an int index and some wrapper function which will from that
index find in the list of current team resp. thread tasks what fn to call and
what argument should be given to it?

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=5436

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/5436] makecontext doesn't copy longs on x86_64

[jakub at redhat dot com]

------- Additional Comments From jakub at redhat dot com  2007-11-30 20:12 -------
Or alternatively synthetize a pointer from two consecutive int arguments...


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=5436

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/5436] makecontext doesn't copy longs on x86_64

[rth at gcc dot gnu dot org]

------- Additional Comments From rth at gcc dot gnu dot org  2007-11-30 21:18 -------
I don't actually need to pass any arguments from libgomp, as the value can
be placed in TLS in the first place.  I just noticed this while examining
the implementations.

The reason why I posted this bug is that we do *not* need two separate
entry points.  The x86_64 argument slot size is *always* 64 bits.  You
can copy that 64 bits  and get the right answer for both "int", "long"
and "void*" typed arguments.  The fact that the upper 32-bits of an
"int" argument, within the 64-bit slot, is undefined is immaterial.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=5436

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/5436] makecontext doesn't copy longs on x86_64

[drepper at redhat dot com]

------- Additional Comments From drepper at redhat dot com  2007-11-30 22:19 -------
(In reply to comment #3)
> The reason why I posted this bug is that we do *not* need two separate
> entry points.

Correct, but what Jakub probably meant is that if we would implement it like
this (i.e., copy long), programs come to rely on it and they will not work
everywhere because they are using the interface incorrectly.  That's at least
the reason the code is as it is today.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=5436

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/5436] makecontext doesn't copy longs on x86_64

[drepper at redhat dot com]

------- Additional Comments From drepper at redhat dot com  2008-04-09 18:38 -------
I changed the code, we copy 64-bit values now.  This will be incompatible
between architectures and platforms but since there is no better alternative
available I see no reason why x86-64 should be penalized for that.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


http://sourceware.org/bugzilla/show_bug.cgi?id=5436

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.