Re: [uClinux-dev] [Fwd: convert ld-elf2flt to C program]

2009-07-06 Thread David McCullough

Jivin Mike Frysinger lays it down ...
 On Monday 06 July 2009 00:24:46 David McCullough wrote:
  Jivin Mike Frysinger lays it down ...
   On Wednesday 20 February 2008 19:22:38 David McCullough wrote:
If someone wants to have a go at reducing the code size/complexity a
bit (or not) and make sure the patch is up to date and only used for
cygwin/windows builds, I will get it committed into the elf2flt repo on
uclinux.org, promise :-)
  
   is this still your opinion David ?  while i dont agree, if it's the only
   way to get merged, then i guess i'll have to do it.  rather than tying it
   to a target environment, i would make it a configure option.  something
   like: ./configure --enable-ld-elf2flt-binary
  
   the latest version is attached and has been tested with the different
   Blackfin tuples and Linux/mingw hosts.  fixed a few more bugs to get this
   far ;).
 
  I was sort of hoping to run the two (script and C in parrallel for a while)
  but I am not sure if that will really do more than cause bit-rot in the
  non-default option.
 
 i'll be switching the Blackfin toolchain to the binary one, so there would be 
 testing on both sides if you wanted to keep the uclinux.org side cautious for 
 a little while.  if no one complains, we flip the default configure option.  
 if still no one complains, we drop it.

Unless there is some strong support for dragging the process out, lets assume
for now the 'C' version is the default and the script is a config option until
we drop it down the track.

  Other thans Johns comments about 'C' not being ideal for scripting,  which
  I agree, I am mostly ok. The only thought I had when all the perl compiler
  stuff was getting thrown around was to re-write it in TCL (Yeah I know),
  but the tinytcl library could easily be used to produce a binary tool to
  run the script,  or, run it native of systems with tcl interpreters.
 
 tinytcl can produce native code from a tcl script ?  or you mean the tinytcl 
 executable itself is tiny ?

No,  but you can just encode the script into a small wrapper and invoke the
interpreter on it that way.  Pretty simple IIRC.

  So unless there are any more followups to this thread with better ideas
  or agreement/disagreement, I think it's time to merge it in.
  Give a day or so for and final feedback and I'll run with whatever is the
  latest patch
 
 i can split the patch up into smaller pieces if you like.  atm it adds helper 
 functions like fatal() to stubs.c and then converts elf2flt.c to use those 
 (i found this useful after elf2flt produced the error output cannot open 
 with no indication *which* program could not open).

Your call on splitting it,  might be better for others to follow.

Actually,  do that and I'll apply all those now,  then we can at least tag the
source prior to the C version coming in so if someone wants the old behaviour
it's easy enough to checkout to a tag.

 i'm pretty sure this is the latest patch (taken from blackfin.u.o git), but i 
 have to double check to make sure i dont have anything left on my laptop 
 which 
 i can do tomorrow.

No prob,

Cheers,
Davidm

-- 
David McCullough,  david_mccullo...@securecomputing.com,  Ph:+61 734352815
McAfee - SnapGear  http://www.snapgear.comhttp://www.uCdot.org
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev


RE: [uClinux-dev] [Fwd: convert ld-elf2flt to C program]

2008-03-13 Thread Gavin Lambert
Quoth Mike Frysinger:
 On Wednesday 20 February 2008, Mike Frysinger wrote:
  On Tuesday 12 September 2006, Nathan Sidwell wrote:
   static void fatal (const char *, ...); static void fatal_perror
   (const char *, ...);
 
  are there really no libiberty funcs that do this ?
 
 looks like the binutils peeps are lazy and just re-implement these same
 set of functions in each set of packages rather than putting them into
 a library

Are those similar to the standard err/errx/warn/warnx and friends from
err.h?



___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev


Re: [uClinux-dev] [Fwd: convert ld-elf2flt to C program]

2008-03-13 Thread Mike Frysinger
On Thursday 13 March 2008, Gavin Lambert wrote:
 Quoth Mike Frysinger:
  On Wednesday 20 February 2008, Mike Frysinger wrote:
   On Tuesday 12 September 2006, Nathan Sidwell wrote:
static void fatal (const char *, ...); static void fatal_perror
(const char *, ...);
  
   are there really no libiberty funcs that do this ?
 
  looks like the binutils peeps are lazy and just re-implement these same
  set of functions in each set of packages rather than putting them into
  a library

 Are those similar to the standard err/errx/warn/warnx and friends from
 err.h?

yes, but unfortunately err.h is a BSDism that glibc happened to pick up.  
using those would sort of defeat the purpose of this effort ... making it 
portable to systems such as Windows.  although i could add stubs for the 
functions to stubs.c if the system C library doesnt support them ...
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Re: [uClinux-dev] [Fwd: convert ld-elf2flt to C program]

