From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25898 invoked by alias); 31 May 2013 23:55:28 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 25883 invoked by uid 89); 31 May 2013 23:55:27 -0000 X-Spam-SWARE-Status: No, score=-9.5 required=5.0 tests=AWL,BAYES_00,KHOP_PGP_SIGNED,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_PASS,TW_QE autolearn=ham version=3.3.1 Received: from smtp.gentoo.org (HELO smtp.gentoo.org) (140.211.166.183) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 31 May 2013 23:55:26 +0000 Received: from vapier.localnet (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id C7D2D33E247; Fri, 31 May 2013 23:55:24 +0000 (UTC) From: Mike Frysinger To: gdb@sourceware.org Subject: Re: Simulator question about argc/argv Date: Fri, 31 May 2013 23:55:00 -0000 User-Agent: KMail/1.13.7 (Linux/3.8.3; KDE/4.6.5; x86_64; ; ) Cc: "Steve Ellcey " References: <201305311453.05333.vapier@gentoo.org> In-Reply-To: <201305311453.05333.vapier@gentoo.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2787194.WrCpbcVBvD"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201305311955.29482.vapier@gentoo.org> X-Virus-Found: No X-SW-Source: 2013-05/txt/msg00150.txt.bz2 --nextPart2787194.WrCpbcVBvD Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-length: 3134 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. >=20 > 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 :). >=20 > 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=20 __setup_argv_and_call_main * __setup_argv_and_call_main uses the syscalls SYS_argc, SYS_argn, and=20 SYS_argnlen to request info from the sim and copies the contents to storage= it=20 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= =20 sim state (see sim_analyze_program() and STATE_PROG_ARGV()) * also in semi-startup (see sim_create_inferior()), we have to handle an ed= ge=20 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=20 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, althoug= h i=20 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_arg= v",=20 but don't actually implement any handling for it this of course doesn't include random ports/patches that people like to car= ry=20 but not post upstream however, considering Jie's findings in the referenced thread, and no one ha= s=20 spoken up since, and it seems everyone's sim (except for Blackfin & SuperH)= =20 have been broken, then i guess it's time to call it. let's recommend peopl= e=20 implement SYS_arg{c, n, nlen}, and document the process. hell, i really ne= ed=20 to bite my tongue and write *any* sim documentation as i don't believe anyo= ne=20 has ever written any :(. -mike --nextPart2787194.WrCpbcVBvD Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. Content-length: 836 -----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----- --nextPart2787194.WrCpbcVBvD--