[PATCH] gdb: add callback defines for new ARGV handling

[Mike Frysinger]

Jie: could you comment on the below thread ?
-mike

On Monday 10 January 2011 22:38:11 Doug Evans wrote:
> [+ newlib]
> 
> On Mon, Jan 10, 2011 at 2:29 PM, Mike Frysinger wrote:
> >> For callback.h, IWBN to add some documentation regarding why things
> >> are the way they are.  E.g. if argn is preferred over argv, why?
> > 
> > these things were created long before i had even heard of either project,
> > so i can only speculate on their history.
> 
> Understood.
> 
> > i would guess that argv/argvlen made it
> > more difficult to do what most people actually want -- pass argc/argv to
> > the main function.  and so argc/argn were born.
> 
> I wouldn't mind hearing more, sounds pretty fishy.
> Though I understand it was before your time.
> 
> I found these in the newlib archives:
> An inquiry into argv,argvlen:
> http://sourceware.org/ml/newlib/2006/msg00859.html
> Submission of argc,argn,argnlen:
> http://sourceware.org/ml/newlib/2006/msg00883.html
> 
> I couldn't find any pushback when argn,argnlen were submitted.
> 
> > all i really know is that argc/argn/argnlen are labeled as "the new
> > approach" in a few places, and as such, it is what the Blackfin port
> > supports.
> 
> Blech.
> I'm hesitant to approve the patch, but since this is sim,newlib I
> don't want to hold things up much just because of this.
> 
> > it also seems like the syscall handling intended to handle argv at some
> > point, but someone didnt get around to implementing it.  so i could
> > flesh that out too so that i could take the Blackfin argn/argc code and
> > move it to common/syscall.c in the sim.
> 
> newlib: does anyone know the history of SYS_argc,argn,argnlen vs
> SYS_argv,argvlen beyond the above mentioned emails?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20120409/1a60edc8/attachment.sig>