argv

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 t

[testsuite, obvious] Fix gcc.dg/pr92301.c on targets that don't support argc/argv.

I've checked in this trivial patch to fix another test failure I found on nios2-elf, due to the BSP we use for simulator testing on this target not having support for argc/argv. This testcase doesn't actually use any command-line arguments and I think just does the argc test to avoid

Re: [DRIVER PATCH]: Nadger subprocess argv[0]

inside a build log, the poor user can be more confused as to what this > cc1plus thing might be). My inclination is that, whatever you do with argv[0], it's a bug for the message to mention cc1plus at all. The fact that there is an executable called cc1plus is an implementation de

[Bug driver/29931] following argv[0] symlink in process_command breaks symlinked-together toolchain

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29931 --- Comment #11 from Harald van Dijk --- Thinking about this a bit more, the logic should probably be: pick a file known to exist. libgcc.a could be a good candidate, but there could be better options. Look this up twice, once following

Re: [DRIVER PATCH]: Nadger subprocess argv[0]

Ping? https://gcc.gnu.org/ml/gcc-patches/2019-05/msg00695.html I originally hesitated adding a space, as Martin suggested, so that argv[0] still obviously looked like a single arg. But I'm not opposed to changing that. He's also right that the errors one can get from failing to spawn

Re: [DRIVER PATCH]: Nadger subprocess argv[0]

nfused as to what this cc1plus thing might be). I achieve this by taking advantage of the subprocess spawning taking separate arguments for the program to exec, and the argv[0] value passed to that program.  Because subprocesses can use argv[0] to locate themselves I propagate the directory na

[DRIVER PATCH]: Nadger subprocess argv[0]

chieve this by taking advantage of the subprocess spawning taking separate arguments for the program to exec, and the argv[0] value passed to that program. Because subprocesses can use argv[0] to locate themselves I propagate the directory name, so that remains as before. When using va

[Bug driver/29931] following argv[0] symlink in process_command breaks symlinked-together toolchain

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29931 Eric Gallager changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED

[Bug driver/29931] following argv[0] symlink in process_command breaks symlinked-together toolchain

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29931 Harald van Dijk changed: What|Removed |Added CC||harald at gigawatt dot nl --- Comment

[Bug driver/29931] following argv[0] symlink in process_command breaks symlinked-together toolchain

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29931 Eric Gallager changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|---

[Bug driver/29931] following argv[0] symlink in process_command breaks symlinked-together toolchain

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29931 Eric Gallager changed: What|Removed |Added Status|NEW |WAITING --- Comment #7 from Eric

[Bug driver/29931] following argv[0] symlink in process_command breaks symlinked-together toolchain

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29931 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org ---

Re: [PATCH 1/4] Make argv const char ** in read_md_files etc

On Wed, May 04, 2016 at 04:49:27PM -0400, David Malcolm wrote: > This patch makes the argv param to read_md_files const, needed > so that the RTL frontend can call it on a const char *. > > While we're at it, it similarly makes const the argv for all > of the "main" fun

Re: [PATCH 1/4] Make argv const char ** in read_md_files etc

On Wed, May 4, 2016 at 10:49 PM, David Malcolm <dmalc...@redhat.com> wrote: > This patch makes the argv param to read_md_files const, needed > so that the RTL frontend can call it on a const char *. > > While we're at it, it similarly makes const the argv for all > of

[PATCH 1/4] Make argv const char ** in read_md_files etc

This patch makes the argv param to read_md_files const, needed so that the RTL frontend can call it on a const char *. While we're at it, it similarly makes const the argv for all of the "main" functions of the various gen*. OK for trunk? gcc/ChangeLog: * genattr-comm

Re: [PATCH] libiberty: {count,dup,write}argv: constify argv input slightly

On Sat, Jan 2, 2016 at 10:39 PM, Mike Frysinger wrote: > Would be more useful if we could use "const char * const *", but there's > a long standing bug where gcc warns about incompatible pointers when you > try to pass in "char **". That's not a bug. It's how C works.

Re: [PATCH] libiberty: {count,dup,write}argv: constify argv input slightly

On 05 Jan 2016 07:32, Ian Lance Taylor wrote: > On Sat, Jan 2, 2016 at 10:39 PM, Mike Frysinger wrote: > > Would be more useful if we could use "const char * const *", but there's > > a long standing bug where gcc warns about incompatible pointers when you > > try to pass in

