This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Simulator question about argc/argv


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

Attachment: signature.asc
Description: This is a digitally signed message part.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]