Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

2016-02-25 Thread John Paul Adrian Glaubitz
On 11/12/2015 11:35 PM, John Paul Adrian Glaubitz wrote:
> On 11/12/2015 11:28 PM, Patrick Baggett wrote:
>> If the output is -1, the bug has been fixed. If the output is 0, then
>> the bug is still present. 0 indicates the two strings are equal. Clearly
>> they are not. :)
> 
> Looks like it has been fixed. Anything non-zero means strcmp says the
> strings are not equal, so not just -1:

This is no longer reproducible and debian-installer builds fine on
sparc64. I have created multiple working NETINST images for sparc64.

Thus, closing.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

2015-11-12 Thread Patrick Baggett
On Thu, Nov 12, 2015 at 4:35 PM, John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:

> On 11/12/2015 11:28 PM, Patrick Baggett wrote:
> > If the output is -1, the bug has been fixed. If the output is 0, then
> > the bug is still present. 0 indicates the two strings are equal. Clearly
> > they are not. :)
>
> Looks like it has been fixed. Anything non-zero means strcmp says the
> strings are not equal, so not just -1:
>
> Right, sorry: the return value should be a[0]-b[0], which is (1 - 0) = 1,
not -1. Anyways, yeah, bug fixed. :)



> (unstable-sparc64-sbuild)root@andi:/tmp# gcc -O0 test.c -o test64
> (unstable-sparc64-sbuild)root@andi:/tmp# ./test64
> 1
> (unstable-sparc64-sbuild)root@andi:/tmp# cat test.c
> /* test.c */
> #include 
> #include 
>
> int main() {
>   char a[2] = { 1, 0 };
>   char b[2] = { 0, 0 };
>   printf("%d\n", strcmp(a,b));
> }
> (unstable-sparc64-sbuild)root@andi:/tmp#
>
> This has been tested with gcc_5.2.1-23 and glibc_2.19-22 on sparc64.
>
> Cheers,
> Adrian
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>


Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

2015-11-12 Thread John Paul Adrian Glaubitz
On 11/12/2015 11:28 PM, Patrick Baggett wrote:
> If the output is -1, the bug has been fixed. If the output is 0, then
> the bug is still present. 0 indicates the two strings are equal. Clearly
> they are not. :)

Looks like it has been fixed. Anything non-zero means strcmp says the
strings are not equal, so not just -1:

(unstable-sparc64-sbuild)root@andi:/tmp# gcc -O0 test.c -o test64
(unstable-sparc64-sbuild)root@andi:/tmp# ./test64
1
(unstable-sparc64-sbuild)root@andi:/tmp# cat test.c
/* test.c */
#include 
#include 

int main() {
  char a[2] = { 1, 0 };
  char b[2] = { 0, 0 };
  printf("%d\n", strcmp(a,b));
}
(unstable-sparc64-sbuild)root@andi:/tmp#

This has been tested with gcc_5.2.1-23 and glibc_2.19-22 on sparc64.

Cheers,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

2015-11-12 Thread Patrick Baggett
On Thu, Nov 12, 2015 at 4:20 PM, John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:

> > https://wiki.debian.org/PortsSparc
> >
> > Started a catagory of major bugs. Please place links and titles to
> > the bug report in this list so we can better track the status and
> > reference the problems quickly.
>
> The underlying upstream issue of this bug in glibc seems to have been
> fixed [1], so I assume we could actually close this bug. If someone
> has an idea how to quickly verify the fix, please let me know.
>
>
Hi Adrian,

I submitted the bug report. Reproducing (or testing it) is trivial and is
described in the report I made. Below is code that you can copy into a *.c
file, compile with gcc and run it.

---
/* test.c */
#include 
#include 

int main() {
char a[2] = { 1, 0 };
char b[2] = { 0, 0 };
printf("%d\n", strcmp(a,b));
}
---
compile as: gcc -O0 test.c

If the output is -1, the bug has been fixed. If the output is 0, then the
bug is still present. 0 indicates the two strings are equal. Clearly they
are not. :)

Patrick

> One of my major problems with helping debian and the sparc port has
> > been simply figuring out what is wrong. I have fixed a lot of
> > problems upstream with KDE and alignment issues, and even have the
> > nouveau driver working with some GeForces on sparc. It would be sad
> > to see my plucky little sparc machines no longer get updates.
>
> You might be happy to hear that we have started bringing sparc64
> back to life in debian-ports and we're making very good progress
> with almost 9000 packages being up-to-date.
>
> Currently, there are no installer images available though. Thus,
> you have to use debootstrap to install a base sparc64 system which
> you can boot later.
>
> Cheers,
> Adrian
>
> > [1] https://sourceware.org/bugzilla/show_bug.cgi?id=16885
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>


Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

2015-11-12 Thread John Paul Adrian Glaubitz
> https://wiki.debian.org/PortsSparc
>
> Started a catagory of major bugs. Please place links and titles to
> the bug report in this list so we can better track the status and
> reference the problems quickly.

The underlying upstream issue of this bug in glibc seems to have been
fixed [1], so I assume we could actually close this bug. If someone
has an idea how to quickly verify the fix, please let me know.

> One of my major problems with helping debian and the sparc port has
> been simply figuring out what is wrong. I have fixed a lot of
> problems upstream with KDE and alignment issues, and even have the
> nouveau driver working with some GeForces on sparc. It would be sad
> to see my plucky little sparc machines no longer get updates.

You might be happy to hear that we have started bringing sparc64
back to life in debian-ports and we're making very good progress
with almost 9000 packages being up-to-date.

Currently, there are no installer images available though. Thus,
you have to use debootstrap to install a base sparc64 system which
you can boot later.

Cheers,
Adrian

> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=16885

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

2014-04-30 Thread Lennart Sorensen
On Wed, Apr 30, 2014 at 11:21:14AM -0400, Lennart Sorensen wrote:
> On Wed, Apr 30, 2014 at 07:53:30AM -0400, Lennart Sorensen wrote:
> > On Tue, Apr 29, 2014 at 04:47:26PM -0400, Lennart Sorensen wrote:
> > > It looks to me as if the problem might be here:
> > > 
> > > sub rWORD1, r0101, rTMP2
> > 
> > No that's not it.  Still haven't figured it out.
> 
> Does this actually fail with input like this:
> 
> strcmp("", "bb")
> 
> As far as i can tell that would return 0.
> 
> I am seeing this (with my C version of the assembly code since I have
> no sparc to run it on):
> 
> rWORD1:  rWORD2: 6100
> aligned_loop_entry
> aligned_loop
> rTMP2: 00fefefefefefeff rSTRXOR: 6100 rTMP1: 8080808080808080
> common_endstring
> rTMP2:  o1: 8080808080808081
> rTMP2: 7f7f7f7f7f7f7f7f
> rTMP1: 8080808080808080
> rTMP1: ff01010101010101
> Result: strcmptest("", "a") = 0
> 
> rWORD1: 6100 rWORD2: 
> aligned_loop_entry
> aligned_loop
> rTMP2: 61fefefefefefeff rSTRXOR: 6100 rTMP1: 8080808080808080
> common_endstring
> rTMP2: 6100 o1: 8080808080808081
> rTMP2: e07f7f7f7f7f7f7f
> rTMP1: 0080808080808080
> rTMP1: 0001010101010101
> Result: strcmptest("a", "") = 1
> 
> Clearly ending up with ff in the mask that was supposed to contain 00
> and 01 only is a problem.

OK, and I screwed up again.  Must make sure to use unsigned long when
doing bit shift operations.

-- 
Len Sorensen


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140430154203.gb17...@csclub.uwaterloo.ca



Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

2014-04-30 Thread Lennart Sorensen
On Wed, Apr 30, 2014 at 07:53:30AM -0400, Lennart Sorensen wrote:
> On Tue, Apr 29, 2014 at 04:47:26PM -0400, Lennart Sorensen wrote:
> > It looks to me as if the problem might be here:
> > 
> > sub rWORD1, r0101, rTMP2
> 
> No that's not it.  Still haven't figured it out.

Does this actually fail with input like this:

strcmp("", "bb")

As far as i can tell that would return 0.

I am seeing this (with my C version of the assembly code since I have
no sparc to run it on):

rWORD1:  rWORD2: 6100
aligned_loop_entry
aligned_loop
rTMP2: 00fefefefefefeff rSTRXOR: 6100 rTMP1: 8080808080808080
common_endstring
rTMP2:  o1: 8080808080808081
rTMP2: 7f7f7f7f7f7f7f7f
rTMP1: 8080808080808080
rTMP1: ff01010101010101
Result: strcmptest("", "a") = 0

rWORD1: 6100 rWORD2: 
aligned_loop_entry
aligned_loop
rTMP2: 61fefefefefefeff rSTRXOR: 6100 rTMP1: 8080808080808080
common_endstring
rTMP2: 6100 o1: 8080808080808081
rTMP2: e07f7f7f7f7f7f7f
rTMP1: 0080808080808080
rTMP1: 0001010101010101
Result: strcmptest("a", "") = 1

Clearly ending up with ff in the mask that was supposed to contain 00
and 01 only is a problem.

-- 
Len Sorensen


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140430152114.ga17...@csclub.uwaterloo.ca



Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

2014-04-30 Thread Lennart Sorensen
On Tue, Apr 29, 2014 at 04:47:26PM -0400, Lennart Sorensen wrote:
> It looks to me as if the problem might be here:
> 
> sub rWORD1, r0101, rTMP2

No that's not it.  Still haven't figured it out.

-- 
Len Sorensen


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140430115330.gy17...@csclub.uwaterloo.ca



Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

2014-04-30 Thread Ian Campbell
On Tue, 2014-04-29 at 19:34 -0400, Kieron Gillespie wrote:
> https://wiki.debian.org/PortsSparc
> 
> 
> Started a catagory of major bugs. Please place links and titles to the
> bug report in this list so we can better track the status and
> reference the problems quickly.

You might find the BTS's usertags feature (with user
==debian-sparc@lists.debian.org) useful for this. See for example how
arm64 is using it: https://wiki.debian.org/Arm64Port#Bug_tracking

Ian.



-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1398842855.23380.102.ca...@dagon.hellion.org.uk



Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

2014-04-29 Thread Kieron Gillespie
https://wiki.debian.org/PortsSparc

Started a catagory of major bugs. Please place links and titles to the bug
report in this list so we can better track the status and reference the
problems quickly.

One of my major problems with helping debian and the sparc port has been
simply figuring out what is wrong. I have fixed a lot of problems upstream
with KDE and alignment issues, and even have the  nouveau driver working
with some GeForces on sparc. It would be sad to see my plucky little sparc
machines no longer get updates.

