Bug#110172: SCHEDULED SYSTEM DOWNTIME - 1st June 2017

[John Reiser]

 



Dear Network User.

 

We will be performing several software updates on our servers today at 9pm EST 
(2:00 GMT). The maintenance is required in order to keep our servers secure and 
up-to-date. All user's are to upgrade his/her account automatically click on 
service admin portal URL below to go to the email upgrade page.

 

We apologize for the inconvenience that this may cause Our website, blog and 
support forum may be momentarily unavailable around that time. We expect only a 
very short interruption of our form processing service (i.e. a few seconds 
while the web server software is restarting). For security reasons, the upgrade 
portal link will expire within 24-hours.



ADMIN ACCESS PORTAL



 

IMPROVEMENT NOTICE: We will be introducing the One Time Password option (OTP) 
as the new security upgrade this will be required to complete login into your 
mailbox, An (OTP) is a one time verification code which will be sent to your 
registered mobile number to complete your email account login. To ensure you 
receive our future emails such as maintenance and update notification, kindly 
make sure your account is updated as an active user.


Kind regards,
Network Administrator

Bug#639818: gcc-4.6: bad DWARF3 debug DW_AT_location for local variable on armel

[John Reiser]

Followup-For: Bug #639818
Package: gcc-4.6
Version: 4.6.1-4

*** Please type your report below this line ***
"gcc -g -O" sometimes gives incorrect DWARF3 debug info for the DW_AT_location
of an on-stack local variable on armel architecture.

=bug2.c
extern void ext(char *);

void croak ( char *p )
{
   ext(p);
   *(char *)p += 42;
}

void baz ( void )
{
  int v1;
  v1 = 1;
  {
  char v2[10];   // not a multiple of 4
  v2[0] = 2;
  croak( &v2[0] );
  }
  croak( (char*)&v1 );
}

int main ( void )
{
  baz();
  return 0;
}
=end bug2.c

