Re: Simulator question about argc/argv

[Andrew Pinski <pinskia at gmail dot com>]

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