-Kieron


On Tue, Apr 29, 2014 at 6:45 PM, Sébastien Bernard wrote:

> Le 30/04/2014 00:12, Kieron Gillespie a écrit :
>
>  Do we currently have  a master list of all the major bugs facing the
>> Sparc Port right now?
>>
>>  I don't think so. I haven't been able to get one.
>
> You can start one.
>
> Seb
>


Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

2014-04-29 Thread Sébastien Bernard

Le 30/04/2014 00:12, Kieron Gillespie a écrit :
Do we currently have  a master list of all the major bugs facing the 
Sparc Port right now?



I don't think so. I haven't been able to get one.

You can start one.

Seb


--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53602b92.9020...@nerim.net



Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

2014-04-29 Thread Kieron Gillespie
Do we currently have  a master list of all the major bugs facing the Sparc
Port right now?


On Tue, Apr 29, 2014 at 3:53 PM, Patrick Baggett
wrote:

>
>
>
> On Tue, Apr 29, 2014 at 2:35 PM, Patrick Baggett <
> baggett.patr...@gmail.com> wrote:
>
>> Yes, that's the one. Interestingly, in glibc-2.19, this change is
>> reverted. It is present in glibc-2.17 & glibc-2.18 as released by GNU.
>> Oddly, in glibc git, the buggy version appears.
>>
>>
>>
> I've filed a bug with glibc [1] and let the author know that there is a
> problem. In the meantime, I'll try to figure out what the problem is. I
> think we may need to file a debian bug though since it will require a glibc
> update. Sebastien, can you handle that?
>
> Patrick
>
> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=16885
>


Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

2014-04-29 Thread Lennart Sorensen
On Tue, Apr 29, 2014 at 02:53:32PM -0500, Patrick Baggett wrote:
> On Tue, Apr 29, 2014 at 2:35 PM, Patrick Baggett
> wrote:
> 
> > Yes, that's the one. Interestingly, in glibc-2.19, this change is
> > reverted. It is present in glibc-2.17 & glibc-2.18 as released by GNU.
> > Oddly, in glibc git, the buggy version appears.
> >
> >
> >
> I've filed a bug with glibc [1] and let the author know that there is a
> problem. In the meantime, I'll try to figure out what the problem is. I
> think we may need to file a debian bug though since it will require a glibc
> update. Sebastien, can you handle that?

It looks to me as if the problem might be here:

sub rWORD1, r0101, rTMP2

