" /> Status for Andrew DeFaria: January 2, 2005 - January 8, 2005 Archives

« December 26, 2004 - January 1, 2005 | Main | January 9, 2005 - January 15, 2005 »

January 7, 2005

ecrdesc

Well I played around with this a little more and came up with a Perl script that will dump ECR descriptions fairly easy. From what I understand that's mostly what we want access to from a Linux box (though I could envision wanting other things perhaps in the future). The problem as I see it is that this script will only run on lynx12. It should be runnable from any machine really however you would need to install the DBD module for Informix for Perl access. Unfortunately this requires at least an Informix Client SDK and that's not free! :-(

Here's the simple script (currently at lynx12:/tmp/ecrdesc.pl):

#!/usr/bin/perl
################################################################################
#
# File:         ecrdesc
# Description:  This script will dump out the description for the ECR #(s)
#               passed in.
# Author:       Andrew@DeFaria.com
# Created:      Fri Jan  7 15:35:13 PST 2005
# Language:     Perl
#
# (c) Copyright 2005, LynxWorks Inc., all rights reserved
#
################################################################################
use strict;
use warnings;
use DBI;

my $DB;

# Called when a database error has occurred
sub DBError {
  my $msg       = shift;
  my $statement = shift;

  print $msg . "\nError #" . $DB->err . " " . $DB->errstr . "\n";

  if (defined $statement) {
    print "SQL Statement: $statement\n";
  } # if

  exit $DB->err;
} # DBError

# Connect to database. Note this is using anonymous access (read only)
$DB = DBI->connect("DBI:Informix:lynxmigr1")
  or DBError "Unable to open database";

# Loop through ECR #s from the command line
foreach my $ecr (@ARGV) {
  print "ECR #: $ecr\n";

  my $statement    = "select description from defect where pkey=\"$ecr\"";
  my $sth    = $DB->prepare ($statement)
    or DBError "Unable to prepare statement", $statement;

  $sth->execute ()
    or DBError "Unable to execute statement", $statement;

  # Defect records are unique per pkey (AKA ECR) there for there will
  # only be one entry in @row. Also the description is returned as one
  # large string.
  my @row = $sth->fetchrow_array;

  if (!@row) {
    # @row is empty if there was no ECR by that number
    print "Nothing found!\n";
  } else {
    my $desc = pop @row;
    print "Description:\n" . "-" x 80 . "\n" . $desc . "\n" . "-" x 80 . "\n";
  } # if
} # foreach

$DB->disconnect;

exit;

January 6, 2005

Files4ecr

  • Finished up files4ecr
  • PPC toolchain build W/23084 is failing

files4ecr

From the gnu.cvs.help newsgroup I learned that doing a cvs log of everything then grepping through that is much faster than interrogating each file with cvs log. I then reorganized files4ecr to work in the following manner:

It occurred to me that often we wish to know, or pull, the file revision associated with an ECR #. I've created a script called files4ecr that accomplishes this:

saturn:files4ecr-u
Usage: files4ecr [-v] [-d] [-l] [-x] [-u] <ecr>

Where:
 
        -v:     Turn on verbose mode (Default: off)
        -d:     Turn on debug mode (Default: off)
        -l:     Local directory only, no recursion
        -x:     Turn on execute mode (Default: off)
        -u:     Dsplay usage
        ecr     ECR number to search for

The performance for this script is pretty good, depending on the amount of information in the CVS logs. Here's an example of it's usage:

saturn:files4ecr 20505
SETUP.csh: 10.2 - Out of date
etc/tconfig: 10.2 - Already up to date
SETUP.bash: 10.6 - Out of date
etc/ttys-arm: 1.1 - Already up to date
Makefile: 10.13 - Out of date

In noexecute mode it just displays the file and the revision of the file associated with that ECR. The -l option is similar to cvs' -l option:

saturn:files4ecr -l 20505
SETUP.csh: 10.2 - Out of date
SETUP.bash: 10.6 - Out of date
Makefile: 10.13 - Out of date

Also, like cvs, files4ecr operates in the current context and current working directory.

With -x turned on files4ecr will perform the cvs update commands necessary to "pull" the versions for the ECR:

saturn:files4ecr -x 20505
cvs update -r10.2  SETUP.csh - Updated
cvs update -r10.2  etc/tconfig - Already up to date
cvs update -r10.6  SETUP.bash - Updated
cvs update -r1.1  etc/ttys-arm - Already up to date
cvs update -r10.13  Makefile - Updated

And we can see that the update has taken place:

saturn:files4ecr 20505
SETUP.csh: 10.2 - Already up to date
etc/tconfig: 10.2 - Already up to date
SETUP.bash: 10.6 - Already up to date
etc/ttys-arm: 1.1 - Already up to date
Makefile: 10.13 - Already up to date

Anybody interested in such a script?

Note: I've noticed that "ECR Number:" is not necessarily a consistent indicator of an ECR number. I search for several strings:

/^ECR Number: (\d*)$/    or
/^ECR# (\d*)$/           or
/^ECR # (\d*)$/          or
/^\s*ECR (\d*)/

I've also noticed that a single ECR number may be attached to several revisions. files4ecr takes the latest revision in such cases.

PPC toolchain build W/23084 is failing

Preliminary investigation shows that while attempting to configure libiberty the build process is unable to use gcc to compile things. It seems to be lacking a crt1.o

January 4, 2005

files4ecr.pl

The algorithm that files4ecr.pl uses is indeed slow. Combing through lynxos looking for files involved in ECR 20591 took:

real    416m30.889s
user    6m43.900s
sys     1m42.770s

Yikes!

Building Native Toolchain for PPC

Here's the plan:

  1. Build Toolchain with PPC fix ECR 23084
  2. Build LynxOS with the new toolchain
  3. Build Toolchain natively

Toolchain build with PPC ECR 23084 fix

Seems the individual files for this ECR have already been applied to the work area so I just need to build. Here what I did:

  • In dopey:/export/build1/LYNXOS_500/build/toolchain/3.2.2 I created a directory named 010405 (for today's date).
  • Copied a Makefile from 121804/Makefile. With the toolchain all we need is a good make file, make sure that it's SRCDIR is correct (this one points to /export/build1/LYNXOS_500/work-area/toolchain/3.2.2/toolchain/src) and that you source SETUP.bash setting ENV_PREFIX and target properly (I used /export/build1/LYNXOS_500/build/lynxos/120604-B/ppc and, of course, PPC for a target)
  • Sourced SETUP.bash
  • Did make install > install.log 2>&1

TOT Build Failure

  • Unable to build TOT due to error in definition of atoi

Is there a known problem with TOT build? Cause I'm getting an error saying essentially that "atoi is undefined".

gcc -g -O2 -o named aclconf.o client.o config.o control.o controlconf.o interfac
emgr.o listenlist.o log.o logconf.o main.o notify.o query.o server.o sortlist.o
tkeyconf.o tsigconf.o update.o xfrout.o zoneconf.o lwaddr.o lwresd.o lwdclient.o
lwderror.o lwdgabn.o lwdgnba.o lwdgrbn.o lwdnoop.o lwsearch.o  unix/os.o ../../
lib/lwres/liblwres.a ../../lib/dns/libdns.a   ../../lib/isccfg/libisccfg.a ../..
/lib/isccc/libisccc.a ../../lib/isc/libisc.a  -lnsl
/export/build1/LYNXOS_500/build/lynxos/120604-C/x86/lib/libnsl.a(getgrent.as.o):
In function `getgrent':
getgrent.as.o(.text+0xb4): undefined reference to `atoi'
/export/build1/LYNXOS_500/build/lynxos/120604-C/x86/lib/libnsl.a(getgrent.as.o):
In function `fgetgrent':
getgrent.as.o(.text+0x2b8): undefined reference to `atoi'
/export/build1/LYNXOS_500/build/lynxos/120604-C/x86/lib/libnsl.a(getpwent.as.o):
In function `getpwent':
getpwent.as.o(.text+0xb4): undefined reference to `atoi'
getpwent.as.o(.text+0xce): undefined reference to `atoi'
/export/build1/LYNXOS_500/build/lynxos/120604-C/x86/lib/libnsl.a(getpwent.as.o):
In function `getpw':
getpwent.as.o(.text+0x29e): undefined reference to `atoi'
/export/build1/LYNXOS_500/build/lynxos/120604-C/x86/lib/libnsl.a(getpwent.as.o)(
.text+0x34c): more undefined references to `atoi' follow
collect2: ld returned 1 exit status
make[4]: *** [named] Error 1

It seems that the problem is in strtol.c version 10.2, which says that the definition was moved to stdlib.h, and stdlib.h appears to have it, yet the build fails anyway...

Looking at the compilation line for strtol.c I see it produces strtol.as.o, which in a previous successful build yeilds:

$ nm strtol.as.o
        U __ctype
        U __divdi3
        U __moddi3
        U _errno
00000208 T atoi
000001f4 T atol
00000000 T strtol

But in this build yeilds:

$ nm strtol.as.o
        U __ctype
        U __divdi3
        U __moddi3
        U _errno
00000208 T atoi
000001f4 T atol
00000000 T strtol

So how do we fix this error?

January 3, 2005

files4ecr.pl/Building TOT as per instructions

  • Worked on getting files4ecr.pl to work
  • Attempted to rebuild TOT using the documentation created so far as a guide. Ran out of disk space! :-(
  • More documentation of build/test/release process

files4ecr.pl

The daily CVS Checkin Log works by creating a temporary CVS area based on a tag then doing a cvs update capturing what files have changed. Those files are examined and a report is produced by ECR number.

While this works fairly well and is relatively optimized (only working on the files that changed since the label) it may not be that accurate. It seems to assume that all files for an ECR are checked in together and on the same day. What if, for example, somebody checked in a file for an ECR days ago and it now checking in the rest of the work? The files reported for this ECR may be incomplete.

Here's an example of where this happened. In today's CVS Checkin Log email the following files are listed as associated with ECR # 20591:

ECR Number:  20591
	src/lib/libc/strto_int.c              10.2    	zhuravle	2004/12/27 16:11:21
	src/lib/libc/strto_real.c             10.2    	zhuravle	2004/12/27 16:09:47
	src/lib/libc/strto_real.h             10.2    	zhuravle	2004/12/27 16:09:47
	src/lib/libc/strtod.c                 10.4    	zhuravle	2004/12/27 16:09:47
	src/lib/libc/strtof.c                 10.2    	zhuravle	2004/12/27 16:09:47
	src/lib/libc/strtoimax.c              10.2    	zhuravle	2004/12/27 16:11:58
	src/lib/libc/strtol.c                 10.2    	zhuravle	2004/12/27 16:11:58
	src/lib/libc/strtold.c                10.2    	zhuravle	2004/12/27 16:09:48
	src/lib/libc/strtoll.c                10.3    	zhuravle	2004/12/27 16:11:58
	src/lib/libc/strtoul.c                10.2    	zhuravle	2004/12/27 16:11:58
	src/lib/libc/strtoull.c               10.3    	zhuravle	2004/12/27 16:11:58
	src/lib/libc/strtoumax.c              10.2    	zhuravle	2004/12/27 16:11:58
	usr/include/rcsid.h                   10.2    	zhuravle	2004/12/27 15:57:50
	usr/include/stdlib.h                  10.10   	zhuravle	2004/12/27 16:07:26

Yet thoroughly scanning the CVS logs we find:

ECR Number: 20591 Nbr of files: 25

Nbr Path/File                           Version   Author    Date
--- ----------------------------------- ------- ----------- -------------------
  1 strtoull.c                           10.3   zhuravle    2004/12/27 16:11:58
  2 strtoull.c                           10.2   zhuravle    2004/10/22 12:04:48
  3 Makefile                             10.18  zhuravle    2004/10/22 12:04:47
  4 strto_int.c                          10.2   zhuravle    2004/12/27 16:11:21
  5 strto_int.c                          10.1   zhuravle    2004/10/22 12:04:48
  6 strtold.c                            10.2   zhuravle    2004/12/27 16:09:48
  7 strtold.c                            10.1   zhuravle    2004/10/22 12:04:48
  8 strtoll.c                            10.3   zhuravle    2004/12/27 16:11:58
  9 strtoll.c                            10.2   zhuravle    2004/10/22 12:04:48
 10 strtoul.c                            10.2   zhuravle    2004/12/27 16:11:58
 11 strtoul.c                            10.1   zhuravle    2004/10/22 12:04:48
 12 strtoimax.c                          10.2   zhuravle    2004/12/27 16:11:58
 13 strtoimax.c                          10.1   zhuravle    2004/10/22 12:04:48
 14 strtoumax.c                          10.2   zhuravle    2004/12/27 16:11:58
 15 strtoumax.c                          10.1   zhuravle    2004/10/22 12:04:48
 16 strto_real.c                         10.2   zhuravle    2004/12/27 16:09:47
 17 strto_real.c                         10.1   zhuravle    2004/10/22 12:04:48
 18 strto_real.h                         10.2   zhuravle    2004/12/27 16:09:47
 19 strto_real.h                         10.1   zhuravle    2004/10/22 12:04:48
 20 strtod.c                             10.4   zhuravle    2004/12/27 16:09:47
 21 strtod.c                             10.3   zhuravle    2004/10/22 12:04:48
 22 strtof.c                             10.2   zhuravle    2004/12/27 16:09:47
 23 strtof.c                             10.1   zhuravle    2004/10/22 12:04:48
 24 strtol.c                             10.2   zhuravle    2004/12/27 16:11:58
 25 strtol.c                             10.1   zhuravle    2004/10/22 12:04:48

Now files4ecr.pl thoroughly checks all CVS logs (based on the paths it is givin that is) but this takes a lot of time.

Note that Makefile is listed by files4ecr.pl but not in the daily CVS Checking Log. That's because Makefile was checked in with that ECR number a while ago. The daily CVS Checkin Log does not reflect this historical fact.

Also note that ECR's unlike tags that can only exist on one revision, ECR numbers are just strings placed in the check in comment. Thus there is the possibility that they will exist on more than one revision (e.g. strtod.c versions 10.4 and 10.3). IOW checking in another version of a file and using the same ECR number will not remove the ECR number in the command of a previous version of the file!