Re: Simulator question about argc/argv

Mike Frysinger
2013-06-01T06:21:07Z

[-- 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.