Why is the content of argv, on the stack? why not on data section?
since its on the stack..say, i have
argv[] = "HELLO WORLD";
need to push "HELL"
push "O WO";
push "RLD";
right? or is there any other mechanism to load t
> OK.
Thanks, committed.
DJ Delorie wrote:
> How about this?
OK.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
How about this?
--- gcc/gcc/gcc/testsuite/gcc.c-torture/execute/pr36321.c 2008-07-23
00:21:31.0 -0400
+++ ./pr36321.c 2008-11-24 13:46:04.0 -0500
@@ -17,7 +17,9 @@
}
+static char * volatile argp = "pr36321.x";
+
int main(int argc, char **argv)
{
- f
Mark Mitchell <[EMAIL PROTECTED]> writes:
> Andreas Schwab wrote:
>> Mark Mitchell <[EMAIL PROTECTED]> writes:
>>
>>> However, I think an even better fix is just to hard-code the string and
>>> make it volatile. Presumably, the use of argv[
Andreas Schwab wrote:
> Mark Mitchell <[EMAIL PROTECTED]> writes:
>
>> However, I think an even better fix is just to hard-code the string and
>> make it volatile. Presumably, the use of argv[0] here is just to keep
>> the compiler from optimizing the prog
Mark Mitchell <[EMAIL PROTECTED]> writes:
> However, I think an even better fix is just to hard-code the string and
> make it volatile. Presumably, the use of argv[0] here is just to keep
> the compiler from optimizing the program away. So, I suggest doing
> something like:
&
Paul Brook wrote:
> foo (argv[0]);
> I'd say it's a broken test then.
It's a broken program, in full generality.
DJ, you could fix this either by checking argc != 0 in the test, or by
adding an effective-target condition that the test be run only on
targets that p
On Tuesday 18 November 2008, DJ Delorie wrote:
> > I think a more relevant question is whether it's ok to pass 0, {NULL} for
> > argc, argv.
>
> You can do that on desktop linux, you know:
>
> execl(some_prog_name, NULL);
>
> argv[0] is NOT guaranteed to b
> I think a more relevant question is whether it's ok to pass 0, {NULL} for
> argc, argv.
You can do that on desktop linux, you know:
execl(some_prog_name, NULL);
argv[0] is NOT guaranteed to be non-NULL:
ISO/IEC 9899:1999(E) 5.1.2.2.1
2 If they are declared, the parame
> What are the expectations here? Do we expect simulators to set up
> argv[0]? (the m32c BSP acts like you're on real hardware) Do we expect
> simulators to blithely ignore NULL pointer references?
I think a more relevant question is whether it's ok to pass 0, {NULL} for
gcc.c-torture/execute/pr36321.c fails on m32c because the simulator
doesn't set argv[0] *and* the simulator has NULL pointer detection:
void foo(char *str)
{
int len2 = strlen (str);
. . .
int main(int argc, char **argv)
{
foo
Hi,
is it a known bug that `main' function (and so even specially compiled with the
specific prologue/epilogue) missing DWARF `DW_AT_location' for its `argc' and
`argv' on 32-bit targets? I did not find a Bugzilla entry for it.
affected: x86_64-redhat-linux with -m32, i
13 matches
Mail list logo
