--- Comment #8 from joshudson at gmail dot com 2006-04-22 23:28 ---
The code that calls all the "asmlinkage" calls does so through a vector table.
Consequently, it does not know how many arguments it calls. However, the
arguments live in particular registers when called,
Version: 4.0.1
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joshudson at gmail dot com
GCC host triplet: Multiple
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24727
--- Comment #2 from joshudson at gmail dot com 2005-11-08 04:25 ---
Aren't function arguments contravariant rather than covariant?
--
joshudson at gmail dot com changed:
What|Removed |
ity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: joshudson at gmail dot com
Target Milestone: ---
spurious warning on right shift constant > integer when code would be
eliminated by optimization step because it is only rea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85962
--- Comment #1 from Joshua ---
(first three lines is because you don't want bug reports with external header
files--3 lines is a lot better than all of stdint.h and limits.h)
Assignee: unassigned at gcc dot gnu.org
Reporter: joshudson at gmail dot com
Target Milestone: ---
Created attachment 59073
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59073&action=edit
main reproduction source file
GCC Version: gcc (Debian 12.2.0-14) 12.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116642
--- Comment #1 from Joshua ---
Created attachment 59074
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59074&action=edit
runtime required to build nutty.i all the way to an executable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116642
--- Comment #2 from Joshua ---
Created attachment 59075
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59075&action=edit
linker script used to build nutty.i (don't know if requried or not to build
executable)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116642
--- Comment #8 from Joshua ---
I am absolutely certain declaring new local variables inside the vfork() block
is kosher.
Modifying variables outside the vfork() block simply requires marking them
volatile; in this the rule is the same as setjmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116642
--- Comment #9 from Joshua ---
Update: vfork is not the problem. If the function is _called_ vfork the bug
happens. The bug remains if I update package.s to use __NR_fork instead of
__NR_vfork.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116642
--- Comment #11 from Joshua ---
So far I have the following.
I have modified the asm stub so that vfork() is an alias for fork(); of course
gcc doesn't know about that, and that's the point.
If I remove -ffreestanding I can verify the asm is c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116642
--- Comment #12 from Joshua ---
I located the actual bug in the disassembly. While it is somehow caused by
vfork; it is not due to vfork or vfork rules. The bad assembly code is here.
.LC16:
.quad .LC7
You can't *do* that in this env
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116642
--- Comment #14 from Joshua ---
Is this just a doc problem then?
It says I must use -fpie to make a relocatable executable.
I need a relocatable executable with no relocations. There is nothing in source
code requiring a relocation, so I am su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116642
--- Comment #16 from Joshua ---
I took out -fpie and the output assembly was different and the binary started
working. That is contrary to the documentation which says you need -fpie for
position independent executables.
I suppose it would be a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116642
--- Comment #18 from Joshua ---
I stand corrected. I removed -pie.
The resulting output binary is still relocatable in memory. I don't think the
Kernel is willing to load an ELF binary at address 0, and that's the only other
option with this he
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116642
--- Comment #21 from Joshua ---
Well then; I guess I'm having pain every time I upgrade the compiler no matter
what.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116642
--- Comment #25 from Joshua ---
Guys, I goofed and don't know what I actually did.
I failed to reset one of the other hypotheses after finding the problem in the
disassembly. On re-unpacking the archive containing the reproduction I
uploaded, t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116642
--- Comment #26 from Joshua ---
I've been wondering how to fix this item. Having found the faulting assembly
code; vfork is incidental to the problem. Removing vfork simply preterbs it
away not actually fixing.
I actually hit this once before w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116642
--- Comment #32 from Joshua ---
>> Build your program as a static PIE and use assembly
>> (or a very limited C subset) to relocate itself on startup.
> All other implementations (Glibc, Musl, and Linux kernel
> with KASLR enabled on modern arch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116642
--- Comment #33 from Joshua ---
Florin wrote:
> It's quite brittle and requires constant maintenance as the compiler
> changes. We've simplified the code significantly of the past few years
> and may finally be able to properly fix it, as far
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: joshudson at gmail dot com
Target Milestone: ---
The following code fragment demonstrates the problem:
extern int execve2(const char *name, const char**args, const char **environ);
int function()
{
const char
21 matches
Mail list logo