[PATCH] libiberty: {count,dup,write}argv: constify argv input slightly

) ATTRIBUTE_MALLOC; +extern char **dupargv (char * const *) ATTRIBUTE_MALLOC; /* Expand "@file" arguments in argv. */ @@ -88,11 +88,11 @@ extern void expandargv (int *, char ***); /* Write argv to an @-file, inserting necessary quoting. */ -extern int writeargv (char **, FI

Refactor intelmic-mkoffload.c argv building to use obstacks (was: [PATCH 1/4] Add mkoffload for Intel MIC)

an improvement - you're trading a compile time > >>> error for a runtime error. So, what is the other change this is > >>> preparing for? > >> > >> Ok, I now see the other patch. But I also see that other code in the same > >> file and in the nvptx mkoffl

[PATCH 02/03] jit-playback: Move argv-creation to its own function

): Use an auto_vecconst char * rather than a const char *[20] for the top-level argv, and move the logic to build it to... (gcc::jit::playback::context::make_fake_args): New function. * jit-playback.h (gcc::jit::playback::context::make_fake_args): New function

[Bug other/61895] libbacktrace crashes with bus error with empty file argv[0]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61895 Ian Lance Taylor ian at airs dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last

[Bug other/61895] libbacktrace crashes with bus error with empty file argv[0]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61895 --- Comment #3 from ian at gcc dot gnu.org ian at gcc dot gnu.org --- Author: ian Date: Sat Aug 2 00:53:58 2014 New Revision: 213512 URL: https://gcc.gnu.org/viewcvs?rev=213512root=gccview=rev Log: PR other/61895 runtime: Ignore small argv

[Bug other/61895] libbacktrace crashes with bus error with empty file argv[0]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61895 --- Comment #4 from ian at gcc dot gnu.org ian at gcc dot gnu.org --- Author: ian Date: Sat Aug 2 00:54:15 2014 New Revision: 213513 URL: https://gcc.gnu.org/viewcvs?rev=213513root=gccview=rev Log: PR other/61895 runtime: Ignore small argv

[Bug other/61895] libbacktrace crashes with bus error with empty file argv[0]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61895 Ian Lance Taylor ian at airs dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED

libgo patch committed: Ignore small argv[0] for backtrace

Reportedly in some cases Docker starts processes with argv[0] pointing to an empty file. That would cause libgo to pass that empty file to libbacktrace, which would then fail to do any backtraces. Everything should work fine if libbacktrace falls back to /proc/self/exe. This patch to libgo

[Bug other/61895] libbacktrace crashes with bus error with empty file argv[0]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61895 --- Comment #1 from Dominik Vogt vogt at linux dot vnet.ibm.com --- execv(argv[0], argv[1]); ^^^ ^^^ 1 2 Sorry.

[Bug other/61895] New: libbacktrace crashes with bus error with empty file argv[0]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61895 Bug ID: 61895 Summary: libbacktrace crashes with bus error with empty file argv[0] Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal

[Bug c/58103] New: Error in handling of command line parameters in main(int argc, char *argv[]), in case of ???..?

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58103 Bug ID: 58103 Summary: Error in handling of command line parameters in main(int argc, char *argv[]), in case of ???..? Product: gcc Version: 4.8.1 Status: UNCONFIRMED

[Bug c/58103] Error in handling of command line parameters in main(int argc, char *argv[]), in case of ???..?

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58103 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED

[Bug c/58103] Error in handling of command line parameters in main(int argc, char *argv[]), in case of ???..?

