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-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.