Simulator question about argc/argv

Simulator question about argc/argv

[Steve Ellcey]

Some new tests have been added to the GCC testsuite (cilk tests) that
check the value of argc and they expect it to be 1 if there are no
arguments to the test program (and there are none) but I am getting 0
when I run the tests under the gnu simulator.  Does anyone know why
this is?  I don't know if this is specific to my target (mips-mti-elf)
or a general simulator problem.  Perhaps it is related to my linker
script?  The mips-mti-elf target is built with newlib.  Could someone
else who uses the gnu simulator and newlib try this.  It works fine for
me under the qemu simulator.

% cat x.c
#include <stdio.h>
int main(int argc, char **argv)
{
  printf("%d\n", argc);
  return 0;
}

% mips-mti-elf-gcc x.c -Tmti32.ld -o x
% mips-mti-elf-run ./x
0
% mips-mti-elf-run ./x 99
0

Steve Ellcey
sellcey@mips.com

Re: Simulator question about argc/argv

[Andrew Pinski]

On Fri, May 31, 2013 at 9:47 AM, Steve Ellcey <sellcey@mips.com> wrote:
>
> Some new tests have been added to the GCC testsuite (cilk tests) that
> check the value of argc and they expect it to be 1 if there are no
> arguments to the test program (and there are none) but I am getting 0
> when I run the tests under the gnu simulator.  Does anyone know why
> this is?  I don't know if this is specific to my target (mips-mti-elf)
> or a general simulator problem.  Perhaps it is related to my linker
> script?  The mips-mti-elf target is built with newlib.  Could someone
> else who uses the gnu simulator and newlib try this.  It works fine for
> me under the qemu simulator.
>
> % cat x.c
> #include <stdio.h>
> int main(int argc, char **argv)
> {
>   printf("%d\n", argc);
>   return 0;
> }
>
> % mips-mti-elf-gcc x.c -Tmti32.ld -o x
> % mips-mti-elf-run ./x
> 0
> % mips-mti-elf-run ./x 99
> 0


I get a similar thing on both of Cavium's internal simulators (MIPS64
and AARCH64) when running with bare metal.  I normally just go and fix
the testcase not to depend on argc.

Thanks,
Andrew

>
> Steve Ellcey
> sellcey@mips.com
>

Re: Simulator question about argc/argv

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1858 bytes --]

On Friday 31 May 2013 12:47:54 Steve Ellcey wrote:
> Some new tests have been added to the GCC testsuite (cilk tests) that
> check the value of argc and they expect it to be 1 if there are no
> arguments to the test program (and there are none) but I am getting 0
> when I run the tests under the gnu simulator.  Does anyone know why
> this is?  I don't know if this is specific to my target (mips-mti-elf)
> or a general simulator problem.  Perhaps it is related to my linker
> script?  The mips-mti-elf target is built with newlib.  Could someone
> else who uses the gnu simulator and newlib try this.  It works fine for
> me under the qemu simulator.

unfortunately, the argc/argv handling tends to be target specific and spread 
across newlib, libgloss, and the sim (target specific pieces).  you might even 
see different behavior if the env is gdb rather than the run frontend :).

i'd have to dig into the specific mips lower startup code to see how it 
transfers things, but this does work for Blackfin targets:

$ cat test.c
#include <stdio.h>
int main(int argc, char **argv)
{
  printf("%d\n", argc);
  return 0;
}
$ bfin-elf-gcc -msim test.c
$ bfin-elf-run ./a.out
1
$ bfin-elf-gdb -q -ex 'target sim' -ex load -ex run ./a.out 
Connected to the simulator.
Loading section .init, size 0x12 lma 0x0
Loading section .text, size 0x89f8 lma 0x14
Loading section .fini, size 0xe lma 0x8a0c
Loading section .rodata, size 0x618 lma 0x8a1c
Loading section .eh_frame, size 0x4 lma 0x9034
Loading section .ctors, size 0x8 lma 0xa038
Loading section .dtors, size 0x8 lma 0xa040
Loading section .jcr, size 0x4 lma 0xa048
Loading section .data, size 0x8bc lma 0xa04c
Start address 0x14
Transfer rate: 313376 bits in <1 sec.
Starting program: /usr/local/src/gnu/gdb/sim/bfin/a.out 
1