regards Heinz -Original Message- From: mpolacek at gcc dot gnu.org [mailto:gcc-bugzi...@gcc.gnu.org] Sent: Donnerstag, 08. August 2013 13:40 To: heinz.dob...@gmx.at Subject: *** GMX Spamverdacht *** [Bug c/58103] Error in handling of command line parameters in main(int argc, char *argv

[Bug c/58103] Error in handling of command line parameters in main(int argc, char *argv[]), in case of ???..?

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58103 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Sorry, I don't know neither Microsoft compiler nor Windows enough to answer that.

[Bug c/58103] Error in handling of command line parameters in main(int argc, char *argv[]), in case of ???..?

2013 13:57 To: heinz.dob...@gmx.at Subject: *** GMX Spamverdacht *** [Bug c/58103] Error in handling of command line parameters in main(int argc, char *argv[]), in case of ???..? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58103 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org

[Bug c/58103] Error in handling of command line parameters in main(int argc, char *argv[]), in case of ???..?

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58103 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- This has nothing to do with GCC anyway.

[Bug driver/29931] following argv[0] symlink in process_command breaks symlinked-together toolchain

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29931 --- Comment #5 from simonb at gcc dot gnu.org 2011-02-07 18:10:21 UTC --- Author: simonb Date: Mon Feb 7 18:10:15 2011 New Revision: 169891 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169891 Log: Auto-detect suitable default behaviour

Re: testsuite, simulators, and argv[0]

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 pass argv[0]. I think

Re: testsuite, simulators, and argv[0]

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: volatile char *x

Re: testsuite, simulators, and argv[0]

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 program away. So, I suggest doing something like

Re: testsuite, simulators, and argv[0]

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[0] here is just to keep the compiler from optimizing the program away

Re: testsuite, simulators, and argv[0]

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) { - foo (argv[0]); + foo

Re: testsuite, simulators, and argv[0]

DJ Delorie wrote: How about this? OK. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: testsuite, simulators, and argv[0]

OK. Thanks, committed.

testsuite, simulators, and argv[0]

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 (argv

Re: testsuite, simulators, and argv[0]

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 argc, argv. If yes

Re: testsuite, simulators, and argv[0]

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 parameters to the main

Re: testsuite, simulators, and argv[0]

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 be non-NULL: ISO/IEC 9899:1999(E) 5.1.2.2.1

[Bug debug/29628] unused argc/argv missing their DW_AT_location

--- Comment #2 from dodji at gcc dot gnu dot org 2008-10-13 14:23 --- Hello, I can't reproduce this neither on 4.3 nor trunk branch. In both branch, the variables have the DW_AT_location attribute. Please see below the attached dwarf output. --

[Bug debug/29628] unused argc/argv missing their DW_AT_location

--- Comment #3 from jan dot kratochvil at redhat dot com 2008-10-13 14:34 --- Fedora gcc-4.3.2-6.x86_64 with -m32 is still buggy as described in the Comment 0. But HEAD works OK now (-m32) so closing, thanks for the test: GNU C (GCC) version 4.4.0 20081007 (experimental)

[Bug ada/30560] gnatchop behaves differently dependend on argv[0] -- make check-ada fails

--- Comment #3 from sam at gcc dot gnu dot org 2008-04-12 19:27 --- Bug fixed but not closed. Closing it. -- sam at gcc dot gnu dot org changed: What|Removed |Added

[Bug driver/29931] following argv[0] symlink in process_command breaks symlinked-together toolchain

-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last

[Bug ada/30560] New: gnatchop behaves differently dependend on argv[0] -- make check-ada fails

! (which breaks the acats host_gnatchop script) It looks like gnatchop follows symlinks on each path component if argv[0] is not gnatchop. From strace of the last case: execve(/usr/bin/gnatchop, [/usr/bin/gnatchop, support/checkfil.ada], [/* 80 vars */]) = 0 ... getcwd(/abuild/rguenther/obj/gcc

[Bug ada/30560] gnatchop behaves differently dependend on argv[0] -- make check-ada fails

--- Comment #1 from rguenth at gcc dot gnu dot org 2007-01-23 17:09 --- The testsuite is fixed by the following which should be safe because we're adding the path of $host_gnat* to PATH first. Index: run_acats === ---

[Bug ada/30560] gnatchop behaves differently dependend on argv[0] -- make check-ada fails

--- Comment #2 from rguenth at gcc dot gnu dot org 2007-01-23 17:27 --- Subject: Bug 30560 Author: rguenth Date: Tue Jan 23 17:27:22 2007 New Revision: 121083 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121083 Log: 2007-01-23 Richard Guenther [EMAIL PROTECTED] PR

[Bug driver/29931] following argv[0] symlink in process_command breaks symlinked-together toolchain

--- Comment #4 from amylaar at gcc dot gnu dot org 2006-12-04 14:27 --- The bug is not fixed; the gcc.c patch has not been reviewed. -- amylaar at gcc dot gnu dot org changed: What|Removed |Added

[Bug driver/29931] following argv[0] symlink in process_command breaks symlinked-together toolchain

--- Comment #3 from pinskia at gcc dot gnu dot org 2006-12-03 21:32 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added

[Bug driver/29931] following argv[0] symlink in process_command breaks symlinked-together toolchain

--- Comment #2 from amylaar at gcc dot gnu dot org 2006-11-30 17:06 --- Subject: Bug 29931 Author: amylaar Date: Thu Nov 30 17:05:45 2006 New Revision: 119366 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119366 Log: include: 2006-05-03 Andrew Stubbs [EMAIL PROTECTED]

[Bug debug/29628] unused argc/argv missing their DW_AT_location

--- Comment #1 from jakub at gcc dot gnu dot org 2006-10-30 16:11 --- This is caused by the stack realignment in i?86 main, the way it is currently implemented is that address of first argument is loaded into %ecx and then the stack is realigned. The pseudo register which shows in the

[Bug debug/29628] New: [32bit] unused argc/argv missing their DW_AT_location

`main' function (the function with specific prologue/epilogue) is missing DWARF `DW_AT_location' for its `argc' and `argv' on 32-bit targets - only if these arguments are never unused. affected: x86_64-redhat-linux with -m32, i386-redhat-linux not affected: x86_64-redhat-linux (-m64) 32-bit

[Bug debug/29628] unused argc/argv missing their DW_AT_location

triplet|i686-pc-linux-gnu | Summary|[32bit] unused argc/argv|unused argc/argv missing |missing their DW_AT_location|their DW_AT_location http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29628

[32bit] `main' missing argc/argv DW_AT_location

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, i386-redhat-linux