Skip to content
Snippets Groups Projects
  1. Oct 03, 2012
  2. Jul 04, 2010
    • Wolfgang Denk's avatar
      Make sure that argv[] argument pointers are not modified. · 54841ab5
      Wolfgang Denk authored
      
      The hush shell dynamically allocates (and re-allocates) memory for the
      argument strings in the "char *argv[]" argument vector passed to
      commands.  Any code that modifies these pointers will cause serious
      corruption of the malloc data structures and crash U-Boot, so make
      sure the compiler can check that no such modifications are being done
      by changing the code into "char * const argv[]".
      
      This modification is the result of debugging a strange crash caused
      after adding a new command, which used the following argument
      processing code which has been working perfectly fine in all Unix
      systems since version 6 - but not so in U-Boot:
      
      int main (int argc, char **argv)
      {
      	while (--argc > 0 && **++argv == '-') {
      /* ====> */	while (*++*argv) {
      			switch (**argv) {
      			case 'd':
      				debug++;
      				break;
      			...
      			default:
      				usage ();
      			}
      		}
      	}
      	...
      }
      
      The line marked "====>" will corrupt the malloc data structures and
      usually cause U-Boot to crash when the next command gets executed by
      the shell.  With the modification, the compiler will prevent this with
      an
      	error: increment of read-only location '*argv'
      
      N.B.: The code above can be trivially rewritten like this:
      
      	while (--argc > 0 && **++argv == '-') {
      		char *arg = *argv;
      		while (*++arg) {
      			switch (*arg) {
      			...
      
      Signed-off-by: default avatarWolfgang Denk <wd@denx.de>
      Acked-by: default avatarMike Frysinger <vapier@gentoo.org>
      54841ab5
  3. Nov 22, 2009
  4. Jan 24, 2009
    • Yuri Tikhonov's avatar
      FPU POST: fix warnings when building with 2.18 binutils · ce82ff05
      Yuri Tikhonov authored
      
      When compile u-boot with the 2.18 binutils the following
      warning messages for each object file in post/lib_ppc/fpu/ is
      produced at the linking stage:
      
      post/libpost.a(acc1.o) uses hard float, u-boot uses soft-float
      ...
      
      This is because of the fact that, in general, the soft-float and
      hard-float ABIs are incompatible; the 2.18 binutils do checking
      of the Tag_GNU_Power_ABI_FP attribute of the files to be linked, and
      produce the worning like above if these are not compatible.
      
      The incompatibility of ABIs is concerned only the float values:
      e.g. the soft-float ABI assumes the float argument passing in the
      pair of rX registers, and the hard-float ABI assumes passing of
      the float argument in the fX register. When we don't pass the float
      arguments between the functions compiled with different floatness,
      then such an application will work correctly.
      This is the case for the FPU POST: u-boot (compiled with soft-float)
      doesn't pass to (and doesn't get from) the FPU POST functions any
      floats; there are no functions exported from the post/lib_ppc/fpu/
      objects which would work with float parameters/returns too. So, we
      can reassure the linker not to worry about the difference in ABI
      attributes of linking files just by setting the 'soft-float'
      attribute for the objects in post/lib_ppc/fpu. And this patch does
      this.
      
      Also, to avoid passing both soft- and hard-float options in CFLAGS
      when compiling the files from post/lib_ppc/fpu (which is OK, but
      looks rather dirty) this patch removes the soft-float string from
      CFLAGS in post/lib_ppc/fpu/Makefile.
      
      Signed-off-by: default avatarYuri Tikhonov <yur@emcraft.com>
      ce82ff05
  5. Oct 18, 2008
  6. Apr 22, 2008
  7. Jul 05, 2007
  8. Mar 06, 2007
  9. Jun 07, 2004
  10. Apr 15, 2004
    • Wolfgang Denk's avatar
      * Patches by Pantelis Antoniou, 30 Mar 2004: · 5a8c51cd
      Wolfgang Denk authored
        - add support for the Epson 156x series of graphical displays
          (These displays are serial and not suitable for using a normal
          framebuffer console on them)
        - add infrastructure needed in order to POST any DSPs in a board
      5a8c51cd
  11. Jan 03, 2004
  12. Aug 27, 2002
  13. Nov 12, 2000
Loading