Program exited normally.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Simulator question about argc/argv

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1873 bytes --]

On Friday 31 May 2013 14:53:04 Mike Frysinger wrote:
> On Friday 31 May 2013 12:47:54 Steve Ellcey wrote:
> > Some new tests have been added to the GCC testsuite (cilk tests) that
> > check the value of argc and they expect it to be 1 if there are no
> > arguments to the test program (and there are none) but I am getting 0
> > when I run the tests under the gnu simulator.  Does anyone know why
> > this is?  I don't know if this is specific to my target (mips-mti-elf)
> > or a general simulator problem.  Perhaps it is related to my linker
> > script?  The mips-mti-elf target is built with newlib.  Could someone
> > else who uses the gnu simulator and newlib try this.  It works fine for
> > me under the qemu simulator.
> 
> unfortunately, the argc/argv handling tends to be target specific and
> spread across newlib, libgloss, and the sim (target specific pieces).  you
> might even see different behavior if the env is gdb rather than the run
> frontend :).
> 
> i'd have to dig into the specific mips lower startup code to see how it
> transfers things, but this does work for Blackfin targets:

and the example of passing in additional args:
$ bfin-elf-run ./a.out 99
2
$ bfin-elf-gdb -q -ex 'target sim' -ex load -ex 'run 99' -ex q bfin/a.out 
Connected to the simulator.
Loading section .init, size 0x12 lma 0x0
Loading section .text, size 0x89f8 lma 0x14
Loading section .fini, size 0xe lma 0x8a0c
Loading section .rodata, size 0x618 lma 0x8a1c
Loading section .eh_frame, size 0x4 lma 0x9034
Loading section .ctors, size 0x8 lma 0xa038
Loading section .dtors, size 0x8 lma 0xa040
Loading section .jcr, size 0x4 lma 0xa048
Loading section .data, size 0x8bc lma 0xa04c
Start address 0x14
Transfer rate: 313376 bits in <1 sec.
Starting program: /usr/local/src/gnu/gdb/sim/bfin/a.out 99
2

Program exited normally.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Simulator question about argc/argv

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 3143 bytes --]

On Friday 31 May 2013 14:53:04 Mike Frysinger wrote:
> On Friday 31 May 2013 12:47:54 Steve Ellcey wrote:
> > Some new tests have been added to the GCC testsuite (cilk tests) that
> > check the value of argc and they expect it to be 1 if there are no
> > arguments to the test program (and there are none) but I am getting 0
> > when I run the tests under the gnu simulator.  Does anyone know why
> > this is?  I don't know if this is specific to my target (mips-mti-elf)
> > or a general simulator problem.  Perhaps it is related to my linker
> > script?  The mips-mti-elf target is built with newlib.  Could someone
> > else who uses the gnu simulator and newlib try this.  It works fine for
> > me under the qemu simulator.
> 
> unfortunately, the argc/argv handling tends to be target specific and
> spread across newlib, libgloss, and the sim (target specific pieces).  you
> might even see different behavior if the env is gdb rather than the run
> frontend :).
> 
> i'd have to dig into the specific mips lower startup code to see how it
> transfers things, but this does work for Blackfin targets:

ok, there's a bit of history here :).  you can start here:
http://sourceware.org/ml/newlib/2012/msg00134.html

for the Blackfin overview:

on the libgloss side of things:
* _start in the crt0 used by the sim calls a Blackfin-libgloss func named 
__setup_argv_and_call_main
* __setup_argv_and_call_main uses the syscalls SYS_argc, SYS_argn, and 
SYS_argnlen to request info from the sim and copies the contents to storage it 
has allocated locally
* the code then calls the real main() with the populated argc/argv values
* profit!

on the sim side of things:
* at startup (see sim_open()), save a copy of the argc/argv into the active 
sim state (see sim_analyze_program() and STATE_PROG_ARGV())
* also in semi-startup (see sim_create_inferior()), we have to handle an edge 
case where the sim is being started up by `gdb` rather than `run`
* the code that responds to syscalls looks for these SYS_arg* and returns 
values from STATE_PROG_ARGV()

