Re: Simulator question about argc/argv
Mike Frysinger <[email protected]>
| Newsgroups | gmane.comp.gdb.devel |
|---|---|
| Message-ID | <[email protected]> |
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
signature.asc
(application/pgp-signature, 836 B)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iQIcBAABAgAGBQJRqThxAAoJEEFjO5/oN/WB8twP/RUst1wwX63a0lWfJNKK2SkE 1nMSgzH3rR7C8aMqPIg1Zy4U1tzuyiXCXN/KxpoDl4QUYja0uUaynChDbStGgPpg I0hHvjMO5AD1kn4ryukeAj4hzcTG92SdjHWgKOOyi2ZwFUgtF2SnmMpkHVbizA5l oAo4EDX4yjAvEY5LUIAHjbSphyWM3w5HOXkpFWZjHvPIjt7ZI19UDseXek7ss3to zqACzoBgrP6ojIkffOe2SmJ9yJWGtE3Q1VZVg8F5pfPTJJ1L2Wbd8vJO8KWP5t6p GkD5WWC3cMvcYUpp0Bog2LtYPfNiyBOh7Tl8oVmK6UbWxeLP3DS8y4LDbYqtHZ/J QwBk/r1YLfPW8QpXBwITd4zvQHT/AuXg2EC/msX+GH0omaXfwnTqkuAwJsldAtO5 0SgKh0sczMUMR9ROtjzB91QI0Dlau75hzg1ycoGEXaW/fHVL9DtPWmIjROvjtBGT mcWRwVcBmk/q60nwQbnRd3+8spJE3VcMHRSuoLBYk/CVn6j9CqKuXMMlXgFwyxSr x/gyLHnrU/jTJDSrVbwrK/Xlmt5lrzu5bzvmOOtukH9pAsSP4JlezvJl2NCIHtkQ FJqsGNWhtNSjsIHz+v6LdOq5SKPn2gaUTytxpNiAnO6zQsyLBdn6sM8wrtwLEPqF 3zSp5wARoklVyGXFpaBJ =OagZ -----END PGP SIGNATURE-----