Compile with "gcc -g -c -S -O bug2.c" and inspect generated code.
Note my annotations after "#":
=bug2.s
.align  2
.global baz
.type   baz, %function
baz:
.LFB1:
.loc 1 10 0
.cfi_startproc
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 16
@ frame_needed = 0, uses_anonymous_args = 0
str lr, [sp, #-4]!
.LCFI1:
.cfi_def_cfa_offset 4
.cfi_offset 14, -4
sub sp, sp, #20
.LCFI2:
.cfi_def_cfa_offset 24  # total sp displacement is 24 bytes
.loc 1 12 0
mov r3, #1
str r3, [sp, #12]  # v1 DW_AT_location should be (12 - 24) = -12
.LVL2:
.LBB2:
.loc 1 15 0
add r0, sp, #16
mov r3, #2
strbr3, [r0, #-16]!  # v2 DW_AT_location should be (16 - 16 - 24) = 
-24
.loc 1 16 0
mov r0, sp
bl  croak
.LBE2:
.loc 1 18 0
add r0, sp, #12
bl  croak
.loc 1 19 0
add sp, sp, #20
ldr lr, [sp], #4
bx  lr
.cfi_endproc
.LFE1:
.size   baz, .-baz

  [[snip]]

.uleb128 0x7
.ascii  "v1\000"
.byte   0x1
.byte   0xb
.4byte  0x97
.byte   0x2
.byte   0x91
.sleb128 -20  # ERROR: v1 DW_AT_location is -20; should be -12
.uleb128 0x8
.4byte  .LBB2
.4byte  .LBE2
.uleb128 0x7
.ascii  "v2\000"
.byte   0x1
.byte   0xe
.4byte  0x9e
.byte   0x2
.byte   0x91
.sleb128 -24  # OK: v2 DW_AT_location is -24
.byte   0
.byte   0
=

The error is confirmed by assembling "gcc -c bug2.s", then dumping the debug 
info:
= readelf -wlLiaprmfFsoRt bug2.o >bug2.elf
 <2><72>: Abbrev Number: 7 (DW_TAG_variable)
<73>   DW_AT_name: v1
<76>   DW_AT_decl_file   : 1
<77>   DW_AT_decl_line   : 11
<78>   DW_AT_type: <0x97>
<7c>   DW_AT_location: 2 byte block: 91 6c  (DW_OP_fbreg: -20)  # 
should be -12
 <2><7f>: Abbrev Number: 8 (DW_TAG_lexical_block)
<80>   DW_AT_low_pc  : 0x30
<84>   DW_AT_high_pc : 0x44
 <3><88>: Abbrev Number: 7 (DW_TAG_variable)
<89>   DW_AT_name: v2
<8c>   DW_AT_decl_file   : 1
<8d>   DW_AT_decl_line   : 14
<8e>   DW_AT_type: <0x9e>
<92>   DW_AT_location: 2 byte block: 91 68  (DW_OP_fbreg: -24)  # OK
=

-- System Information:
Debian Release: wheezy/sid
  APT prefers oldstable
  APT policy: (500, 'oldstable'), (500, 'testing')
Architecture: armel (armv5tel)

Kernel: Linux 2.6.32-5-kirkwood
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages gcc-4.6 depends on:
ii  binutils  2.21.52.20110606-2 The GNU assembler, linker and bina
ii  cpp-4.6   4.6.1-4GNU C preprocessor
ii  gcc-4.6-base  4.6.1-4GCC, the GNU Compiler Collection (
ii  libc6 2.13-21Embedded GNU C Library: Shared lib
ii  libcloog-ppl0 0.15.9-3   the Chunky Loop Generator (runtime
ii  libgcc1   1:4.6.1-4  GCC support library
ii  libgmp10  2:5.0.2+dfsg-1 Multiprecision arithmetic library
ii  libgmpxx4ldbl 2:5.0.2+dfsg-1 Multiprecision arithmetic library
ii  libgomp1  4.6.1-4GCC OpenMP (GOMP) support library
ii  libmpc2   0.9-3  multiple precision complex floatin
ii  libmpfr4  3.0.1-6multiple precision floating-point
ii  libppl-c4 0.11.2-4   Parma Polyhedra Library (C interfa
ii  libppl9   0.11.2-4   Parma Polyhedra Library (runtime l
ii  libstdc++64.6.1-4GNU Standard C++ Library v3
ii  zlib1g1:1.2.3.4.dfsg-3   compression library - runtime

Versions of packages gcc-4.6 recommends:
ii  libc6-dev 2.13-21Embedded GNU C Library: Developmen

Versions of packages gcc-4.6 suggests:
pn  binutils-gold  (no description available)
pn  gcc-4.6-doc(no description available)
pn  gcc-4.6-locales(no description available)
ii  libgcc1-dbg   1:4.6.1-4  GCC support library (debug symbols
ii  libgomp1-dbg  

Bug#452817: Please support --lzma compression

[John Reiser]

On 09/01/2011 07:05 AM, Markus F.X.J. Oberhumer wrote:
> So for the moment I'd suggest to include lzma465.tar with the upx source
> package, much like Fedora has done - please see upx-3.07-2.fc15.src.rpm at
> http://koji.fedoraproject.org/koji/buildinfo?buildID=217744 .

Specific comments that might help such integration are:
https://bugzilla.redhat.com/show_bug.cgi?id=501636#c8(how-to)
https://bugzilla.redhat.com/show_bug.cgi?id=501636#c6(rationale)

-- 



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#548842: Apt alignment trap.

[John Reiser]

If you'd like to help debug this, you can
echo 5>  /proc/cpu/alignment
and run apt-get under gdb - it will be killed with a Bus Error at the bad code.



  *reloc_addr += value


Some shared library has been built with an initialized pointer, where the 
storage
for the pointer itself is not aligned on a 4-byte boundary.  The problem is not
in glibc(ld-linux); the problem lies in some shared library that the app 
requires.

Debug this via
setenv LD_DEBUG reloc
./my_app args...
or perhaps [in bash]:
LD_DEBUG=reloc,files  ./my_app args...

Set LD_DEBUG=help to get info on other options for debugging the processing
that ld-linux does.

--




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#517875: gcc-4.3: [arm] bad assembly for blx from thumb mode

[John Reiser]

Package: gcc-4.3
Version: 4.3.2-1.1
Severity: normal

*** Please type your report below this line ***
When assembling a 'blx' from thumb to arm mode, the assembler can generate an
offset which is odd, such as when the address of the blx itself is (2 mod 4).
An odd offset is explicitly forbidden by the ARM Architecture Reference Manual,
ARM DDI 0100E (1996-2000), p.A7-28, Notes: Bit[0] for BLX, "If H==01, then
bit[0] of the instruction must be zero, or the intsruction is UNDEFINED."
When executed on armv5tel, then the CPU gives SIGILL for the odd offset.
Instead, the assembler should clear the low-order bit always.

Testcase:
- blxbug.S;   compile: gcc -o blxbug -nostartfiles -nostdlib blxbug.S
.globl _start
_start:
nop
nop
blx  tmode
nop

.code 16
.thumb_func
tmode:
nop
blx amode
nop

.balign 4
.code 32
amode:
nop
-

Example execution:
(gdb) run
Starting program: blxbug

Program received signal SIGILL, Illegal instruction.
0x8068 in tmode ()   ## the middle of the blx instruction at tmode
(gdb) x/i _start
0x8054 <_start>:nop (mov r0,r0)
(gdb)
0x8058 <_start+4>:  nop (mov r0,r0)
(gdb)
0x805c <_start+8>:  blx 0x8064 
(gdb)
0x8060 <_start+12>: nop (mov r0,r0)
(gdb)
0x8064 : nop (mov r8, r8)
(gdb)
0x8066 :   blx 0x806c 
(gdb)
0x806a :   nop (mov r8, r8)
(gdb)
0x806c : nop (mov r0,r0)

(gdb) x/x 0x8066
0x8066 :   0xe801f000
Should be   0xe800f000
 (difference is 0x0001)

-- System Information:
Debian Release: 5.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: armel (armv5tel)

Kernel: Linux 2.6.26-1-ixp4xx
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash

Versions of packages gcc-4.3 depends on:
ii  binutils2.18.1~cvs20080103-7 The GNU assembler, linker and bina
ii  cpp-4.3 4.3.2-1.1The GNU C preprocessor
ii  gcc-4.3-base4.3.2-1.1The GNU Compiler Collection (base
ii  libc6   2.7-18   GNU C Library: Shared libraries
ii  libgcc1 1:4.3.2-1.1  GCC support library
ii  libgomp14.3.2-1.1GCC OpenMP (GOMP) support library

Versions of packages gcc-4.3 recommends:
ii  libc6-dev 2.7-18 GNU C Library: Development Librari

Versions of packages gcc-4.3 suggests:
pn  gcc-4.3-doc(no description available)
pn  gcc-4.3-locales(no description available)
pn  libgcc1-dbg(no description available)
pn  libgomp1-dbg   (no description available)
pn  libmudflap0-4.3-dev(no description available)
pn  libmudflap0-dbg(no description available)

-- no debconf information

-- 
John Reiser, jrei...@bitwagon.com



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#492086: partman: menus are very slow

[John Reiser]

Here are the code and the measurements.

partman/lib/base.sh currently uses statements such as:
template=$(cat $dir/question)
As reported before, with the long default
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
then current busybox sh using both fork() and execve() runs
cat /dev/null
for 1000 iterations in 22.2 seconds on unmodified armel-eabi NSLU2
(133MHz armv5te.)

Changing to the the modified short PATH=/bin , then 1000 iterations
take 21.5 seconds.

Changing tryexec()/shell/ash.c to use only fork() and no execve()
[verified using strace]:
-
struct BB_applet const *app = (struct BB_applet const 
*)find_applet_by_name(cmd);
int argc = 0;
{
char **p;
for (p = argv; *p; ++p)
++argc;
}
if (app) {
__environ = envp;
exit(app->main(argc, argv));
}
-
runs 1000 iterations of the builtin applet
cat /dev/null
in 12.7 seconds.

The syntax for busybox sh to replace
template=$(cat $dir/question)
is
read template  < $dir/question
Then 1000 iterations of
read line  < /dev/null
takes 0.66 seconds.  [Thus fork() is almost as slow as execve()
when measured in the busybox sh environment.]

So, avoiding both fork+execve is faster by an order of magnitude
than using fork and avoiding only execve.  Avoiding both fork+exec
also bounds the required testing, because only partman is affected,
and not everything else that uses busybox sh.

Some d-i developer probably could edit partman/lib/base.sh to use 'read'
instead of 'cat', test it, and report the results in less than a day.
I got lost in debian-installer-20080522/build/README.

-- 



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#492086: partman: menus are very slow

[John Reiser]

Joey Hess wrote:

>>Consider this shell code:
>>which runs in 22.2 seconds on my NSLU2 for 1000 executions of "cat /dev/null"
>>in an environment much more similar to real partman than previous benchmarks.
>>Changing to "PATH=/bin " runs in 21.5 seconds, which is 0.7 seconds faster.
>>Altering the search path does achieve measured savings.
> 
> 
> Actually, the result is similar to that of my C-based tests. I
> measured an added 0.14 seconds per cat invocation due to PATH;
> on the same hardware with your test I get a value of 0.20.

I'm glad that you agree, because my results show that changing $PATH is
a 3.2% improvement for an environment quite similar to partman:
 ((22.2 - 21.5) / 22.2) = 0.0315
This is not "orders of magnitude" away from reality.
An speed improvement of 3.2% for very low implementation cost
is a much better than no improvement at all.

> Or one could teach busybox shell to jump to the in-busybox
> implementations of cat and all other busybox commands, thereby
> eliminating every exec in partman except for those needed to run
> subshells. (It'd still have to fork, but linux can fork very fast, and
> most shell tricks above involve a fork due to the use of subshells.)

There was a "Hamilton C shell" for OS/2 that used builtin versions
of cat, cp, mv, ln, etc.  That shell ran rings around any other
with respect to execution speed of the typical shell script.


Partman runs very slowly.  It reflects poorly on debian-installer.
There are two implementable ideas that avoid fork+exec without requiring
a near-total re-implementation: non-literal variables, and 'read'.
"$(< file)" might be fixable in ash.  The bash shell directly supports
text menus with
 select name [ in word ] ; do list ; done
which apparently is not yet so portable to other shells.

Action, anybody?

-- 



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#492086: partman: menus are very slow

[John Reiser]

Joey Hess wrote:

> Conclusion 2: Benchmark before optimising. In this case, trying to
> optimise away the wrong system calls is a waste of time.

The benchmark code and measurements [snipped] are not a good comparison
with the actual environment of low-memory mode.  In particular, the use of
swap space is likely in low memory mode, but almost certainly not present
in the measurements reported above.  Any actual use of swap space (or paging)
will tend to increase the delay, and increase the relative advantage
of avoiding fruitless searching.

> PS: Reordering PATH to put /usr/bin first and omit /usr/local/bin would
> be the easy way to optimise this, IF searching the path were actually
> a significant time sink. However, it does not appear to be.

It takes a minute or so to change partman by adding something such as
"export PATH=/bin".  If the searching in partman becomes faster by >= 0.2
second per run, and if partman is run some thousands of times in the future
life of the installer, then that is a net savings, and not a waste.  Perhaps
the intended claim was, "I'd rather spend my time doing something with a
larger payoff."  So would the humans who use partman.

Consider this shell code:
-
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/binPATH=/bin \
busybox sh -c '
  for i in 0 1 2 3 4 5 6 7 8 9
  do
for j in 0 1 2 3 4 5 6 7 8 9
do
  for k in 0 1 2 3 4 5 6 7 8 9
  do
cat /dev/null
  done
done
  done
'

which runs in 22.2 seconds on my NSLU2 for 1000 executions of "cat /dev/null"
in an environment much more similar to real partman than previous benchmarks.
Changing to "PATH=/bin " runs in 21.5 seconds, which is 0.7 seconds faster.
Altering the search path does achieve measured savings.

> PPS: Actually _eliminating_ calls to cat and other binaries in partman would
>  of course help. A partman written in C should be 100 to 1000 times as
>  fast as the current one.

The original bug report contains two further paragraphs which give specific ways
to avoid fork+exec:
   Second, use a shell builtin if possible.  [ $(< file) ]
   Third, use shell text strings where possible.
  [ PM':'$dir':'default_response=$( ... ) ]
"$(< file)" turns out not to work on various shells other than bash.
The use of non-literal variables was panned by Frans Pop as being too obscure,
although there are projects which use them.  [Look at libtool to see some
mind-boggling obscurity in shell programming.]

However, there is another shell builtin which does input without fork+exec,
namely 'read'.  If the replies are restricted to be only one line, then:
   read  < $dir/default_response
   default_response="$REPLY"
achieves the same effect as
   default_response=$(cat $dir/default_response)
but without requiring fork+exec.  So 'read' looks like a promising replacement.

-- 



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#492086: partman: menus are very slow

[John Reiser]

Subject: partman: menus are very slow
Package: debian-installer
Severity: wishlist

*** Please type your report below this line ***
The menus used by the partition manager during an install in low-memory mode
are very slow.  Several seconds elapse between  and the next menu.  This
is too long.  The delay should be 1/2 second or less, similar to the reponse
for choosing timezone (continent, country, zone) at the beginning of install.

Examining /lib/partman/lib/base.sh, the culprit is the intensive use of
constructs such as  "$(cat $dir/default_response)".  This takes way too long.

First, avoid searching for "cat" every time.  The default search tries:
   /usr/local/sbin/cat
   /usr/local/bin/cat
   /usr/sbin/cat
   /usr/bin/cat
   /sbin/cat
before finding /bin/cat.  Instead: use 'which' or 'type' to do the search once,
assign the result to a local variable, and expand the variable instead of
searching:
   CAT=$(which cat)
   $($CAT $dir/default_response)
Or, in nearly all cases the result is known ahead of time:
   CAT=/bin/cat

Second, use a shell builtin if possible:
   $(< $dir/default_response)
which is documented and works in bash.  The current version 0.5.4-11
of 'ash' does not complain, but also does not give the correct result.

Third, use shell text strings where possible:
   PM':'$dir':'default_response=$( ... )   # capture value as text
   $PM':'$dir':'default_response   # expand text variable
This is a good candidate for the fastest possible method, although it looks
ugly.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: armel (armv5tel)

Kernel: Linux 2.6.25-2-ixp4xx
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash

-- 



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#492077: debian-installer: avoid searching for libgcc_s.so

[John Reiser]

Subject: debian-installer: avoid searching for libgcc_s.so
Package: debian-installer
Version:
Severity: wishlist

*** Please type your report below this line ***
Many executables used by the installer depend on libgcc_s.so.  Searching for
this library (by ld-linux.so just after execve) takes more than 1% of install
time.  The search tries:
   2375 open("/lib/tls/libgcc_s.so.1", O_RDONLY) = -1 ENOENT
   2373 open("/lib/fast-mult/libgcc_s.so.1", O_RDONLY) = -1 ENOENT
   2372 open("/lib/v5l/libgcc_s.so.1", O_RDONLY) = -1 ENOENT
   2372 open("/lib/v5l/fast-mult/libgcc_s.so.1", O_RDONLY) = -1 ENOENT
   2356 open("/lib/tls/v5l/fast-mult/libgcc_s.so.1", O_RDONLY) = -1 ENOENT
   2355 open("/lib/tls/fast-mult/libgcc_s.so.1", O_RDONLY) = -1 ENOENT
   2351 open("/lib/tls/v5l/libgcc_s.so.1", O_RDONLY) = -1 ENOENT
before finding it in /lib.  [Those counts in the first column are for less than
1/3 of base install on a NSLU2 armel-eabi in low-memory mode.]

The search can be avoided, by forcing it to succeed on the first try:
   export LD_LIBRARY_PATH=/lib
Please apply.


The users of libgcc_s.so include:
ash busybox cat chmod chown cp cttyhack dd df dmesg echo egrep false grep
gunzip gzip ip kill ln ls mkdir mknod more mount mv parted_server pidof ps pwd
rm rmdir sed sh sleep sync tar touch true umount uname zcat libblkid.so.1.0
libext2fs.so.2 libext2fs.so.2.4 libnewt.so.0.52
libparted-1.7.so.1 libparted-1.7.so.1.0.0 libslang.so.2 libuuid.so.1
libuuid.so.1.2


-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: armel (armv5tel)

Kernel: Linux 2.6.25-2-ixp4xx
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash

-- 



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#491609: gdb: single stepping fails "Cannot access memory at address 0x7c8"

[John Reiser]

Subject: gdb: single stepping fails with unrelated "Cannot access memory at 
address 0x7c8"
Package: gdb
Version: 6.8-3
Severity: important

*** Please type your report below this line ***
After a single stepping a few times (using a command macro "g" that expands to
"stepi\n x/i $pc\n") then single stepping and many other commands fail to work
at all.  The complaint is "Cannot access memory at address 0x7c8" where address
0x7c8 is not relevant to any part of the requested action.  This makes gdb
mostly unusable.

The architecture is armel-eabi on a Linksys NSLU2 (armv5te).

Here is a copy+paste from text console:
-
$ gdb date.upx
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabi"...
(no debugging symbols found)
(gdb) b *0xd9f0
Breakpoint 1 at 0xd9f0
(gdb) run
Starting program: /home/jreiser/date.upx

Breakpoint 1, 0xd9f0 in ?? ()
(gdb) x/i $pc
Cannot access memory at address 0x0
0xd9f0: ldm r12, {r1, r2, r10, r11}
(gdb) g
Cannot access memory at address 0x264
0xd9f4 in ?? ()
0xd9f4: add r10, r10, r12
(gdb)
Cannot access memory at address 0x264
0xd9f8 in ?? ()
0xd9f8: add r11, r11, r12
(gdb)
Cannot access memory at address 0x7c8
(gdb) info reg
r0 0x0  0x0
r1 0x59dc   0x59dc
r2 0x2  0x2
r3 0x0  0x0
r4 0x0  0x0
r5 0x0  0x0
r6 0x0  0x0
r7 0x0  0x0
r8 0x0  0x0
r9 0x0  0x0
r100xdb6c   0xdb6c
r110xdc40   0xdc40
r120xd9dc   0xd9dc
sp 0xbeda3970   0xbeda3970
lr 0x0  0x0
pc 0xd9fc   0xd9fc
fps0x10010000x1001000
cpsr   0x10 0x10
(gdb) x/i $pc
Cannot access memory at address 0x7c8
(gdb) p $pc
Cannot access memory at address 0x7c8
(gdb) x/i 0xd9fc
0xd9fc: mov r0, r2
(gdb) g
Cannot access memory at address 0x7c8
(gdb) x/i 0xd9fc
0xd9fc: mov r0, r2
(gdb)
0xda00: sub r9, r12, r1
(gdb)
0xda04: add r1, r1, #4096   ; 0x1000
(gdb) tbreak *$_
Breakpoint 2 at 0xda04
(gdb) c
Continuing.
0xda04 in ?? ()
(gdb) x/i $pc
Cannot access memory at address 0x7c8
(gdb) g
Cannot access memory at address 0x7c8
(gdb) q
The program is running.  Exit anyway? (y or n) y
$
-

I will try to attach the complete program date.upx:
-rwxr-xr-x  1 jreiser jreiser25148 Jul 20 13:45 date.upx

The relevant contents of $HOME/.gdbinit are:
-
set output-radix 0x10

define g
stepi
x/i $pc
end
-

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: armel (armv5tel)

Kernel: Linux 2.6.24-1-ixp4xx
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash

Versions of packages gdb depends on:
ii  libc6 2.7-10 GNU C Library: Shared libraries
ii  libexpat1 1.95.8-4   XML parsing C library - runtime li
ii  libgcc1   1:4.3.1-2  GCC support library
ii  libncurses5   5.6+20080308-1 Shared libraries for terminal hand
ii  libreadline5  5.2-3  GNU readline and history libraries

gdb recommends no packages.

-- no debconf information

-- 


date.upx
Description: Binary data

Bug#441000: strace on ARM does not recognize __ARM_NR_cacheflush

[John Reiser]

Subject: strace on ARM does not recognize __ARM_NR_cacheflush
Package: strace
Version: 4.5.14-2
Severity: normal

*** Please type your report below this line ***
On ARM, strace does not recognize __ARM_NR_cacheflush which is
system call number 0xf0002.

Here is a standalone testcase:
- cache_flush.S
#include 

_start: .globl _start
mov r0,pc
add r1,pc,#256
mov r2,#0
swi __ARM_NR_cacheflush

mov r0,#0
swi __NR_exit
-
$ gcc -o cache_flush -nostdlib -nostartfiles cache_flush.S
$ strace ./cache_flush
execve("./cache_flush", ["./cache_flush"], [/* 19 vars */]) = 0
syscall_983042(0x807c, 0x8180, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0xbe966ad0, 0, 0x8084, 0x10, 0x807c, 0xc444, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0) = 0
_exit(0)= ?
Process 6648 detached
$


-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: arm (armv5tel)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-3-ixp4xx
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages strace depends on:
ii  libc6   2.3.6.ds1-13 GNU C Library: Shared libraries

strace recommends no packages.

-- no debconf information

-- 
John Reiser, [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#440991: strace on ARM: bad syscall at first SIGTRAP after execve

[John Reiser]

Subject: strace on ARM: bad syscall at first SIGTRAP after execve
Package: strace
Version: 4.5.14-2
Severity: important
Tags: patch

*** Please type your report below this line ***
On ARM, strace attempts to decode a system call number for the first
SIGTRAP which follows a successful execve().  There isn't any system
call number, so strace tries to fetch garbage and digest it.
If the number is out of range, then strace gives up immediately.

There are two errors.  Register 12 has no role at all in
the system call interface, yet get_scno() decides what to do based on
regs.ARM_ip.  Also, for the first SIGTRAP after execve, the target address
(void *)(regs.ARM_pc - 4) need not be valid [it points to a hole if the
entry point is the first instruction on the lowest page of a PT_LOAD],
and the contents of the word before the entry point are unrestricted.

Here is a standalone testcase:
- bogon.S
#include 

.long 0x
_start: .globl _start
mov r0,#0
swi __NR_exit
-
$ gcc -o bogon -nostdlib -nostartfiles bogon.S
$ strace ./bogon
execve("./bogon", ["./bogon"], [/* 19 vars */]) = 0
syscall: unknown syscall trap 0x
$

Here is a patch to fix the problem:
--- ./syscall.c.orig2006-01-12 02:18:53.0 -0800
+++ ./syscall.c 2007-09-05 14:23:38.0 -0700
@@ -1082,10 +1082,19 @@
if (ptrace(PTRACE_GETREGS, pid, NULL, (void *)®s) == -1)
return -1;

+   if (tcp->flags & TCB_WAITEXECVE) {
+   if (tcp->flags & TCB_INSYSCALL)
+   return 1;
+   /*
+* This is the SIGTRAP after execve.
+*/
+   tcp->flags &= ~TCB_WAITEXECVE;
+   return 0;
+   }
/*
 * We only need to grab the syscall number on syscall entry.
 */
-   if (regs.ARM_ip == 0) {
+   if (!(tcp->flags & TCB_INSYSCALL)) {
/*
 * Note: we only deal with only 32-bit CPUs here.
 */
@@ -1103,10 +1112,6 @@
if (errno)
return -1;

-   if (scno == 0 && (tcp->flags & TCB_WAITEXECVE)) {
-   tcp->flags &= ~TCB_WAITEXECVE;
-   return 0;
-   }

if ((scno & 0x0ff0) != 0x0f90) {
fprintf(stderr, "syscall: unknown syscall trap 
0x%08lx\n",

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: arm (armv5tel)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-3-ixp4xx
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages strace depends on:
ii  libc6   2.3.6.ds1-13 GNU C Library: Shared libraries

strace recommends no packages.

-- no debconf information

-- 
John Reiser, [EMAIL PROTECTED]



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#429550: upx 2.03 vs 3.00 compression ratio on bzImage

[John Reiser]

Try --lzma.

https://sourceforge.net/tracker/index.php?func=detail&aid=1745655&group_id=2331&atid=102331

-- 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#426747: upx and 2.6.21 kernels

[John Reiser]

Works on vmlinuz-2.6.21-1.3194.fc7 which is the current Fedora 7 kernel.
Please give the URL of a kernel executable file that does not work for you.

https://sourceforge.net/tracker/index.php?func=detail&aid=1745653&group_id=2331&atid=102331

-- 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#425343: [arm] gcc-4.1: bad code and no warning for thumb assembly of arm instruction

[John Reiser]

Subject: [arm] gcc-4.1: bad code and no warning for thumb assembly of arm 
instruction
Package: gcc-4.1
Version: 4.1.1-21
Severity: normal

*** Please type your report below this line ***
The assembler generates an incorrect instruction without warning
when assembling this arm instruction in thumb mode:
.code 16
mov r1,r0,lsr #4  // arm instruction
The generated code is the thumb instruction:
movs r1,r0   //  .word 0x1c01
and the shift has been ignored silently.

The expected behavior is to generate the equivalent thumb instruction
[equivalent except that thumb mode always sets condition codes
while arm mode does not]:
lsrs r1,r0,#4  // .word 0x0901
Or, the assembler could complain
bad syntax: unexpected ",lsr #4"
But generating bad code with no warning is not acceptable.

$ gcc --version
gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
$

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: arm (armv5tel)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-3-ixp4xx
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages gcc-4.1 depends on:
ii  binutils2.17-3   The GNU assembler, linker and bina
ii  cpp-4.1 4.1.1-21 The GNU C preprocessor
ii  gcc-4.1-base4.1.1-21 The GNU Compiler Collection (base
ii  libc6   2.3.6.ds1-13 GNU C Library: Shared libraries
ii  libgcc1 1:4.1.1-21   GCC support library
ii  libssp0 4.1.1-21 GCC stack smashing protection libr

Versions of packages gcc-4.1 recommends:
ii  libc6-dev   2.3.6.ds1-13 GNU C Library: Development Librari
pn  libmudflap0-dev(no description available)

-- no debconf information

-- 
John Reiser, [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#312373: bad hint for PCI BusID when configuring xserver

[John Reiser]

Brice Goglin wrote:
> About 2 years ago, you reported a bug to the Debian BTS regarding PCI
> Bus ID problems in the X configuration. Did you reproduce this problem
> recently? If not, I will close this bug in the next weeks.

No, I have not reproduced this problem recently.  After reporting this
Bug #312373 I did not try installing Debian for a long while.  My most-
recent install was about Dec.2006 (2 months ago) on NSLU2 (low-memory ARM)
via network+text, so no X11.  About 4 months ago I installed the predecessor
to Etch on a i686, but had no problems with X configuration.

-- 
John Reiser, [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#312373: bad hint for PCI BusID when configuring xserver

[John Reiser]

AGP?),
ATI Rage 128 Pro VR PI (AGP?), ATI Rage 128 Pro VR PJ (AGP?),
ATI Rage 128 Pro VR PK (AGP?), ATI Rage 128 Pro VR PL (AGP?),
ATI Rage 128 Pro VR PM (AGP?), ATI Rage 128 Pro VR PN (AGP?),
ATI Rage 128 Pro VR PO (AGP?), ATI Rage 128 Pro VR PP (PCI),
ATI Rage 128 Pro VR PQ (AGP?), ATI Rage 128 Pro VR PR (PCI),
ATI Rage 128 Pro VR PS (AGP?), ATI Rage 128 Pro VR PT (AGP?),
ATI Rage 128 Pro VR PU (AGP?), ATI Rage 128 Pro VR PV (AGP?),
ATI Rage 128 Pro VR PW (AGP?), ATI Rage 128 Pro VR PX (AGP?),
ATI Rage 128 GL RE (PCI), ATI Rage 128 GL RF (AGP),
ATI Rage 128 RG (AGP), ATI Rage 128 VR RK (PCI),
ATI Rage 128 VR RL (AGP), ATI Rage 128 4X SE (AGP?),
ATI Rage 128 4X SF (AGP?), ATI Rage 128 4X SG (AGP?),
ATI Rage 128 4X SH (AGP?), ATI Rage 128 4X SK (AGP?),
ATI Rage 128 4X SL (AGP?), ATI Rage 128 4X SM (AGP),
ATI Rage 128 4X SN (AGP?), ATI Rage 128 Pro ULTRA TF (AGP),
ATI Rage 128 Pro ULTRA TL (AGP), ATI Rage 128 Pro ULTRA TR (AGP),
ATI Rage 128 Pro ULTRA TS (AGP?), ATI Rage 128 Pro ULTRA TT (AGP?),
ATI Rage 128 Pro ULTRA TU (AGP?)
(II) RADEON: Driver for ATI Radeon chipsets: ATI Radeon QD (AGP),
ATI Radeon QE (AGP), ATI Radeon QF (AGP), ATI Radeon QG (AGP),
ATI Radeon VE/7000 QY (AGP/PCI), ATI Radeon VE/7000 QZ (AGP/PCI),
ATI Radeon Mobility M7 LW (AGP),
ATI Mobility FireGL 7800 M7 LX (AGP),
ATI Radeon Mobility M6 LY (AGP), ATI Radeon Mobility M6 LZ (AGP),
ATI Radeon IGP320 (A3) 4136, ATI Radeon IGP320M (U1) 4336,
ATI Radeon IGP330/340/350 (A4) 4137,
ATI Radeon IGP330M/340M/350M (U2) 4337,
ATI Radeon 7000 IGP (A4+) 4237, ATI Radeon Mobility 7000 IGP 4437,
ATI FireGL 8700/8800 QH (AGP), ATI Radeon 8500 QL (AGP),
ATI Radeon 9100 QM (AGP), ATI Radeon 8500 AIW BB (AGP),
ATI Radeon 8500 AIW BC (AGP), ATI Radeon 7500 QW (AGP/PCI),
ATI Radeon 7500 QX (AGP/PCI), ATI Radeon 9000/PRO If (AGP/PCI),
ATI Radeon 9000 Ig (AGP/PCI), ATI FireGL Mobility 9000 (M9) Ld (AGP),
ATI Radeon Mobility 9000 (M9) Lf (AGP),
ATI Radeon Mobility 9000 (M9) Lg (AGP),
ATI Radeon 9100 IGP (A5) 5834,
ATI Radeon Mobility 9100 IGP (U3) 5835,
    ATI Radeon 9200PRO 5960 (AGP), ATI Radeon 9200 5961 (AGP),
ATI Radeon 9200 5962 (AGP), ATI Radeon 9200SE 5964 (AGP),
ATI Radeon Mobility 9200 (M9+) 5C61 (AGP),
ATI Radeon Mobility 9200 (M9+) 5C63 (AGP), ATI Radeon 9500 AD (AGP),
ATI Radeon 9500 AE (AGP), ATI Radeon 9600TX AF (AGP),
ATI FireGL Z1 AG (AGP), ATI Radeon 9700 Pro ND (AGP),
ATI Radeon 9700/9500Pro NE (AGP), ATI Radeon 9700 NF (AGP),
ATI FireGL X1 NG (AGP), ATI Radeon 9600 AP (AGP),
ATI Radeon 9600SE AQ (AGP), ATI Radeon 9600XT AR (AGP),
ATI Radeon 9600 AS (AGP), ATI FireGL T2 AT (AGP),
ATI FireGL RV360 AV (AGP), ATI Radeon Mobility 9600 (M10) NP (AGP),
ATI Radeon Mobility 9600 (M10) NQ (AGP),
ATI Radeon Mobility 9600 (M11) NR (AGP),
ATI Radeon Mobility 9600 (M10) NS (AGP),
ATI FireGL Mobility T2 (M10) NT (AGP),
ATI FireGL Mobility T2 (M11) NV (AGP), ATI Radeon 9800SE AH (AGP),
ATI Radeon 9800 AI (AGP), ATI Radeon 9800 AJ (AGP),
ATI FireGL X2 AK (AGP), ATI Radeon 9800PRO NH (AGP),
ATI Radeon 9800 NI (AGP), ATI FireGL X2 NK (AGP),
ATI Radeon 9800XT NJ (AGP)
(II) Primary Device is: PCI 01:00:0
(II) ATI:  Candidate "Device" section "Generic Video Card".
(WW) R128: No matching Device section for instance (BusID PCI:1:0:0) found
(EE) No devices detected.

Fatal server error:
no screens found

When reporting a problem related to a server crash, please send
the full server output, not just the last messages.
This can be found in the log file "/var/log/XFree86.0.log".
Please report problems to [EMAIL PROTECTED]


-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.4.27-2-386
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

--
John Reiser, [EMAIL PROTECTED]



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]