a quick survey of libgloss/newlib shows:
* SYS_arg{c, n, nlen}: implemented by Blackfin and SuperH
* SYS_arg{v, vlen}: implemented by d10v (and defined by arm & i960, although i 
don't see implementation for it)

while a survey of the sim shows:
* common code has implementations of SYS_arg{v, vlen}, but they're disabled
* Blackfin & SuperH implement SYS_arg{c, n, nlen}
* a few random sims mark out SYS_arg{v, vlen} as in "syscall #13 is SYS_argv", 
but don't actually implement any handling for it

this of course doesn't include random ports/patches that people like to carry 
but not post upstream

however, considering Jie's findings in the referenced thread, and no one has 
spoken up since, and it seems everyone's sim (except for Blackfin & SuperH) 
have been broken, then i guess it's time to call it.  let's recommend people 
implement SYS_arg{c, n, nlen}, and document the process.  hell, i really need 
to bite my tongue and write *any* sim documentation as i don't believe anyone 
has ever written any :(.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Simulator question about argc/argv

[Andrew Pinski]

On Fri, May 31, 2013 at 4:55 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Friday 31 May 2013 14:53:04 Mike Frysinger wrote:
>> On Friday 31 May 2013 12:47:54 Steve Ellcey wrote:
>> > Some new tests have been added to the GCC testsuite (cilk tests) that
>> > check the value of argc and they expect it to be 1 if there are no
>> > arguments to the test program (and there are none) but I am getting 0
>> > when I run the tests under the gnu simulator.  Does anyone know why
>> > this is?  I don't know if this is specific to my target (mips-mti-elf)
>> > or a general simulator problem.  Perhaps it is related to my linker
>> > script?  The mips-mti-elf target is built with newlib.  Could someone
>> > else who uses the gnu simulator and newlib try this.  It works fine for
>> > me under the qemu simulator.
>>
>> unfortunately, the argc/argv handling tends to be target specific and
>> spread across newlib, libgloss, and the sim (target specific pieces).  you
>> might even see different behavior if the env is gdb rather than the run
>> frontend :).
>>
>> i'd have to dig into the specific mips lower startup code to see how it
>> transfers things, but this does work for Blackfin targets:
>
> ok, there's a bit of history here :).  you can start here:
> http://sourceware.org/ml/newlib/2012/msg00134.html
>
> for the Blackfin overview:
>
> on the libgloss side of things:
> * _start in the crt0 used by the sim calls a Blackfin-libgloss func named
> __setup_argv_and_call_main
> * __setup_argv_and_call_main uses the syscalls SYS_argc, SYS_argn, and
> SYS_argnlen to request info from the sim and copies the contents to storage it
> has allocated locally
> * the code then calls the real main() with the populated argc/argv values
> * profit!
>
> on the sim side of things:
> * at startup (see sim_open()), save a copy of the argc/argv into the active
> sim state (see sim_analyze_program() and STATE_PROG_ARGV())
> * also in semi-startup (see sim_create_inferior()), we have to handle an edge
> case where the sim is being started up by `gdb` rather than `run`
> * the code that responds to syscalls looks for these SYS_arg* and returns
> values from STATE_PROG_ARGV()
>
> a quick survey of libgloss/newlib shows:
> * SYS_arg{c, n, nlen}: implemented by Blackfin and SuperH
> * SYS_arg{v, vlen}: implemented by d10v (and defined by arm & i960, although i
> don't see implementation for it)
>
> while a survey of the sim shows:
> * common code has implementations of SYS_arg{v, vlen}, but they're disabled
> * Blackfin & SuperH implement SYS_arg{c, n, nlen}
> * a few random sims mark out SYS_arg{v, vlen} as in "syscall #13 is SYS_argv",
> but don't actually implement any handling for it
>
> this of course doesn't include random ports/patches that people like to carry
> but not post upstream
>
> however, considering Jie's findings in the referenced thread, and no one has
> spoken up since, and it seems everyone's sim (except for Blackfin & SuperH)
> have been broken, then i guess it's time to call it.  let's recommend people
> implement SYS_arg{c, n, nlen}, and document the process.  hell, i really need
> to bite my tongue and write *any* sim documentation as i don't believe anyone
> has ever written any :(.

This won't help non-gdb based simulators where the problem also exist.
 I test gdb and gcc using a non-gdb based simulator all the time.  The
environment is designed for a bare metal environment where there is no
argv or argc (well the bootloader does pass arguments down to the
program but it is hard to do using the simulator except using a
separate file and it never passes the application name either even via
the bootloader).

I think it is better to just fix the GCC testsuite rather than fixing
the simulators.

Thanks,
Andrew Pinski


> -mike

Re: Simulator question about argc/argv

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 2704 bytes --]

On Friday 31 May 2013 22:25:24 Andrew Pinski wrote:
> On Fri, May 31, 2013 at 4:55 PM, Mike Frysinger wrote:
> > On Friday 31 May 2013 14:53:04 Mike Frysinger wrote:
> >> On Friday 31 May 2013 12:47:54 Steve Ellcey wrote:
> >> > Some new tests have been added to the GCC testsuite (cilk tests) that
> >> > check the value of argc and they expect it to be 1 if there are no
> >> > arguments to the test program (and there are none) but I am getting 0
> >> > when I run the tests under the gnu simulator.  Does anyone know why
> >> > this is?  I don't know if this is specific to my target (mips-mti-elf)
> >> > or a general simulator problem.  Perhaps it is related to my linker
> >> > script?  The mips-mti-elf target is built with newlib.  Could someone
> >> > else who uses the gnu simulator and newlib try this.  It works fine
> >> > for me under the qemu simulator.
> >> 
> >> unfortunately, the argc/argv handling tends to be target specific and
> >> spread across newlib, libgloss, and the sim (target specific pieces). 
> >> you might even see different behavior if the env is gdb rather than the
> >> run frontend :).
> >> 
> >> i'd have to dig into the specific mips lower startup code to see how it
> >> transfers things, but this does work for Blackfin targets:
> > 
> > ok, there's a bit of history here :).  you can start here:
> > http://sourceware.org/ml/newlib/2012/msg00134.html
> > ...
> > however, considering Jie's findings in the referenced thread, and no one
> > has spoken up since, and it seems everyone's sim (except for Blackfin &
> > SuperH) have been broken, then i guess it's time to call it.  let's
> > recommend people implement SYS_arg{c, n, nlen}, and document the
> > process.  hell, i really need to bite my tongue and write *any* sim
> > documentation as i don't believe anyone has ever written any :(.
> 
> This won't help non-gdb based simulators where the problem also exist.
>  I test gdb and gcc using a non-gdb based simulator all the time.  The
> environment is designed for a bare metal environment where there is no
> argv or argc (well the bootloader does pass arguments down to the
> program but it is hard to do using the simulator except using a
> separate file and it never passes the application name either even via
> the bootloader).

perhaps, but it doesn't preclude fixing the GNU sim (not to be pedantic, but 
`run` isn't gdb based, it's entirely standalone).  this is a long standing 
issue and it isn't unreasonable for people to expect this to work.

> I think it is better to just fix the GCC testsuite rather than fixing
> the simulators.

or make it XFAIL when the sim is known to suck.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Simulator question about argc/argv

[nick clifton]

Hi Steve,

> Some new tests have been added to the GCC testsuite (cilk tests) that
> check the value of argc and they expect it to be 1 if there are no
> arguments to the test program (and there are none) but I am getting 0
> when I run the tests under the gnu simulator.  Does anyone know why
> this is?

Yes - many simulators do not support passing any arguments to the 
program that they are simulating.  So they set argc to zero when they 
invoke main.  (They usually also set argv to NULL and envp to NULL).

Tests that depend upon a non-zero argc value are, IMHO, dubious.  Tests 
should be able to be run in an automated fashion without anything being 
provided to them via the command line or their environment.

Cheers
   Nick