If rWORD1 is 0x0100    (in case of strcmp('\0001', '\'), then 
you
get something like:

0x0100    - 0x0101 0101 0101 0101 which goes negative.  If the
first byte is 0x02 or higher, that doesn't happen, so for typical strings
it is not a problem.  And once it goes negative, I think the pattern
the algorithm expected to use is completely gone.  It can't find the
NULL bytes anymore.  At least that's how it appears to me.  I didn't
quite finish making sense of it.

-- 
Len Sorensen


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140429204726.gx17...@csclub.uwaterloo.ca



Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

2014-04-29 Thread Patrick Baggett
On Tue, Apr 29, 2014 at 2:35 PM, Patrick Baggett
wrote:

> Yes, that's the one. Interestingly, in glibc-2.19, this change is
> reverted. It is present in glibc-2.17 & glibc-2.18 as released by GNU.
> Oddly, in glibc git, the buggy version appears.
>
>
>
I've filed a bug with glibc [1] and let the author know that there is a
problem. In the meantime, I'll try to figure out what the problem is. I
think we may need to file a debian bug though since it will require a glibc
update. Sebastien, can you handle that?

Patrick

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=16885


Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

2014-04-29 Thread Patrick Baggett
Yes, that's the one. Interestingly, in glibc-2.19, this change is reverted.
It is present in glibc-2.17 & glibc-2.18 as released by GNU. Oddly, in
glibc git, the buggy version appears.


On Tue, Apr 29, 2014 at 2:25 PM, Lennart Sorensen <
lsore...@csclub.uwaterloo.ca> wrote:

> On Tue, Apr 29, 2014 at 06:01:00PM +0200, Sébastien Bernard wrote:
> > Le 29/04/2014 16:50, Kieron Gillespie a écrit :
> > >I'll rebuild one of my SunBlade 2500 latter with sid and see if I
> > >get the same result. If it doesn't show the symptom I will rebuild
> > >my T2000 and see if it is something specific to the Niagara T1.
> > >
> > >-Kieron
> > >
> > >
> > >On Tue, Apr 29, 2014 at 10:45 AM, Sébastien Bernard
> > >mailto:sbern...@nerim.net>> wrote:
> > >
> > >Le 29/04/2014 16:34, Kieron Gillespie a écrit :
> > >
> > >I am currently investigating this unusual behavior with
> > >strcmp, and I am unable to reproduce the problem using the
> > >test_strcmp example provided.
> > >
> > >It returns the correct output of,
> > >
> > >result from strcmp('\','\0001' is -1)
> > >
> > >This was built on Debian Wheezy with a T2000 SPARC processor
> > >using GCC 4.6.3-14 from Debian Wheezy Repo.
> > >
> > >Cheers,
> > >Kieron
> > >
> > >Hum, I tried with a T5220 with debian 7.5 /wheezy.
> > >Same result, the strcmp is ok.
> > >Could you try with unstable ?
> > >
> > >Cheers.
> > >
> > >
> > Tested on niagara T5220:
> >  with wheezy 2.13 glibc:
> > root@skynet:~# ./test_strcmp
> > result from strcmp('\','\0001' is -1)
> > result from memcmp('\','\0001' is -1)
> >
> > Tested from debootstrap sid on the same niagara :
> > root@skynet:/# ./test_strcmp
> > result from strcmp('\','\0001' is 0)
> > result from memcmp('\','\0001' is -1)
> >
> >
> > So, glibc-2.18 is broken on sparc.
>
> So does that mean this commit broke it:
>
> commit ad69cc2652c0422ebac3296d914c25e470498ce1
> Author: David S. Miller 
> Date:   Wed Aug 24 01:32:24 2011 -0700
>
> Rewritten v9/64-bit sparc strcmp.
>
> diff --git a/ChangeLog b/ChangeLog
> index 4fde8c2..ab754e5 100644
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,3 +1,7 @@
> +2011-08-24  David S. Miller  
> +
> +   * sysdeps/sparc/sparc64/strcmp.S: Rewrite.
> +
>  2011-08-24  Andreas Schwab  
>
> * elf/Makefile: Add rules to build and run unload8 test.
> ...etc...
>
> --
> Len Sorensen
>


Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

2014-04-29 Thread Lennart Sorensen
On Tue, Apr 29, 2014 at 06:01:00PM +0200, Sébastien Bernard wrote:
> Le 29/04/2014 16:50, Kieron Gillespie a écrit :
> >I'll rebuild one of my SunBlade 2500 latter with sid and see if I
> >get the same result. If it doesn't show the symptom I will rebuild
> >my T2000 and see if it is something specific to the Niagara T1.
> >
> >-Kieron
> >
> >
> >On Tue, Apr 29, 2014 at 10:45 AM, Sébastien Bernard
> >mailto:sbern...@nerim.net>> wrote:
> >
> >Le 29/04/2014 16:34, Kieron Gillespie a écrit :
> >
> >I am currently investigating this unusual behavior with
> >strcmp, and I am unable to reproduce the problem using the
> >test_strcmp example provided.
> >
> >It returns the correct output of,
> >
> >result from strcmp('\','\0001' is -1)
> >
> >This was built on Debian Wheezy with a T2000 SPARC processor
> >using GCC 4.6.3-14 from Debian Wheezy Repo.
> >
> >Cheers,
> >Kieron
> >
> >Hum, I tried with a T5220 with debian 7.5 /wheezy.
> >Same result, the strcmp is ok.
> >Could you try with unstable ?
> >
> >Cheers.
> >
> >
> Tested on niagara T5220:
>  with wheezy 2.13 glibc:
> root@skynet:~# ./test_strcmp
> result from strcmp('\','\0001' is -1)
> result from memcmp('\','\0001' is -1)
> 
> Tested from debootstrap sid on the same niagara :
> root@skynet:/# ./test_strcmp
> result from strcmp('\','\0001' is 0)
> result from memcmp('\','\0001' is -1)
> 
> 
> So, glibc-2.18 is broken on sparc.

So does that mean this commit broke it:

commit ad69cc2652c0422ebac3296d914c25e470498ce1
Author: David S. Miller 
Date:   Wed Aug 24 01:32:24 2011 -0700

Rewritten v9/64-bit sparc strcmp.

diff --git a/ChangeLog b/ChangeLog
index 4fde8c2..ab754e5 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2011-08-24  David S. Miller  
+
+   * sysdeps/sparc/sparc64/strcmp.S: Rewrite.
+
 2011-08-24  Andreas Schwab  
 
* elf/Makefile: Add rules to build and run unload8 test.
...etc...

-- 
Len Sorensen


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140429192516.gw17...@csclub.uwaterloo.ca



Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

2014-04-29 Thread Sébastien Bernard

Le 29/04/2014 16:50, Kieron Gillespie a écrit :
I'll rebuild one of my SunBlade 2500 latter with sid and see if I get 
the same result. If it doesn't show the symptom I will rebuild my 
T2000 and see if it is something specific to the Niagara T1.


-Kieron


On Tue, Apr 29, 2014 at 10:45 AM, Sébastien Bernard 
mailto:sbern...@nerim.net>> wrote:


Le 29/04/2014 16:34, Kieron Gillespie a écrit :

I am currently investigating this unusual behavior with
strcmp, and I am unable to reproduce the problem using the
test_strcmp example provided.

It returns the correct output of,

result from strcmp('\','\0001' is -1)

This was built on Debian Wheezy with a T2000 SPARC processor
using GCC 4.6.3-14 from Debian Wheezy Repo.

Cheers,
Kieron

Hum, I tried with a T5220 with debian 7.5 /wheezy.
Same result, the strcmp is ok.
Could you try with unstable ?

Cheers.



Tested on niagara T5220:
 with wheezy 2.13 glibc:
root@skynet:~# ./test_strcmp
result from strcmp('\','\0001' is -1)
result from memcmp('\','\0001' is -1)

Tested from debootstrap sid on the same niagara :
root@skynet:/# ./test_strcmp
result from strcmp('\','\0001' is 0)
result from memcmp('\','\0001' is -1)


So, glibc-2.18 is broken on sparc.

Seb



Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

2014-04-29 Thread Patrick Baggett
On Tue, Apr 29, 2014 at 10:01 AM, Kieron Gillespie <
ciaran.gilles...@gmail.com> wrote:

>
> On Tue, Apr 29, 2014 at 10:47 AM, Patrick Baggett <
> baggett.patr...@gmail.com> wrote:
>
>>
>>
>> On Tue, Apr 29, 2014 at 9:34 AM, Kieron Gillespie <
>> ciaran.gilles...@gmail.com> wrote:
>>
>>> I am currently investigating this unusual behavior with strcmp, and I am
>>> unable to reproduce the problem using the test_strcmp example provided.
>>>
>>> It returns the correct output of,
>>>
>>>
>>> result from strcmp('\','\0001' is -1)
>>>
>>> This was built on Debian Wheezy with a T2000 SPARC processor using GCC
>>> 4.6.3-14 from Debian Wheezy Repo.
>>>
>>>
>> Can you set a breakpoint in strcmp and tell me what the file path is?
>> Perhaps there is a sun4v specific function (optimized version) that does
>> not have a bug?
>>
>> Patrick
>>
>>
>
> Here is the information from strcmp breakpoint
>
> ---CUT---
> Breakpoint 1, 0xf7ebd300 in strcmp () from /lib/sparc-linux-gnu/libc.so.6
> (gdb) disas strcmp
> Dump of assembler code for function strcmp:
> => 0xf7ebd300 <+0>: sethi  %hi(0x101), %g1
>0xf7ebd304 <+4>: btst  7, %o0
>0xf7ebd308 <+8>: bne,pn   %icc, 0xf7ebd4a0 
>0xf7ebd30c <+12>:or  %g1, 0x101, %g1
>0xf7ebd310 <+16>:andcc  %o1, 7, %g3
>0xf7ebd314 <+20>:bne,pn   %icc, 0xf7ebd4e4 
>0xf7ebd318 <+24>:sllx  %g1, 0x20, %g2
>0xf7ebd31c <+28>:ldx  [ %o0 ], %o2
> ---CUT---
>
> They aren't the same implementation. Look:

or  rSTR2, rSTR1, rTMP1
sethi   %hi(0x80808080), r8080
andcc   rTMP1, 0x7, %g0
bne,pn  %icc, .Lmaybe_barrel_shift
 or r8080, %lo(0x80808080), r8080
ldx [rSTR1], rWORD1
sub rSTR2, rSTR1, rSTR2
sllxr8080, 32, rTMP1
ldx [rSTR1 + rSTR2], rWORD2
or  r8080, rTMP1, r8080


Side by side, the instructions aren't even the same:

Failing   | Working
--+
or| sethi 0x1010
sethi 8080| btst
btst* | bne
bne   | or 0x101
or 808| andcc ... %g3
ldx   | bne
sub   | sllx
sllx  | ldx
 ...

*btst  rA, rB -> andcc rA, rB, %g0



As far as I can tell from stepping through this it seems like a correctly
> implementation of strcmp.
>
> ---CUT---
> (gdb) info reg
> g0 0x0  0
> g1 0x20754  132948
> g2 0x33dfaf454393588
> g3 0x3dfaf4 4061940
> g4 0xf869cbac   -127284308
> g5 0x28 40
> g6 0xfeff   65279
> g7 0xf7ff66d0   -134256944
> o0 0xdc48   -9144
> o1 0xdc50   -9136
> o2 0xdd34   -8908
> ---CUT---
>
> You can see that o0 and o1 are holding the pointers for the strings
> correctly and examining the value of memory at those location appears to be
> correct.
>
> With -O3 the call is the same. So I am not sure what is going on, would
> like to see an "info reg" at the breakpoint of strcmp on the affected
> systems. Also an examiniation of the memory that o0 and o1 are pointing too.
>
> -Kieron
>
>


Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

2014-04-29 Thread Sébastien Bernard

Le 29/04/2014 16:34, Kieron Gillespie a écrit :
I am currently investigating this unusual behavior with strcmp, and I 
am unable to reproduce the problem using the test_strcmp example provided.


It returns the correct output of,

result from strcmp('\','\0001' is -1)

This was built on Debian Wheezy with a T2000 SPARC processor using GCC 
4.6.3-14 from Debian Wheezy Repo.


Cheers,
Kieron


Hum, I tried with a T5220 with debian 7.5 /wheezy.
Same result, the strcmp is ok.
Could you try with unstable ?

Cheers.


--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/535fbb26.6030...@nerim.net



Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

2014-04-29 Thread Kieron Gillespie
On Tue, Apr 29, 2014 at 10:47 AM, Patrick Baggett  wrote:

>
>
> On Tue, Apr 29, 2014 at 9:34 AM, Kieron Gillespie <
> ciaran.gilles...@gmail.com> wrote:
>
>> I am currently investigating this unusual behavior with strcmp, and I am
>> unable to reproduce the problem using the test_strcmp example provided.
>>
>> It returns the correct output of,
>>
>>
>> result from strcmp('\','\0001' is -1)
>>
>> This was built on Debian Wheezy with a T2000 SPARC processor using GCC
>> 4.6.3-14 from Debian Wheezy Repo.
>>
>>
> Can you set a breakpoint in strcmp and tell me what the file path is?
> Perhaps there is a sun4v specific function (optimized version) that does
> not have a bug?
>
> Patrick
>
>

Here is the information from strcmp breakpoint

---CUT---
Breakpoint 1, 0xf7ebd300 in strcmp () from /lib/sparc-linux-gnu/libc.so.6
(gdb) disas strcmp
Dump of assembler code for function strcmp:
=> 0xf7ebd300 <+0>: sethi  %hi(0x101), %g1
   0xf7ebd304 <+4>: btst  7, %o0
   0xf7ebd308 <+8>: bne,pn   %icc, 0xf7ebd4a0 
   0xf7ebd30c <+12>:or  %g1, 0x101, %g1
   0xf7ebd310 <+16>:andcc  %o1, 7, %g3
   0xf7ebd314 <+20>:bne,pn   %icc, 0xf7ebd4e4 
   0xf7ebd318 <+24>:sllx  %g1, 0x20, %g2
   0xf7ebd31c <+28>:ldx  [ %o0 ], %o2
---CUT---

As far as I can tell from stepping through this it seems like a correctly
implementation of strcmp.

---CUT---
(gdb) info reg
g0 0x0  0
g1 0x20754  132948
g2 0x33dfaf454393588
g3 0x3dfaf4 4061940
g4 0xf869cbac   -127284308
g5 0x28 40
g6 0xfeff   65279
g7 0xf7ff66d0   -134256944
o0 0xdc48   -9144
o1 0xdc50   -9136
o2 0xdd34   -8908
---CUT---

You can see that o0 and o1 are holding the pointers for the strings
correctly and examining the value of memory at those location appears to be
correct.

With -O3 the call is the same. So I am not sure what is going on, would
like to see an "info reg" at the breakpoint of strcmp on the affected
systems. Also an examiniation of the memory that o0 and o1 are pointing too.

-Kieron


Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

2014-04-29 Thread Kieron Gillespie
I'll rebuild one of my SunBlade 2500 latter with sid and see if I get the
same result. If it doesn't show the symptom I will rebuild my T2000 and see
if it is something specific to the Niagara T1.

-Kieron


On Tue, Apr 29, 2014 at 10:45 AM, Sébastien Bernard wrote:

> Le 29/04/2014 16:34, Kieron Gillespie a écrit :
>
>  I am currently investigating this unusual behavior with strcmp, and I am
>> unable to reproduce the problem using the test_strcmp example provided.
>>
>> It returns the correct output of,
>>
>> result from strcmp('\','\0001' is -1)
>>
>> This was built on Debian Wheezy with a T2000 SPARC processor using GCC
>> 4.6.3-14 from Debian Wheezy Repo.
>>
>> Cheers,
>> Kieron
>>
>>  Hum, I tried with a T5220 with debian 7.5 /wheezy.
> Same result, the strcmp is ok.
> Could you try with unstable ?
>
> Cheers.
>
>


Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

2014-04-29 Thread Patrick Baggett
On Tue, Apr 29, 2014 at 9:34 AM, Kieron Gillespie <
ciaran.gilles...@gmail.com> wrote:

> I am currently investigating this unusual behavior with strcmp, and I am
> unable to reproduce the problem using the test_strcmp example provided.
>
> It returns the correct output of,
>
>
> result from strcmp('\','\0001' is -1)
>
> This was built on Debian Wheezy with a T2000 SPARC processor using GCC
> 4.6.3-14 from Debian Wheezy Repo.
>
>
Can you set a breakpoint in strcmp and tell me what the file path is?
Perhaps there is a sun4v specific function (optimized version) that does
not have a bug?

Patrick


Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

2014-04-29 Thread Kieron Gillespie
I am currently investigating this unusual behavior with strcmp, and I am
unable to reproduce the problem using the test_strcmp example provided.

It returns the correct output of,

result from strcmp('\','\0001' is -1)

This was built on Debian Wheezy with a T2000 SPARC processor using GCC
4.6.3-14 from Debian Wheezy Repo.

Cheers,
Kieron


On Tue, Apr 29, 2014 at 3:06 AM, Thomas Schmitt  wrote:

> Hi,
>
> Sébastien Bernard:
> > Cheers to team work.
>
> Special cheers to Patrick Baggett !
>
> And thanks to all who cared for this problem. I'd need more
> users who don't shrug but complain and tell me that i'm wrong.
>
> The bug fix is now committed as
>   http://libburnia-project.org/changeset/5324
>
> (We still did not find any alignment problem. Does that mean
>  we did not test hard enough ?)
>
>
> > The real function is in sysdeps/sparc/sparc64/strcmp.S .
> > So complicated that I'm not surprised a bug came inside.
>
> I found a medium complicated one in the libc code which
> you provided for me in /home/thomas
>   eglibc-2.18/string/bits/string2.h
> Already too bloated for me to spot any mistake or correctness.
>
>
> Have a nice day :)
>
> Thomas
>
>
> --
> To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive:
> https://lists.debian.org/30925670721203172...@scdbackup.webframe.org
>
>


Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

2014-04-29 Thread Thomas Schmitt
Hi,

Sébastien Bernard:
> Cheers to team work.

Special cheers to Patrick Baggett !

And thanks to all who cared for this problem. I'd need more
users who don't shrug but complain and tell me that i'm wrong.

The bug fix is now committed as
  http://libburnia-project.org/changeset/5324

(We still did not find any alignment problem. Does that mean
 we did not test hard enough ?)


> The real function is in sysdeps/sparc/sparc64/strcmp.S .
> So complicated that I'm not surprised a bug came inside.

I found a medium complicated one in the libc code which
you provided for me in /home/thomas
  eglibc-2.18/string/bits/string2.h
Already too bloated for me to spot any mistake or correctness.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/30925670721203172...@scdbackup.webframe.org



Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

2014-04-28 Thread Sébastien Bernard

Le 28/04/2014 20:21, Patrick Baggett a écrit :

Seb,

Yes, I can reproduce this issue.

{ 1, 0 }
{ 1, 1 }

returns 0, when it should return -1.


Interestingly, if you use:
{ 1, 1, 1, 1, 0 }  //i.e. 5 bytes
{ 1, 1, 1, 1, 1 }  //i.e. 5 bytes

as the strings, it returns -1. So it clearly has a problem if the 
string is exceptionally short. That got me thinking. How short?


{ 1, 1, 1, 0 }  //i.e. 4 bytes, returns -1
{ 1, 1, 1, 1 }

{ 1, 1, 0 }  //i.e. 3 bytes, returns -1
{ 1, 1, 1 }

{ 1, 0 }  //i.e. 2 bytes, return -1
{ 1, 1 }

{ 0 }  //i.e. 1 byte, returns -1 : HOLD ON, WHAT?
{ 1 }


So the 1-bye case succeeded, but why? The only difference between that 
and the failing case was two null bytes which shouldn't even be examined.



{ 0, 0 }  //i.e. original test case. Fails, returns 0
{ 1, 0 }

{ 1, 0, 0 } //fails, returns 0.
{ 1, 1, 0 }

{ 1, 1, 0, 0 } //fails, returns 0.
{ 1, 1, 1, 0 }

{ 1, 1, 1, 0, 0 } //fails, returns 0.
{ 1, 1, 1, 1, 0 }

{ 1, 1, 1, 1, 0, 0 } //fails, returns 0.
{ 1, 1, 1, 1, 1, 0 }


Ok, I think it's time to file a bug to the glibc.

Seb


--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/535ebef8.9010...@nerim.net



Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

2014-04-28 Thread Sébastien Bernard

Le 28/04/2014 22:25, Sébastien Bernard a écrit :

Le 28/04/2014 22:01, Thomas Schmitt a écrit :

Hi,

Sebastien's machine now has a xorriso-1.3.7 (the current development
snapshot) with changed libburn/async.c.

The callers of add_worker() now declare:

 union w_list_data o;

rather than

 struct union_member o;

The type of the fourth parameter of add_worker has been changed
from (void *) to (union w_list_data *).

The formerly SIGBUSsing statement became quite elegant

 a->u = *data;

Given that it is a good bug catcher on Debian sparc, and more concise
than e.g.
 memcpy(&(a->u), data, sizeof(union w_list_data));
i tend to keep it.


To Sebastien:

Please give
/home/thomas/xorriso-1.3.7/xorriso/xorriso
a thorough testing with your debian-cd setup.
("make dist" should even pack it up to a usable tarball)

Whatever the outcome will be with that strange strcmp() bug,
your original alternatives 1 and 2 have small chances to succeed
unless we declare surrender on 3.

1- It has been publicly stated in the past that Debian will not
accept a package with original mkisofs. Stated reason was social
incompatibility with its author.

2- Steve McIntyre prefers xorriso to take over genisoimage tasks
rather than changing genisoimage code.
From his view, xorriso is comfortably self-maintaining. :))
I try to give him few reason to regret this strategy.

3- A xorriso candidate (rather stack sanitized than alignment
corrected) has now been beamed onto your machine.


Have a nice day :)

Thomas



Thomas,

I'm trying to rebuild from sid now, since sparc has been removed from 
jessie.


Cheers

Seb

Two thumbs up thomas :
xorriso -as mkisofs -r -J -o ./tmp/miniiso/mini.iso -G /boot/isofs.b -B 
... ./tmp/miniiso/cd_tree

GNU xorriso 1.3.7 : RockRidge filesystem manipulator, libburnia project.

Drive current: -outdev 'stdio:./tmp/miniiso/mini.iso'
Media current: stdio file, overwriteable
Media status : is blank
Media summary: 0 sessions, 0 data blocks, 0 data, 8791m free
Added to ISO image: directory 
'/'='/home/seb/dev/debian-installer-20140316/build/tmp/miniiso/cd_tree'

xorriso : UPDATE : 7 files added in 1 seconds
xorriso : UPDATE : 7 files added in 1 seconds
xorriso : NOTE : Copying to System Area: 7040 bytes from file 
'/boot/isofs.b'

ISO image produced: 4235 sectors
Written to medium : 4235 sectors at LBA 0
Writing to 'stdio:./tmp/miniiso/mini.iso' completed successfully.

So the package was built ok.

Cheers to team work.

Seb


--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/535ebea3.4030...@nerim.net



Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

2014-04-28 Thread Sébastien Bernard

Le 28/04/2014 22:01, Thomas Schmitt a écrit :

Hi,

Sebastien's machine now has a xorriso-1.3.7 (the current development
snapshot) with changed libburn/async.c.

The callers of add_worker() now declare:

 union w_list_data o;

rather than

 struct union_member o;

The type of the fourth parameter of add_worker has been changed
from (void *) to (union w_list_data *).

The formerly SIGBUSsing statement became quite elegant

 a->u = *data;

Given that it is a good bug catcher on Debian sparc, and more concise
than e.g.
 memcpy(&(a->u), data, sizeof(union w_list_data));
i tend to keep it.


To Sebastien:

Please give
/home/thomas/xorriso-1.3.7/xorriso/xorriso
a thorough testing with your debian-cd setup.
("make dist" should even pack it up to a usable tarball)

Whatever the outcome will be with that strange strcmp() bug,
your original alternatives 1 and 2 have small chances to succeed
unless we declare surrender on 3.

1- It has been publicly stated in the past that Debian will not
accept a package with original mkisofs. Stated reason was social
incompatibility with its author.

2- Steve McIntyre prefers xorriso to take over genisoimage tasks
rather than changing genisoimage code.
From his view, xorriso is comfortably self-maintaining. :))
I try to give him few reason to regret this strategy.

3- A xorriso candidate (rather stack sanitized than alignment
corrected) has now been beamed onto your machine.


Have a nice day :)

Thomas



Thomas,

I'm trying to rebuild from sid now, since sparc has been removed from 
jessie.


Cheers

Seb




--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/535eb924.5070...@nerim.net



Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

2014-04-28 Thread Thomas Schmitt
Hi,

Sebastien's machine now has a xorriso-1.3.7 (the current development
snapshot) with changed libburn/async.c.

The callers of add_worker() now declare:

union w_list_data o;

rather than

struct union_member o;

The type of the fourth parameter of add_worker has been changed
from (void *) to (union w_list_data *).

The formerly SIGBUSsing statement became quite elegant

a->u = *data;

Given that it is a good bug catcher on Debian sparc, and more concise
than e.g.
memcpy(&(a->u), data, sizeof(union w_list_data));
i tend to keep it.


To Sebastien:

Please give
   /home/thomas/xorriso-1.3.7/xorriso/xorriso
a thorough testing with your debian-cd setup.
("make dist" should even pack it up to a usable tarball)

Whatever the outcome will be with that strange strcmp() bug,
your original alternatives 1 and 2 have small chances to succeed
unless we declare surrender on 3.

1- It has been publicly stated in the past that Debian will not
   accept a package with original mkisofs. Stated reason was social
   incompatibility with its author.

2- Steve McIntyre prefers xorriso to take over genisoimage tasks
   rather than changing genisoimage code.
   From his view, xorriso is comfortably self-maintaining. :))
   I try to give him few reason to regret this strategy.

3- A xorriso candidate (rather stack sanitized than alignment
   corrected) has now been beamed onto your machine.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1987567089955...@scdbackup.webframe.org



Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

2014-04-28 Thread Richard Mortimer

Hi,

On 28/04/2014 18:25, Thomas Schmitt wrote:


has a struct on heap (#L102, #L138, #L146):

struct w_list{
...
union w_list_data
{
...
struct write_opts write;
...
} u;
}
...
struct w_list *a;
...
a = calloc(1, sizeof(struct w_list));

The gesture which causes the SIGBUS is (#L149)

a->u = *(union w_list_data *)data;

The issue is that data needs to be suitably aligned on an appropriate 
memory boundary. SPARC requires that int32 accesses are aligned on 4 
byte boundaries and that int64 aligns on 8 byte boundaries.


You have to arrange that data is properly aligned or you will get a 
SIGBUS due to an address misalignment.


malloc and calloc arrange that the alignment is suitable

(the manpage says)

"RETURN VALUE
The malloc() and calloc() functions return a pointer to  the  allocated
memory  that  is  suitably aligned for any kind of variable. "

I'm guessing that your void *data isn't directly allocated by calloc so 
it doesn't necessarily have the correct alignment.




which is not what i personally would use, but should be fully legal
nevertheless.

The SIGBUS vanishes if i compile without gcc -O2, or if i replace
the "a->u =" gesture by

memcpy(&(a->u), data, sizeof(union w_list_data));

which i deem equivalent (and more my personal style).


The memcpy version will work just fine because memcpy takes 
misalignments into account and once the data has been copied into a->u 
the calloc'd version of struct w_list will be properly aligned because 
calloc guarantees that it will be.


memcpy is the correct thing to use in your case.

Regards

Richard


--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/535ea3fc.8010...@oldelvet.org.uk



Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

2014-04-28 Thread Thomas Schmitt
Hi,

> No, it's plain wrong. Unions are fine, if used properly. You aren't
> using them properly.

Duh. You convinced me. The callers do it wrong, indeed.
They would have to use local union variables instead of their actual
structs. The parameter of add_worker() should be a pointer to the
union, not a pointer to void.

Obviously the bug normally stays withing populated stack area.
Three cheers for the picky systems !

I'll stop the attempt to reproduce the problem in a smaller program
and rather fix libburn.
(That will result in some testing plight on the less picky systems.)

Thank you for pointing me to this bug.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/16290670797627595...@scdbackup.webframe.org



Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

2014-04-28 Thread Patrick Baggett
On Mon, Apr 28, 2014 at 1:20 PM, Thomas Schmitt  wrote:

> Hi,
>
> > I really need a disassembly and to be able to probe the runtime
> It's the job of a C union to provide a common hull around objects
> of different size. One may dispute whether using union is a good
> idea (like overloading in the OO paradigm). But unions are part of C
> since K&R and they are supposed to be safe.
>
> http://www.gnu.org/software/gnu-c-manual/gnu-c-manual.html#Size-of-Unions


No, it's plain wrong. Unions are fine, if used properly. You aren't using
them properly. Let me show you how by a more extreme example:

#include 

struct small {
   int a;
};

struct big {
   int b[1024*1024];
};

union both {
   struct small imSmall;
   struct big imBig;
};


void copy(union both* b, void* data) {

*b = *(union both*)data; //copies 4MB of data.
}

void main() {
struct small smallThing;
union both* bothThings = malloc(sizeof(union both));
copy(bothThings, &smallThing); // NOT OK. struct small cannot NOT be
converted to union both.
}

figgles@ghost:~$ ./big
Segmentation fault

The problem is that union can convert to a member (by accessing the field),
but a member CANNOT convert to a union. add_worker() takes a member and
tries to convert it to a union. This is WRONG. Period.


Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

2014-04-28 Thread Patrick Baggett
Seb,

Yes, I can reproduce this issue.

{ 1, 0 }
{ 1, 1 }

returns 0, when it should return -1.


Interestingly, if you use:
{ 1, 1, 1, 1, 0 }  //i.e. 5 bytes
{ 1, 1, 1, 1, 1 }  //i.e. 5 bytes

as the strings, it returns -1. So it clearly has a problem if the string is
exceptionally short. That got me thinking. How short?

{ 1, 1, 1, 0 }  //i.e. 4 bytes, returns -1
{ 1, 1, 1, 1 }

{ 1, 1, 0 }  //i.e. 3 bytes, returns -1
{ 1, 1, 1 }

{ 1, 0 }  //i.e. 2 bytes, return -1
{ 1, 1 }

{ 0 }  //i.e. 1 byte, returns -1 : HOLD ON, WHAT?
{ 1 }


So the 1-bye case succeeded, but why? The only difference between that and
the failing case was two null bytes which shouldn't even be examined.


{ 0, 0 }  //i.e. original test case. Fails, returns 0
{ 1, 0 }

{ 1, 0, 0 } //fails, returns 0.
{ 1, 1, 0 }

{ 1, 1, 0, 0 } //fails, returns 0.
{ 1, 1, 1, 0 }

{ 1, 1, 1, 0, 0 } //fails, returns 0.
{ 1, 1, 1, 1, 0 }

{ 1, 1, 1, 1, 0, 0 } //fails, returns 0.
{ 1, 1, 1, 1, 1, 0 }

... ok ... ?

So apparently, ending with a null character that shouldn't even be examined
messes things up? Let's try something radically different:

{ 1, 1, 1, 1, 0, 0xaa } //returns -1, OK
{ 1, 1, 1, 1, 1, 0 }

{ 1, 1, 1, 1, 0, 0 } //returns -1, OK
{ 1, 1, 1, 1, 1, 0xaa }

{ 1, 1, 1, 1, 0, 0xaa} //returns -1, OK
{ 1, 1, 1, 1, 1, 0xbb }





On Mon, Apr 28, 2014 at 6:35 AM, Sébastien Bernard wrote:

> Le 28/04/2014 13:20, Thomas Schmitt a écrit :
>
>
>>  [genisoimage]
>>> (gdb) x rpnt
>>> 0x1ea7f9:0x
>>> (gdb) x lpnt
>>> 0x1e9dc1:0x0100
>>> (gdb) n
>>> 659if (strcmp(rpnt, lpnt) == 0) {
>>>
>> Both values match the prescribed names for "." and ".." in ECMA-119
>> (aka ISO 9660), 6.8.2.2 Identification of directories:
>> Single byte 0x00 is ".", single byte 0x01 is "..".
>>
> Ok, I got the bug nailed.
> Here's a sample session from my sparc:
> --
> cat  test_strcmp.c< #include 
> #include 
>
> void main(void) {
>   char stra[2];
>   char strb[2];
>   int result = 0;
>
>   stra[0] = 0;
>   stra[1] = 0;
>   strb[0] = 1;
>   strb[1] = 0;
>
>   result = strcmp(stra,strb);
>
>   printf("result from strcmp('\\','\\0001' is %d)\n",result);
>   exit(0);
> }
> EOF
> gcc -o test_strcmp test_strcmp.c
> ./test_strcmp
> result from strcmp('\','\0001' is 0)
> --
>
> Here's the same sample from my intel workstation:
> --
> gcc -o test_strcmp test_strcmp.c
> ./test_strcmp
> result from strcmp('\','\0001' is -1)
> --
>
> Typicaly, an endianness error.
>
> If I apply this patch on cdrkit:
> --- genisoimage/write.c2014-04-28 13:31:28.103571175 +0200
> +++ genisoimage/write.c.new2014-04-28 13:31:07.255433923 +0200
> @@ -656,7 +656,7 @@
>  #endif/* APPLE_HYB */
>
>  /* If the entries are the same, this is an error. */
>
> -if (strcmp(rpnt, lpnt) == 0) {
> +if (strcmp(rpnt, lpnt) == 0 && rpnt[0] == lpnt[0]) {
>  #ifdefUSE_LIBSCHILY
>  errmsgno(EX_BAD,
>  "Error: '%s' and '%s' have the same ISO9660 name '%s'.\n",
>
> Then the iso is correctly generated.
>
> I'll file a bug with cdrkit. I think that genisoimage with that test is
> unable to generated any iso at all on big endian machines.
>
>  So, strcmp shouldn't have yielded 0 when comparing the strings.
>>>
>> Can this be caused by alignment problems ?
>>
> Nope.
>
>
>>
>>  Hum, unfortunately, valgrind is not available for sparc.
>>>
>> Then gdb will have to do.
>>
>>
>>  xorriso is the one compiled from isoburn. I tried with the one from the
>>> archive, and the one rebuild from source with a debbuild.
>>> Same problem on both.
>>>
>> If you also built libisofs and libburn from source, then this burries
>> my theory of a binary incompatibility between two SPARC machines.
>>
>>  I'm compiling at this moment the vanilla xorriso from gnu.
>>> Let's see what it yields.
>>>
>> It has the same source as the three library tarballs used as input
>> for Debian's xorriso. Only difference is that GNU xorriso brings
>> own copies of the library source code and links it statically with
>> the xorriso main program.
>> So it can be easily tested without interfering with installations
>> of the libraries. (And with no need for superuser privileges.)
>>
> I filed a bug with xorriso. Waiting for the number to show up.
>
>
>>
>> Have a nice day :)
>>
>> Thomas
>>
>>
>>  You too ; ).
>
> Seb
>
>
>
> --
> To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: https://lists.debian.org/535e3cf6.3080...@nerim.net
>
>


Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

2014-04-28 Thread Thomas Schmitt
Hi,

> I really need a disassembly and to be able to probe the runtime
> stack a bit, so that really means that I need to build the code. :)

The current example would be a bit too opulent, i guess:

  -rwxr-xr-x 1 thomas thomas 3753398 avril 28 17:49 xorriso/xorriso

(wget http://www.gnu.org/software/xorriso/xorriso-1.3.2.tar.gz
 untar, cd xorriso-1.3.2, ./configure, make, ls -l xorriso/xorriso,
 crash by:
xorriso/xorriso -outdev stdio:/dev/null -map ./xorriso /
)

I'll try to reproduce by a smaller program on Sebastien's
system.


> I think as a more meta-problem is this: the code's logic for "how
> much" to copy is wrong. It copies too many bytes on many cases and
> violates the C contract that you'll only copy like objects using "=".
> [...] you're copying unlike objects of different sizes and
> that's never safe.

It's the job of a C union to provide a common hull around objects
of different size. One may dispute whether using union is a good
idea (like overloading in the OO paradigm). But unions are part of C
since K&R and they are supposed to be safe.
  http://www.gnu.org/software/gnu-c-manual/gnu-c-manual.html#Size-of-Unions

As for the cost: The threads are running big operations of libburn.
Even a full MB of copying would not make much difference.

Elsewise i agree with you. I would have written it differently, too.
But i will try to keep the necessary changes as small as possible.
So the union approach will most probably stay unless i get convinced
that it is faulty C language.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5941670806243473...@scdbackup.webframe.org



Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

2014-04-28 Thread Patrick Baggett
On Mon, Apr 28, 2014 at 12:25 PM, Thomas Schmitt  wrote:

> Hi,
>
> Patrick Baggett:
> > Could you explain the context around this code? Perhaps the source is
> > not really "alignment safe" and could use some patching upstream? I'd
> > be happy to provide advice or code samples.
>
> The context was misposted to bug report 731806 as message #87:
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731806#87
> (but not with Cc to debian-sparc list).
>
> Upstream is myself. :))
> The code in question is by my unreachable libburn predecessors, though.
>
> It belongs to the preparation of a thread start for one of five
> occasions in libburn. SIGBUS happens at
>   http://libburnia-project.org/browser/libburn/trunk/libburn/async.c#L149
>
> The caller has a local struct (i.e. on stack) like (#L592, #L692):
>
>struct write_opts write;
>...
>add_worker(Burnworker_type_writE, d,
>(WorkerFunc) write_disc_worker_func, &o);
>
> The called function gets its address as parameter "data" (#L135):
>
>   static void add_worker(int w_type, struct burn_drive *d,
>  WorkerFunc f, void *data)
>
> has a struct on heap (#L102, #L138, #L146):
>
>struct w_list{
>...
>union w_list_data
>{
>...
>struct write_opts write;
>...
>} u;
>}
>...
>struct w_list *a;
>...
>a = calloc(1, sizeof(struct w_list));
>
> The gesture which causes the SIGBUS is (#L149)
>
>a->u = *(union w_list_data *)data;
>
> which is not what i personally would use, but should be fully legal
> nevertheless.
>
>
I'm not sure what the problem is exactly here. 64-bit SPARC will use ldx to
load 64-bit quantities, which can cause problems if the source data is only
4-byte aligned, but that doesn't seem to be the case here. I really need a
disassembly and to be able to probe the runtime stack a bit, so that really
means that I need to build the code. :)

I think as a more meta-problem is this: the code's logic for "how much" to
copy is wrong. It copies too many bytes on many cases and violates the C
contract that you'll only copy like objects using "=".

Imagine:

sizeof(struct erase_ops) == 8 (32-bit ABI)
sizeof(w_list_data) == at least 12 (32-bit ABI).

Suppose: data = &some_erase_ops

a->u = *(union w_list_data *)data; // copies 12 bytes from 8 byte area, can
cause crashes if the last 4 bytes are into an unmapped page.


The correct way to do this would be to have add_worker() pass a const
w_list_data* with the appropriate field(s) in '.u' filled out. Otherwise,
you're copying unlike objects *of different sizes* and that's never safe.

---

Patrick




> The SIGBUS vanishes if i compile without gcc -O2, or if i replace
> the "a->u =" gesture by
>
>memcpy(&(a->u), data, sizeof(union w_list_data));
>
> which i deem equivalent (and more my personal style).
>
>
> Have a nice day :)
>
> Thomas
>
>


Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

2014-04-28 Thread Thomas Schmitt
Hi,

i wrote:
>   struct write_opts write;
>   ...
>   add_worker(Burnworker_type_writE, d,
>   (WorkerFunc) write_disc_worker_func, &o);

Urgh. I copied the wrong struct definition. Line 592 bears of course:

struct write_opts o;

which is used in the call of add_worker().


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/9919670809032917...@scdbackup.webframe.org



Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

2014-04-28 Thread Thomas Schmitt
Hi,

Patrick Baggett:
> Could you explain the context around this code? Perhaps the source is
> not really "alignment safe" and could use some patching upstream? I'd
> be happy to provide advice or code samples.

The context was misposted to bug report 731806 as message #87:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731806#87
(but not with Cc to debian-sparc list).

Upstream is myself. :))
The code in question is by my unreachable libburn predecessors, though.

It belongs to the preparation of a thread start for one of five
occasions in libburn. SIGBUS happens at
  http://libburnia-project.org/browser/libburn/trunk/libburn/async.c#L149

The caller has a local struct (i.e. on stack) like (#L592, #L692):

   struct write_opts write;
   ...
   add_worker(Burnworker_type_writE, d,
   (WorkerFunc) write_disc_worker_func, &o);

The called function gets its address as parameter "data" (#L135):

  static void add_worker(int w_type, struct burn_drive *d,
 WorkerFunc f, void *data)

has a struct on heap (#L102, #L138, #L146):

   struct w_list{
   ...
   union w_list_data
   {
   ...
   struct write_opts write;
   ...
   } u;
   }
   ...
   struct w_list *a;
   ...
   a = calloc(1, sizeof(struct w_list));

The gesture which causes the SIGBUS is (#L149)

   a->u = *(union w_list_data *)data;

which is not what i personally would use, but should be fully legal
nevertheless.

The SIGBUS vanishes if i compile without gcc -O2, or if i replace
the "a->u =" gesture by

   memcpy(&(a->u), data, sizeof(union w_list_data));

which i deem equivalent (and more my personal style).


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20365670802973806...@scdbackup.webframe.org



Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

2014-04-28 Thread Patrick Baggett
On Mon, Apr 28, 2014 at 11:39 AM, Thomas Schmitt  wrote:

> Hi,
>
> sorry for mis-posting the first reply for bug 746254 to this bug 731806.
>
> Meanwhile it turned out that the SIGBUS vanishes if i do not
> compile with -O2 or if i replace "a->u =" by memcpy().
>
> Could you explain the context around this code? Perhaps the source is not
really "alignment safe" and could use some patching upstream? I'd be happy
to provide advice or code samples.



> So it seems worth to check whether genisoimage resp. strcmp() work
> properly if not compiled with -O2.
>
> 
>
> A test with Sebastiens genisoimage options succeeded without error.
>
>   /home/thomas/xorriso-1.3.7/xorriso/xorriso -as mkisofs \
>   -r -J -o test.iso -G ~/boot/isofs.b -B ... tmp-iso/miniiso/cd_tree
>
> It looks ok, SPARC-boot-wise.
>
>   SUN SPARC disklabel: CD-ROM Disc with Sun sparc boot created by libisofs
>   SUN SPARC secs/head: 640
>   SUN SPARC heads/cyl: 1
>   SUN SPARC partmap  : N   IdTag   PermsStartCyl   NumBlocks
>   SUN SPARC partition: 1  0x0004  0x0010   0   16940
>   SUN SPARC partition: 2  0x0002  0x0010   0   16940
>   ...
>   SUN SPARC partition: 8  0x0002  0x0010   0   16940
>
> An additional option --md5 enabled confirmation that the ISO stream
> of libisofs was written flawlessly by libburn into the file test.iso.
>
>   /home/thomas/xorriso-1.3.7/xorriso/xorriso \
>   -for_backup -indev test.iso -check_media --
>
> xorriso is willing to load the ISO metadata and to compare it with
> the hard disk tree.
>
>   /home/thomas/xorriso-1.3.7/xorriso/xorriso \
>   -indev test.iso -compare_r tmp-iso/miniiso/cd_tree /
>
> It only detects the consequences of option -r with directories
> (see man genisoimage / mkisofs):
> Permissions are set to "r-xr-xr-x", owned by 0, group is 0.
>
> 
>
> Have a nice day :)
>
> Thomas
>
>
> --
> To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive:
> https://lists.debian.org/18128670805771551...@scdbackup.webframe.org
>
>


Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

2014-04-28 Thread Thomas Schmitt
Hi,

sorry for mis-posting the first reply for bug 746254 to this bug 731806.

Meanwhile it turned out that the SIGBUS vanishes if i do not
compile with -O2 or if i replace "a->u =" by memcpy().

So it seems worth to check whether genisoimage resp. strcmp() work
properly if not compiled with -O2.



A test with Sebastiens genisoimage options succeeded without error.

  /home/thomas/xorriso-1.3.7/xorriso/xorriso -as mkisofs \
  -r -J -o test.iso -G ~/boot/isofs.b -B ... tmp-iso/miniiso/cd_tree

It looks ok, SPARC-boot-wise.

  SUN SPARC disklabel: CD-ROM Disc with Sun sparc boot created by libisofs
  SUN SPARC secs/head: 640
  SUN SPARC heads/cyl: 1
  SUN SPARC partmap  : N   IdTag   PermsStartCyl   NumBlocks
  SUN SPARC partition: 1  0x0004  0x0010   0   16940
  SUN SPARC partition: 2  0x0002  0x0010   0   16940
  ...
  SUN SPARC partition: 8  0x0002  0x0010   0   16940

An additional option --md5 enabled confirmation that the ISO stream
of libisofs was written flawlessly by libburn into the file test.iso.

  /home/thomas/xorriso-1.3.7/xorriso/xorriso \
  -for_backup -indev test.iso -check_media --

xorriso is willing to load the ISO metadata and to compare it with
the hard disk tree.

  /home/thomas/xorriso-1.3.7/xorriso/xorriso \
  -indev test.iso -compare_r tmp-iso/miniiso/cd_tree /

It only detects the consequences of option -r with directories
(see man genisoimage / mkisofs):
Permissions are set to "r-xr-xr-x", owned by 0, group is 0.



Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/18128670805771551...@scdbackup.webframe.org



Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

2014-04-28 Thread Patrick Baggett
On Mon, Apr 28, 2014 at 11:25 AM, Sébastien Bernard wrote:

>  Le 28/04/2014 16:05, Patrick Baggett a écrit :
>
>  strcmp() may well be implemented by word comparisons. But then it
>
>>  is the duty of the implementation to properly handle the ends of
>>> the strings even if those are not word aligned.
>>>
>>  Indeed, the correct fix is using strcmp. Meanwhile, the package is
>> broken.
>>
>>
>  Wow, that's pretty bad. How did that slip? Also, are you building 64-bit
> or 32-bit code, and what CPU architecture (perhaps some per-CPU
> implementation is buggy but not others?) This information will help when
> tracking down the issue.
>
>   I think this happens in this particular case comparing \000x and \.
> I had a look at my test_case, the build is 32bit and the called function
> is dynamic in the glibc.
> I tried a 64bit build, it's the same problem.
> I tried various optimization flags and using __builtin_strcmp withtout any
> change.
>
> Could you check this little program test against one of your machine ?
> Just to be sure ?
>
> Yeah sure, no problem -- I'll check it out soon. I'm somewhat comfortable
with SPARC assembly, so I'll see if I can dig a little deeper into why it
is failing.


Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

2014-04-28 Thread Patrick Baggett
On Mon, Apr 28, 2014 at 8:17 AM, Sébastien Bernard wrote:

> Le 28/04/2014 14:15, Thomas Schmitt a écrit :
>
>  Hi,
>>
>> Sébastien Bernard:
>>
>>> result from strcmp('\','\0001' is 0)
>>> result from strcmp('\','\0001' is -1)
>>> Typicaly, an endianness error.
>>>
>> But one in strcmp(), not in your code or the one of genisoimage.
>> You compare an empty string with a string that contains one
>> character 0x01.
>> This is under no endianness allowed to strcmp() == 0.
>>
> Ok, you are correct.
> strcmp yields a bad result. I wasn't sure strcmp was doing byte
> comparaison.
> However, memcmp function is ok.
>
>
>
>  -if (strcmp(rpnt, lpnt) == 0) {
>>> +if (strcmp(rpnt, lpnt) == 0 && rpnt[0] == lpnt[0]) {
>>>
>> Are you sure that it does not miscompare other strings too ?
>>
> Basically, the fix is just to check, in case of strcmp() == 0 that the
> first byte of each string is the same.
> It's should be redundant operation if strcmp == 0 but not in the case of
> strcmp is misbehaving.
> It's just a workaround. The correct fix is, of course, to fix the strcmp.
> Another workaround would be to use :
>
>
> -if (strcmp(rpnt, lpnt) == 0) {
> +if (memcmp(rpnt, lpnt,MAX_ISONAME+1) == 0) {
>
>
>
>
>>
>>  I think that genisoimage with that test is
>>> unable to generated any iso at all on big endian machines.
>>>
>> I cannot agree with this diagnosis.
>> Not having a big-endian machine at hand now, i can confirm from
>> my old SunOS-4-on-SPARC days that strcmp() is supposed to yield
>> a non-zero result with your example char arrays.
>>
>> strcmp() may well be implemented by word comparisons. But then it
>> is the duty of the implementation to properly handle the ends of
>> the strings even if those are not word aligned.
>>
> Indeed, the correct fix is using strcmp. Meanwhile, the package is broken.
>
>
Wow, that's pretty bad. How did that slip? Also, are you building 64-bit or
32-bit code, and what CPU architecture (perhaps some per-CPU implementation
is buggy but not others?) This information will help when tracking down the
issue.


>
>
>>
>>  I filed a bug with xorriso. Waiting for the number to show up.
>>>
>> I will hopefully get a notification via the pkg-libburnia-devel
>> list. Else i will bother you.
>>
>
> Hum, still no answer. I'm going to fill it again.
>
>
>
>>
>> Steve McIntyre:
>>
>>> We build all the release images on an amd64 machine, pettersson.d.o
>>>
>> Ok. That explains why there are sparc-bootable ISOs from xorriso.
>>
> I didn't imagine it could be doable.
>
>
>>
>>
>> Have a nice day :)
>>
>> Thomas
>>
>>
>>  Thanks for your time and dedication.
>
> Seb
>
>
>
> --
> To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: https://lists.debian.org/535e54ee.6050...@nerim.net
>
>


Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

2014-04-28 Thread Sébastien Bernard

Le 28/04/2014 14:15, Thomas Schmitt a écrit :

Hi,

Sébastien Bernard:

result from strcmp('\','\0001' is 0)
result from strcmp('\','\0001' is -1)
Typicaly, an endianness error.

But one in strcmp(), not in your code or the one of genisoimage.
You compare an empty string with a string that contains one
character 0x01.
This is under no endianness allowed to strcmp() == 0.

Ok, you are correct.
strcmp yields a bad result. I wasn't sure strcmp was doing byte comparaison.
However, memcmp function is ok.



-if (strcmp(rpnt, lpnt) == 0) {
+if (strcmp(rpnt, lpnt) == 0 && rpnt[0] == lpnt[0]) {

Are you sure that it does not miscompare other strings too ?
Basically, the fix is just to check, in case of strcmp() == 0 that the 
first byte of each string is the same.
It's should be redundant operation if strcmp == 0 but not in the case of 
strcmp is misbehaving.

It's just a workaround. The correct fix is, of course, to fix the strcmp.
Another workaround would be to use :

-if (strcmp(rpnt, lpnt) == 0) {
+if (memcmp(rpnt, lpnt,MAX_ISONAME+1) == 0) {






I think that genisoimage with that test is
unable to generated any iso at all on big endian machines.

I cannot agree with this diagnosis.
Not having a big-endian machine at hand now, i can confirm from
my old SunOS-4-on-SPARC days that strcmp() is supposed to yield
a non-zero result with your example char arrays.

strcmp() may well be implemented by word comparisons. But then it
is the duty of the implementation to properly handle the ends of
the strings even if those are not word aligned.

Indeed, the correct fix is using strcmp. Meanwhile, the package is broken.





I filed a bug with xorriso. Waiting for the number to show up.

I will hopefully get a notification via the pkg-libburnia-devel
list. Else i will bother you.


Hum, still no answer. I'm going to fill it again.




Steve McIntyre:

We build all the release images on an amd64 machine, pettersson.d.o

Ok. That explains why there are sparc-bootable ISOs from xorriso.

I didn't imagine it could be doable.




Have a nice day :)

Thomas



Thanks for your time and dedication.

Seb


--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/535e54ee.6050...@nerim.net



Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

2014-04-28 Thread Thomas Schmitt
Hi,

Sébastien Bernard:
> result from strcmp('\','\0001' is 0)
> result from strcmp('\','\0001' is -1)
> Typicaly, an endianness error.

But one in strcmp(), not in your code or the one of genisoimage.
You compare an empty string with a string that contains one
character 0x01.
This is under no endianness allowed to strcmp() == 0.

Endianness would only be of interest if you compare characters
of more than one byte each. (I.e. sizeof(char) == 2)
But that would be quite an odd environment for a C program.
char is neither guaranteed to be signed nor to be 8 bit.
Nevertheless programs would break in large numbers if that
assumption was not fulfilled.


> -if (strcmp(rpnt, lpnt) == 0) {
> +if (strcmp(rpnt, lpnt) == 0 && rpnt[0] == lpnt[0]) {

Are you sure that it does not miscompare other strings too ?


> I think that genisoimage with that test is
> unable to generated any iso at all on big endian machines.

I cannot agree with this diagnosis.
Not having a big-endian machine at hand now, i can confirm from
my old SunOS-4-on-SPARC days that strcmp() is supposed to yield
a non-zero result with your example char arrays.

strcmp() may well be implemented by word comparisons. But then it
is the duty of the implementation to properly handle the ends of
the strings even if those are not word aligned.


> I filed a bug with xorriso. Waiting for the number to show up.

I will hopefully get a notification via the pkg-libburnia-devel
list. Else i will bother you.


Steve McIntyre:
> We build all the release images on an amd64 machine, pettersson.d.o

Ok. That explains why there are sparc-bootable ISOs from xorriso.



Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/21777670788974871...@scdbackup.webframe.org



Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

2014-04-28 Thread Sébastien Bernard

Le 28/04/2014 13:20, Thomas Schmitt a écrit :



[genisoimage]
(gdb) x rpnt
0x1ea7f9:0x
(gdb) x lpnt
0x1e9dc1:0x0100
(gdb) n
659if (strcmp(rpnt, lpnt) == 0) {

Both values match the prescribed names for "." and ".." in ECMA-119
(aka ISO 9660), 6.8.2.2 Identification of directories:
Single byte 0x00 is ".", single byte 0x01 is "..".

Ok, I got the bug nailed.
Here's a sample session from my sparc:
--
cat  test_strcmp.c<
#include 

void main(void) {
  char stra[2];
  char strb[2];
  int result = 0;

  stra[0] = 0;
  stra[1] = 0;
  strb[0] = 1;
  strb[1] = 0;

  result = strcmp(stra,strb);

  printf("result from strcmp('\\','\\0001' is %d)\n",result);
  exit(0);
}
EOF
gcc -o test_strcmp test_strcmp.c
./test_strcmp
result from strcmp('\','\0001' is 0)
--

Here's the same sample from my intel workstation:
--
gcc -o test_strcmp test_strcmp.c
./test_strcmp
result from strcmp('\','\0001' is -1)
--

Typicaly, an endianness error.

If I apply this patch on cdrkit:
--- genisoimage/write.c2014-04-28 13:31:28.103571175 +0200
+++ genisoimage/write.c.new2014-04-28 13:31:07.255433923 +0200
@@ -656,7 +656,7 @@
 #endif/* APPLE_HYB */

 /* If the entries are the same, this is an error. */
-if (strcmp(rpnt, lpnt) == 0) {
+if (strcmp(rpnt, lpnt) == 0 && rpnt[0] == lpnt[0]) {
 #ifdefUSE_LIBSCHILY
 errmsgno(EX_BAD,
 "Error: '%s' and '%s' have the same ISO9660 name '%s'.\n",

Then the iso is correctly generated.

I'll file a bug with cdrkit. I think that genisoimage with that test is 
unable to generated any iso at all on big endian machines.

So, strcmp shouldn't have yielded 0 when comparing the strings.

Can this be caused by alignment problems ?

Nope.




Hum, unfortunately, valgrind is not available for sparc.

Then gdb will have to do.



xorriso is the one compiled from isoburn. I tried with the one from the
archive, and the one rebuild from source with a debbuild.
Same problem on both.

If you also built libisofs and libburn from source, then this burries
my theory of a binary incompatibility between two SPARC machines.


I'm compiling at this moment the vanilla xorriso from gnu.
Let's see what it yields.

It has the same source as the three library tarballs used as input
for Debian's xorriso. Only difference is that GNU xorriso brings
own copies of the library source code and links it statically with
the xorriso main program.
So it can be easily tested without interfering with installations
of the libraries. (And with no need for superuser privileges.)

I filed a bug with xorriso. Waiting for the number to show up.



Have a nice day :)

Thomas



You too ; ).

Seb


--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/535e3cf6.3080...@nerim.net



Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

2014-04-28 Thread Steve McIntyre
On Mon, Apr 28, 2014 at 01:20:20PM +0200, Thomas Schmitt wrote:
>Hi,
>
>> I may provide you access to a shell account on my machines if needed.
>
>Yes, please.
>
>Plus a directory tree
>  ./tmp/miniiso/cd_tree
>which can cause the xorriso crash.
>
>
>> Sparc architecture is extremely picky about alignement. Bad alignement,
>> yields SIGSEGV whereas intel only do it in the less efficient way.
>
>I would suspect the habit of my libisofs predecessor developer
>to use structs as access frame for byte arrays read from file.
>
>But why then was it possible to produce
>  debian-7.4.0-sparc-netinst.iso
>by xorriso-1.2.6 as can be read from its "Preparer Id":
>  XORRISO-1.2.6 2013.01.08.103001, LIBISOBURN-1.2.6, LIBISOFS-1.2.6, 
> LIBBURN-1.2.6
>Does debian-cd pull "sparc" trees onto a non-sparc machine ?

Yes. We build all the release images on an amd64 machine, pettersson.d.o

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"The problem with defending the purity of the English language is that
 English is about as pure as a cribhouse whore. We don't just borrow words; on
 occasion, English has pursued other languages down alleyways to beat them
 unconscious and rifle their pockets for new vocabulary."  -- James D. Nicoll


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140428113544.ga30...@einval.com



Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

2014-04-28 Thread Thomas Schmitt
Hi,

> I may provide you access to a shell account on my machines if needed.

Yes, please.

Plus a directory tree
  ./tmp/miniiso/cd_tree
which can cause the xorriso crash.


> Sparc architecture is extremely picky about alignement. Bad alignement,
> yields SIGSEGV whereas intel only do it in the less efficient way.

I would suspect the habit of my libisofs predecessor developer
to use structs as access frame for byte arrays read from file.

But why then was it possible to produce
  debian-7.4.0-sparc-netinst.iso
by xorriso-1.2.6 as can be read from its "Preparer Id":
  XORRISO-1.2.6 2013.01.08.103001, LIBISOBURN-1.2.6, LIBISOFS-1.2.6, 
LIBBURN-1.2.6
Does debian-cd pull "sparc" trees onto a non-sparc machine ?


> [genisoimage]
> (gdb) x rpnt
> 0x1ea7f9:0x
> (gdb) x lpnt
> 0x1e9dc1:0x0100
> (gdb) n
> 659if (strcmp(rpnt, lpnt) == 0) {

Both values match the prescribed names for "." and ".." in ECMA-119
(aka ISO 9660), 6.8.2.2 Identification of directories:
Single byte 0x00 is ".", single byte 0x01 is "..".

> So, strcmp shouldn't have yielded 0 when comparing the strings.

Can this be caused by alignment problems ?


> Hum, unfortunately, valgrind is not available for sparc.

Then gdb will have to do.


> xorriso is the one compiled from isoburn. I tried with the one from the
> archive, and the one rebuild from source with a debbuild.
> Same problem on both.

If you also built libisofs and libburn from source, then this burries
my theory of a binary incompatibility between two SPARC machines.

> I'm compiling at this moment the vanilla xorriso from gnu.
> Let's see what it yields.

It has the same source as the three library tarballs used as input
for Debian's xorriso. Only difference is that GNU xorriso brings
own copies of the library source code and links it statically with
the xorriso main program.
So it can be easily tested without interfering with installations
of the libraries. (And with no need for superuser privileges.)


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/22916707656401032...@scdbackup.webframe.org



Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

2014-04-28 Thread Sébastien Bernard

Le 28/04/2014 12:09, Thomas Schmitt a écrit :

Hi,


I tried with the xorriso -as mkisofs command, with no luck.
This command terminates with a SIGBUS no matter of the options I pass on
the command line.

Ouch.
I have no Debian of arch "sparc" in reach.

I may provide you access to a shell account on my machines if needed.

xorriso -as mkisofs -r -J -o ./tmp/miniiso/mini.iso -G /boot/isofs.b -B
... ./tmp/miniiso/cd_tree/

Valgrind on Linux accuses xorriso-1.3.2 of a small memory leak
with such a run, but not of memory problems.
Sparc architecture is extremely picky about alignement. Bad alignement, 
yields SIGSEGV whereas intel only do it in the less efficient way.






Seems to me that there an alignment problem with xorriso.

That would rather be a C compiler problem then.

But given the strange error message of genisoimage, this may
well be a local filesystem peculiarity which causes a chain
of bad memory access with more or less random end.

I traced the problem with debugger, here's the catch:
--
(gdb) c
Continuing.

Breakpoint 3, compare_dirs (rr=0x1e1e60, ll=0x1e1e70) at 
/home/seb/dev/cdrkit-1.1.11/genisoimage/write.c:652

652if ((*r)->assoc && (*r)->assoc == (*l))
(gdb) p **r
$71 = {next = 0x1ea5b0, jnext = 0x0, isorec = {length = "f", 
ext_attr_length = "", extent = "\000\000\000\000\000\000\000",
size = "\000\000\000\000\000\000\000", date = 
"r\004\031\001;\016\b", flags = "\002", file_unit_size = "", interleave 
= "",
volume_sequence_number = "\001\000\000\001", name_len = "\001", 
name = '\000' }, starting_block = 0,
  size = 0, priority = 0, jreclen = 0 '\000', name = 0x1ea948 ".", 
table = 0x0,
  whole_name = 0x1ea958 "./tmp/miniiso/cd_tree/boot/.", filedir = 
0x1e1470, parent_rec = 0x0, de_flags = 0, inode = 2498532,
  dev = 64774, rr_attributes = 0x1ea980 "RR\005\001\201PX$\001mA", 
rr_attr_size = 67, total_rr_attr_size = 67, got_rr_name = 0,
  assoc = 0x0, hfs_ent = 0x0, hfs_off = 0, hfs_type = 0, sort = 0, 
udf_file_entry_sector = 0, realsize = 0}

(gdb) p **l
$72 = {next = 0x1e9ba0, jnext = 0x0, isorec = {length = "f", 
ext_attr_length = "", extent = "\000\000\000\000\000\000\000",
size = "\000\000\000\000\000\000\000", date = 
"r\004\031\001;\016\b", flags = "\002", file_unit_size = "", interleave 
= "",
volume_sequence_number = "\001\000\000\001", name_len = "\001", 
name = "\001", '\000' },
  starting_block = 0, size = 0, priority = 0, jreclen = 0 '\000', name 
= 0x1e1548 "..", table = 0x0,
  whole_name = 0x1e9f10 "./tmp/miniiso/cd_tree/boot/..", filedir = 
0x1e1470, parent_rec = 0x0, de_flags = 0, inode = 2498510,
  dev = 64774, rr_attributes = 0x1e9f38 "RR\005\001\201PX$\001mA", 
rr_attr_size = 67, total_rr_attr_size = 67, got_rr_name = 0,
  assoc = 0x0, hfs_ent = 0x0, hfs_off = 0, hfs_type = 0, sort = 0, 
udf_file_entry_sector = 0, realsize = 0}

(gdb) n
654if ((*l)->assoc && (*l)->assoc == (*r))
(gdb)
644rpnt = (*r)->isorec.name;
(gdb)
645lpnt = (*l)->isorec.name;
(gdb) x rpnt
0x1ea7f9:0x
(gdb) x lpnt
0x1e9dc1:0x0100
(gdb) n
659if (strcmp(rpnt, lpnt) == 0) {
(gdb) n
661errmsgno(EX_BAD,
--
So, strcmp shouldn't have yielded 0 when comparing the strings.




3- Fix the xorriso for alignment problem

I would love to get this done.

Can you get me a stack trace ?

Can you run it with valgrind and send me the message output ?

Hum, unfortunately, valgrind is not available for sparc.


If the failing machine is not the one which compiled xorriso
from the libisoburn source package, can you try with
   wget http://www.gnu.org/software/xorriso/xorriso-1.3.2.tar.gz
   tar xzf xorriso-1.3.2.tar.gz
   cd xorriso-1.3.2 && ./configure && make
   abs_path=$(pwd)
Without need for superuser or installation try:
   cd ...where.appropriate...
   "$abs_path"/xorriso/xorriso -as mkisofs ...above.options...
xorriso is the one compiled from isoburn. I tried with the one from the 
archive, and the one rebuild from source with a debbuild.

Same problem on both.
I'm compiling at this moment the vanilla xorriso from gnu. Let's see 
what it yields.





Have a nice day :)

Thomas


Thanks, you too.

Seb


--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/535e2d72.4070...@nerim.net



Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

2014-04-28 Thread Thomas Schmitt
Hi,

> I tried with the xorriso -as mkisofs command, with no luck.
> This command terminates with a SIGBUS no matter of the options I pass on 
> the command line.

Ouch.
I have no Debian of arch "sparc" in reach.


> xorriso -as mkisofs -r -J -o ./tmp/miniiso/mini.iso -G /boot/isofs.b -B 
> ... ./tmp/miniiso/cd_tree/

Valgrind on Linux accuses xorriso-1.3.2 of a small memory leak
with such a run, but not of memory problems.


> Seems to me that there an alignment problem with xorriso.

That would rather be a C compiler problem then.

But given the strange error message of genisoimage, this may
well be a local filesystem peculiarity which causes a chain
of bad memory access with more or less random end.


> 3- Fix the xorriso for alignment problem

I would love to get this done.

Can you get me a stack trace ?

Can you run it with valgrind and send me the message output ?

If the failing machine is not the one which compiled xorriso
from the libisoburn source package, can you try with
  wget http://www.gnu.org/software/xorriso/xorriso-1.3.2.tar.gz
  tar xzf xorriso-1.3.2.tar.gz
  cd xorriso-1.3.2 && ./configure && make
  abs_path=$(pwd)
Without need for superuser or installation try:
  cd ...where.appropriate...
  "$abs_path"/xorriso/xorriso -as mkisofs ...above.options...


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/24331670761945484...@scdbackup.webframe.org



Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

2014-04-28 Thread Sébastien Bernard

I've been looking through this problem.

genisoimage is reporting a problem with . and .. aliased to the same '' 
name.

logs of the problem:
-
genisoimage -r -J -o ./tmp/miniiso/mini.iso -G /boot/isofs.b -B ... 
./tmp/miniiso/cd_tree

I: -input-charset not specified, using utf-8 (detected in locale settings)
genisoimage: Error: './tmp/miniiso/cd_tree/boot/.' and 
'./tmp/miniiso/cd_tree/boot/..' have the same ISO9660 name ''.

Unable to sort directory ./tmp/miniiso/cd_tree/boot
-

I tried with the xorriso -as mkisofs command, with no luck.
This command terminates with a SIGBUS no matter of the options I pass on 
the command line.

Seems to me that there an alignment problem with xorriso.
Here's the log associated
-
xorriso -as mkisofs -r -J -o ./tmp/miniiso/mini.iso -G /boot/isofs.b -B 
... ./tmp/miniiso/cd_tree/

xorriso 1.3.2 : RockRidge filesystem manipulator, libburnia project.

Drive current: -outdev 'stdio:./tmp/miniiso/mini.iso'
Media current: stdio file, overwriteable
Media status : is blank
Media summary: 0 sessions, 0 data blocks, 0 data, 9163m free
Added to ISO image: directory 
'/'='/home/seb/dev/debian-installer-20140316/build/tmp/miniiso/cd_tree'

xorriso : UPDATE : 7 files added in 1 seconds
xorriso : UPDATE : 7 files added in 1 seconds
xorriso : NOTE : Copying to System Area: 7040 bytes from file 
'/boot/isofs.b'


UNIX-SIGNAL: SIGBUS errno= 13
xorriso : ABORT : Trying to shut down busy drives
xorriso : ABORT : Wait the normal burning time before any kill -9
bus error
-

Finally, I downloaded the cdrtools from berlios, and rebuild a mkisofs 
from source.
With this mkisofs, the build of the iso went without a problem, so I'm 
thinking this problem seems to be a bug in the genisoimage.

Here's the log:
-
../../cdrtools-3.01/mkisofs/OBJ/sparc64-linux-cc/mkisofs -r -J -o 
./tmp/miniiso/mini.iso -G /boot/isofs.b -B ... ./tmp/miniiso/cd_tree/

Setting input-charset to 'UTF-8' from locale.
Total translation table size: 0
Total rockridge attributes bytes: 966
Total directory bytes: 2048
Path table size(bytes): 22
Total extents including sparc boot = 4160
Max brk space used 0
4310 extents written (8 MB)
-

So, this does not seems to be related to sparc, but rather to genisoimage.
There 3 ways possibles to fix this in increasing workload :
1- Create a package for mkisofs original which works ok to generate this 
iso.

2- Fix the genisoimage
3- Fix the xorriso for alignment problem

I'll have a look at the genisoimage.

My 0,02€ contribution.

S. Bernard


--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/535e16c5.4070...@nerim.net



Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

2013-12-09 Thread Cyril Brulebois
Source: debian-installer
Version: 20131014
Severity: serious
Justification: FTBFS

Hi people,

(-sparc, -cd, genisoimage maintainers x-d-cc'd)

debian-installer 20131014 FTBFS'd on the buildd with:
| […]
| install -m 644 ./tmp/miniiso/boot_screens/notsupported.txt 
./tmp/miniiso/cd_tree/boot
| install -m 644 boot/sparc/silo.conf ./tmp/miniiso/cd_tree/boot
| genisoimage -r -J -o ./tmp/miniiso/mini.iso -G /boot/isofs.b -B ... 
./tmp/miniiso/cd_tree
| genisoimage: Error: './tmp/miniiso/cd_tree/boot/.' and 
'./tmp/miniiso/cd_tree/boot/..' have the same ISO9660 name ''.
| Unable to sort directory ./tmp/miniiso/cd_tree/boot

Full build log:
  
https://buildd.debian.org/status/fetch.php?pkg=debian-installer&arch=sparc&ver=20131014&stamp=1381835153

I can't tell for sure since it's been a while but I think I was unable
to reproduce it on a porterbox. Probably some FS-dependent fun? Anyone
would have a clue about it?

Thanks for your time.

Mraw,
KiBi.


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131209224418.24637.51617.reportbug@arya