2008-03-12 Thread Mike Frysinger
On Wednesday 20 February 2008, Mike Frysinger wrote:
 On Tuesday 12 September 2006, Nathan Sidwell wrote:
  static void fatal (const char *, ...);
  static void fatal_perror (const char *, ...);

 are there really no libiberty funcs that do this ?

looks like the binutils peeps are lazy and just re-implement these same set of 
functions in each set of packages rather than putting them into a library

  static void append_option (options_t *, const char *);
  static void append_options (options_t *, const options_t *);
  static void append_sed (sed_commands_t *, const char *, const char *);
  static void parse_args (int, char **);
  static int execute (const char *, const char *, const options_t *, ...);

 i think libiberty provides argv funcs to build/destroy which these
 functions duplicate ?

the argv funcs provided by libiberty would require re-quoting pains

  create_tmp_file (const char **name_ptr)
  delete_tmp_file (const char **name_ptr)

 libiberty provides temp file functions so these shouldnt be needed

using the libiberty ones wouldnt really gain us much

we could split these lib type functions off into a sep object ... the fatal 
funcs for example could also get used by elf2flt.c/flthdr.c and make that a 
bit more tidy.
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Re: [uClinux-dev] [Fwd: convert ld-elf2flt to C program]

2008-02-20 Thread Mike Frysinger
On Tuesday 12 September 2006, Nathan Sidwell wrote:
 static void fatal (const char *, ...);
 static void fatal_perror (const char *, ...);

are there really no libiberty funcs that do this ?

 static void append_option (options_t *, const char *);
 static void append_options (options_t *, const options_t *);
 static void append_sed (sed_commands_t *, const char *, const char *);
 static void parse_args (int, char **);
 static int execute (const char *, const char *, const options_t *, ...);

i think libiberty provides argv funcs to build/destroy which these functions 
duplicate ?

 create_tmp_file (const char **name_ptr)
 delete_tmp_file (const char **name_ptr)

libiberty provides temp file functions so these shouldnt be needed

the output files dont get unlinked in case of error ... but i guess that's how 
the current script acts as well

did you ever get a chance of posting this code in a public repo somewhere ?
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Re: [uClinux-dev] [Fwd: convert ld-elf2flt to C program]

2008-02-20 Thread David McCullough

Jivin Mike Frysinger lays it down ...
 On Tuesday 12 September 2006, Nathan Sidwell wrote:
  static void fatal (const char *, ...);
  static void fatal_perror (const char *, ...);
 
 are there really no libiberty funcs that do this ?
 
  static void append_option (options_t *, const char *);
  static void append_options (options_t *, const options_t *);
  static void append_sed (sed_commands_t *, const char *, const char *);
  static void parse_args (int, char **);
  static int execute (const char *, const char *, const options_t *, ...);
 
 i think libiberty provides argv funcs to build/destroy which these functions 
 duplicate ?
 
  create_tmp_file (const char **name_ptr)
  delete_tmp_file (const char **name_ptr)
 
 libiberty provides temp file functions so these shouldnt be needed
 
 the output files dont get unlinked in case of error ... but i guess that's 
 how 
 the current script acts as well
 
 did you ever get a chance of posting this code in a public repo somewhere ?

I still have this sitting here waiting for more comment/feedback.

The above sounds good,  anything that reduces the siz eof the current
'C' implementation would be good.  Last I looked the C version still
seemed more complicated than I would have liked,  but then this stuff is
harder in 'C',  thus the reason we have scripts ;-)

As a crazy idea you could probably convert it to tcl,  and on windows
build it into an executable using a local copy of the tinytcl source.
That way the script stays simple,  and a script on unix,  and on windows
you can have a small standalone executable. Anyway, enough crazy talk.

If someone wants to have a go at reducing the code size/complexity a bit
(or not) and make sure the patch is up to date and only used for
cygwin/windows builds, I will get it committed into the elf2flt repo on
uclinux.org, promise :-)

Cheers,
Davidm

-- 
David McCullough,  [EMAIL PROTECTED],   Ph:+61 734352815
Secure Computing - SnapGear  http://www.uCdot.org http://www.cyberguard.com
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev


Re: [uClinux-dev] [Fwd: convert ld-elf2flt to C program]

2007-09-20 Thread Mike Frysinger
On Friday 29 December 2006, Mike Frysinger wrote:
 On Tuesday 12 September 2006 18:46, David McCullough wrote:
  Jivin Mike Frysinger lays it down ...
 
   On Tuesday 12 September 2006 12:27, Nathan Sidwell wrote:
I posted this patch and pinged it a few times, but to no avail.  Is
no one interested?
  
   iirc, we (the blackfin guys) looked over it and liked the direction
   this code is going ... but we arent the maintainers sooo ... ;)
 
  It's been sitting in my inbox,  mostly waiting for some postitive
  feedback.  i think I replied last week and said lets do it.  I'll try
  and get it included this week,

 any such luck yet ? :)

another ping ?
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev