Re: [Clamav-devel] ClamAV 0.100 could not compile on AIX 6.1
Hi, Micah.
No, I didn't attach anything.
Thank you for your advice.
As your advice, I tried.
As a result, the warning messages is no longer outputed.
However, link errors are the problem.
To resolve this, it was necessary to create "libclammspack.a" in advance.
Is there a bad place to reference with the make command?
The processing time has increased by 25%, is not it a problem?
Now that the module has been made, I will try to run it for a while.
T.O
On Wed, 25 Apr 2018 13:38:02 +
"Micah Snyder (micasnyd)" <micas...@cisco.com> wrote:
> Did you try to attach something? Attachments don't work with the mailing
> list. If needed, you can add attachments to comments on the related bugzilla
> ticket (https://bugzilla.clamav.net/show_bug.cgi?id=12089)
>
> -Micah
>
>
> Micah Snyder
> ClamAV Development
> Talos
> Cisco Systems, Inc.
>
>
> On Apr 25, 2018, at 8:33 AM, Tsutomu Oyamada
> <oyam...@promark-inc.com<mailto:oyam...@promark-inc.com>> wrote:
>
> Thank you for your reply.
> Try this. The results are reported after the test.
>
> T.O
>
> On Fri, 20 Apr 2018 14:55:00 +
> "Micah Snyder (micasnyd)" <micas...@cisco.com<mailto:micas...@cisco.com>>
> wrote:
>
> Sorry for the lag time getting back to you Tsutomu.
>
> That is a very good question.
>
> At a minimum, it looks as though the function definition should be
>
>
> static inline int64_t cli_readint64(const void *buff)
>
>
> instead of
>
>
> static inline int32_t cli_readint64(const void *buff)
>
>
> That said, it also appears that the lines in cli_readint64() and others
> should more explicitly cast the type prior to the shift. Something like:
>
>
>
> diff --git a/libclamav/others.h b/libclamav/others.h
> index 65d20ef17..ab32e8fcb 100644
> --- a/libclamav/others.h
> +++ b/libclamav/others.h
> @@ -579,18 +579,18 @@ struct unaligned_ptr {
> #define be32_to_host(v) (v)
> #define be64_to_host(v) (v)
>
> -static inline int32_t cli_readint64(const void *buff)
> +static inline int64_t cli_readint64(const void *buff)
> {
> int64_t ret;
> -ret = ((const char *)buff)[0] & 0xff;
> -ret |= (((const char *)buff)[1] & 0xff) << 8;
> -ret |= (((const char *)buff)[2] & 0xff) << 16;
> -ret |= (((const char *)buff)[3] & 0xff) << 24;
> -
> -ret |= (((const char *)buff)[4] & 0xff) << 32;
> -ret |= (((const char *)buff)[5] & 0xff) << 40;
> -ret |= (((const char *)buff)[6] & 0xff) << 48;
> -ret |= (((const char *)buff)[7] & 0xff) << 56;
> +ret = (int64_t)((const char *)buff)[0] & 0xff;
> +ret |= (int64_t)(((const char *)buff)[1] & 0xff) << 8;
> +ret |= (int64_t)(((const char *)buff)[2] & 0xff) << 16;
> +ret |= (int64_t)(((const char *)buff)[3] & 0xff) << 24;
> +
> +ret |= (int64_t)(((const char *)buff)[4] & 0xff) << 32;
> +ret |= (int64_t)(((const char *)buff)[5] & 0xff) << 40;
> +ret |= (int64_t)(((const char *)buff)[6] & 0xff) << 48;
> +ret |= (int64_t)(((const char *)buff)[7] & 0xff) << 56;
> return ret;
> }
>
>
> Any chance you could try that patch to see if the warnings go away?
>
> Regarding the 'ld' ERROR's youre seeing. It looks as though it's failing to
> link correctly against libmspack or libclammspack. Despite the above bug,
> this is what is now preventing you from completing the build. It may have
> something to do with the ' --disable-static ' on your configure line.
>
> Micah Snyder
> ClamAV Development
> Talos
> Cisco Systems, Inc.
>
>
> On Apr 14, 2018, at 8:12 AM, Tsutomu Oyamada
> <oyam...@promark-inc.com<mailto:oyam...@promark-inc.com><mailto:oyam...@promark-inc.com>>
> wrote:
>
> ld: 0711-317 ERROR: Undefined symbol: .mspack_create_cab_decompressor
> ld: 0711-317 ERROR: Undefined symbol: .mspack_destroy_cab_decompressor
> ld: 0711-317 ERROR: Undefined symbol: .mspack_create_chm_decompressor
> ld: 0711-317 ERROR: Undefined symbol: .mspack_destroy_chm_decompressor
> ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
> collect2: error: ld returned 8 exit status
> ---
>
> This message "Warning: Left shift count > = width of type" is many.
> The following is the message in configure:
>
> checking size of short... 2
> checking size of int... 4
> checking size of long... 8
> checking size of long long... 8
> checking size of void *
Re: [Clamav-devel] ClamAV 0.100 could not compile on AIX 6.1
Thank you for your advice. I tried. # export OBJECT_MODE="64" # export CFLAGS="-maix64" # export LDFLAGS="-maix64 -Wl,-bbigtoc" # ./configure # make However, this time it was another error. --- # make (snip) CC libclamav_internal_utils_la-regfree.lo In file included from ./matcher.h:29:0, from ./others.h:22, from regex/regfree.c:43: ./others.h: In function 'cli_readint64': ./others.h:590:49: warning: left shift count >= width of type [-Wshift-count-overflow] ret |= (((const char *)buff)[4] & 0xff) << 32; ^~ ./others.h:591:49: warning: left shift count >= width of type [-Wshift-count-overflow] ret |= (((const char *)buff)[5] & 0xff) << 40; ^~ ./others.h:592:49: warning: left shift count >= width of type [-Wshift-count-overflow] ret |= (((const char *)buff)[6] & 0xff) << 48; ^~ ./others.h:593:49: warning: left shift count >= width of type [-Wshift-count-overflow] ret |= (((const char *)buff)[7] & 0xff) << 56; ^~ CC libclamav_internal_utils_la-strlcat.lo CCLD libclamav_internal_utils.la CCLD libclamav.la ld: 0711-317 ERROR: Undefined symbol: .mspack_create_cab_decompressor ld: 0711-317 ERROR: Undefined symbol: .mspack_destroy_cab_decompressor ld: 0711-317 ERROR: Undefined symbol: .mspack_create_chm_decompressor ld: 0711-317 ERROR: Undefined symbol: .mspack_destroy_chm_decompressor ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: error: ld returned 8 exit status --- This message "Warning: Left shift count > = width of type" is many. The following is the message in configure: checking size of short... 2 checking size of int... 4 checking size of long... 8 checking size of long long... 8 checking size of void *... 8 The size of the variable type is in 32bit mode. Is this correct? On Fri, 13 Apr 2018 13:15:47 + "Micah Snyder (micasnyd)" <micas...@cisco.com> wrote: > It will be tough for us to fix this, because I don't have an AIX machine to > test with. > > A quick Google search for "conflicting types for 'fsync_range64'" shows a > bunch fo people with similar errors compiling other software on AIX. The 2nd > link down had a similar issue and appear to have to worked around it by > rearranging their #include's: > https://github.com/nagios-plugins/nagios-plugins/issues/40 > > Hard to say if we could do something similar. Again, I don't have the means > to test any changes. > > > Micah Snyder > ClamAV Development > Talos > Cisco Systems, Inc. > > > On Apr 12, 2018, at 10:03 PM, Tsutomu Oyamada > <oyam...@promark-inc.com<mailto:oyam...@promark-inc.com>> wrote: > > Thank you for your reply. > It certainly seems to be the same thing. > Is this a bug? > > By the way, I tried to configure it with "CFLAGS =-maix64" And it was an > error the following. > - > # make >make all-recursive > Making all in libltdl >cp ./argz_.h argz.h-t >mv argz.h-t argz.h >make all-am > CC dlopen.lo > CCLD dlopen.la<http://dlopen.la> > ar: 0707-126 .libs/dlopen.o is not valid with the current object file mode. >Use the -X option to specify the desired object mode. > -- > T.O > > > On Thu, 12 Apr 2018 15:06:25 + > "Micah Snyder (micasnyd)" <micas...@cisco.com<mailto:micas...@cisco.com>> > wrote: > > It looks like Dwight is experiencing the same issue with AIX 5.3: > > https://bugzilla.clamav.net/show_bug.cgi?id=12089 > > > Micah Snyder > ClamAV Development > Talos > Cisco Systems, Inc. > > > On Apr 12, 2018, at 8:49 AM, Tsutomu Oyamada > <oyam...@promark-inc.com<mailto:oyam...@promark-inc.com>> wrote: > > I am experimenting with compiling a new version of ClamAV 0.100 on Aix > 6.1. > The result of configure is as follows: > -- > # ./configure --prefix=/usr/lib/clamav --exec-prefix=/usr/lib/clamav > --bindir=/usr/lib/clamav --sbindir=/usr/lib/clamav > --sysconfdir=/etc/clamav --libdir=/usr/lib/clamav > --datarootdir=/usr/lib/clamav --with-dbdir=/usr/lib/clamav --disable-clamav -- > enable-shared --disable-static --disable-zlib-vcheck --with-pcre > --with-openssl=/opt/freeware --enable-strni > checking build system type... powerpc-ibm-aix6.1.0.0 > checking host system type... powerpc-ibm-aix6.1.0.0 > checking target system type... powerpc-ibm-aix6.1.
Re: [Clamav-devel] ClamAV 0.100 could not compile on AIX 6.1
Thank you for your reply. It certainly seems to be the same thing. Is this a bug? By the way, I tried to configure it with "CFLAGS =-maix64" And it was an error the following. - # make make all-recursive Making all in libltdl cp ./argz_.h argz.h-t mv argz.h-t argz.h make all-am CC dlopen.lo CCLD dlopen.la ar: 0707-126 .libs/dlopen.o is not valid with the current object file mode. Use the -X option to specify the desired object mode. -- T.O On Thu, 12 Apr 2018 15:06:25 + "Micah Snyder (micasnyd)" <micas...@cisco.com> wrote: > It looks like Dwight is experiencing the same issue with AIX 5.3: > > https://bugzilla.clamav.net/show_bug.cgi?id=12089 > > > Micah Snyder > ClamAV Development > Talos > Cisco Systems, Inc. > > > On Apr 12, 2018, at 8:49 AM, Tsutomu Oyamada > <oyam...@promark-inc.com<mailto:oyam...@promark-inc.com>> wrote: > > I am experimenting with compiling a new version of ClamAV 0.100 on Aix > 6.1. > The result of configure is as follows: > -- > # ./configure --prefix=/usr/lib/clamav --exec-prefix=/usr/lib/clamav > --bindir=/usr/lib/clamav --sbindir=/usr/lib/clamav > --sysconfdir=/etc/clamav --libdir=/usr/lib/clamav > --datarootdir=/usr/lib/clamav --with-dbdir=/usr/lib/clamav --disable-clamav -- > enable-shared --disable-static --disable-zlib-vcheck --with-pcre > --with-openssl=/opt/freeware --enable-strni > checking build system type... powerpc-ibm-aix6.1.0.0 > checking host system type... powerpc-ibm-aix6.1.0.0 > checking target system type... powerpc-ibm-aix6.1.0.0 > creating target.h - canonical system defines > checking for a BSD-compatible install... config/install-sh -c > checking whether build environment is sane... yes > checking for a thread-safe mkdir -p... config/install-sh -c -d > checking for gawk... no > checking for mawk... no > checking for nawk... nawk > checking whether make sets $(MAKE)... yes > checking whether make supports nested variables... yes > checking whether UID '0' is supported by ustar format... yes > checking whether GID '0' is supported by ustar format... yes > checking how to create a ustar tar archive... gnutar > checking whether make supports nested variables... (cached) yes > checking for style of include used by make... GNU > checking for gcc... gcc > checking whether the C compiler works... yes > checking for C compiler default output file name... a.out > checking for suffix of executables... > checking whether we are cross compiling... no > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ISO C89... none needed > checking whether gcc understands -c and -o together... yes > checking dependency style of gcc... gcc3 > checking how to run the C preprocessor... gcc -E > checking for grep that handles long lines and -e... /usr/bin/grep > checking for egrep... /usr/bin/grep -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking minix/config.h usability... no > checking minix/config.h presence... no > checking for minix/config.h... no > checking whether it is safe to define __EXTENSIONS__... yes > checking how to print strings... print -r > checking for a sed that does not truncate output... /usr/bin/sed > checking for fgrep... /usr/bin/grep -F > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... no > checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B > checking the name lister (/usr/bin/nm -B) interface... BSD nm > checking whether ln -s works... yes > checking the maximum length of command line arguments... 786432 > checking whether the shell understands some XSI constructs... yes > checking whether the shell understands "+="... no > checking how to convert powerpc-ibm-aix6.1.0.0 file names to > powerpc-ibm-aix6.1.0.0 format... func_convert_file_noop > checking how to convert powerpc-ibm-aix6.1.0.0 file names to toolchain > format... func_convert_file_noop > checking for /usr/bin/ld option to reload object files... -r > checking for objdump... no > checking how to recognize dependent libraries... pass_all > checking for dlltool... no > checking how to associate runtime and link libraries... print -r -- > checking for ar... ar > checking for archiver @FILE support... no > check
[Clamav-devel] ClamAV 0.100 could not compile on AIX 6.1
ious declaration of 'pwrite64' was h ere extern ssize_t pwrite(int, const void *, size_t, off_t); ^ /opt/freeware/lib/gcc/powerpc-ibm-aix6.1.0.0/6.3.0/include-fixed/unistd.h:972:17: error: conflicting types for 'fclear64' extern off64_t fclear64(int, off64_t); ^~~~ /opt/freeware/lib/gcc/powerpc-ibm-aix6.1.0.0/6.3.0/include-fixed/unistd.h:969:15: note: previous declaration of 'fclear64' was h ere extern off_t fclear(int, off_t); ^ /opt/freeware/lib/gcc/powerpc-ibm-aix6.1.0.0/6.3.0/include-fixed/unistd.h:973:13: error: conflicting types for 'fsync_range64' extern int fsync_range64(int, int, off64_t, off64_t); ^ /opt/freeware/lib/gcc/powerpc-ibm-aix6.1.0.0/6.3.0/include-fixed/unistd.h:970:13: note: previous declaration of 'fsync_range64' was here extern int fsync_range(int, int, off_t, off_t); ^ make: The error code from the last command is 1. Stop. make: The error code from the last command is 1. Stop. make: The error code from the last command is 2. Stop. make: The error code from the last command is 1. Stop. make: The error code from the last command is 2. Stop. -- Please give me some advice. Best regards. Tsutomu Oyamada ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net http://www.clamav.net/contact.html#ml
[Clamav-devel] Question about mpool_malloc() error on 0.97.8
We have a question about mpool_malloc() error of version 0.97.8, as follows. We know this error is caused by small value of fragsz[](defined libclamav/mpool.c). Is this understanding correct? Is there any reason why it doesnot stop unusually (abnormally), when the error was happened. (It seems that treatment for the error was not completed correctly.) The size was increased from 0.98 to 1.28MB (8MB formerly). Is that correct? And, Shall the similar error occurred, if it would become to be not big enough? We are worrying if the same issue will occure out again, because; We found that clamd went into an infinite loop and spent 100% of CPU in the case of reading of CVD, when engine v.0.97.8 was reading CVD v.22408 ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net http://www.clamav.net/contact.html#ml
[Clamav-devel] about the MaxFileSize limit during scan
Hi, all. We can set a limitation to MaxFileSize and MaxRecursion, when to perform a scan with clamd. If the virus file matching this restriction, Specifications will determine that the file is clean? As an extreme case, in clamd.conf file set the MaxFileSize as 50. To scan the eicar.com file then judged and clean file. In this case, Can we find if the scan was not completed and was failed? If yes, How? Thanks, Oyamada ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net
Re: [Clamav-devel] build for s390x system
Hi, Dave
I've re-build of clamAV.
As a result, confirmed that work just fine.
Your advice was valid.
Thank you very much.
T.Oyamada
On Thu, 26 Sep 2013 09:07:53 +0900
Tsutomu Oyamada oyam...@promark-inc.com wrote:
Hi, Dave.
Thanks your advice.
I changed type of fp_digit.
and I tried test program.
fp_digit: 4
unsigned long: 8
FP_64BIT not defined
DIGIT_BIT: 32
CHAR_BIT: 8
FP_MAX_SIZE: 8448
FP_SIZE: 264
TFM_ASM not defined
fp_word: 8
ulong64: 8
unsigned long long: 8
CRYPT not defined
It works good.
I will try re-compile clamav.
Later report the results.
T.Oyamada
On Wed, 25 Sep 2013 17:13:58 -0400
David Raynor dray...@sourcefire.com wrote:
On Wed, Sep 25, 2013 at 2:55 PM, David Raynor dray...@sourcefire.comwrote:
On Tue, Sep 24, 2013 at 9:47 PM, Tsutomu Oyamada
oyam...@promark-inc.comwrote:
Hi, Dave.
Thanks for your advice and quick respons.
I tried it.
fp_digit: 8
unsigned long: 8
FP_64BIT not defined
DIGIT_BIT: 64
CHAR_BIT: 8
FP_MAX_SIZE: 8704
FP_SIZE: 136
TFM_ASM not defined
fp_word: 8
ulong64: 8
unsigned long long: 8
CRYPT not defined
What should I just do in order to fix this problem?
Please teach me how to set size of fp_word to 16.
T.Oyamada
On Tue, 24 Sep 2013 18:16:26 -0400
David Raynor dray...@sourcefire.com wrote:
On Tue, Sep 24, 2013 at 4:37 PM, David Raynor dray...@sourcefire.com
wrote:
On Tue, Sep 24, 2013 at 2:05 AM, Tsutomu Oyamada
oyam...@promark-inc.comwrote:
Hi,
I investigated the value using the following programs.
#include stdlib.h
#include bignum_fast.h
int main(int argc, char **argv) {
printf(fp_digit: %d\n,sizeof(fp_digit));
printf(unsigned long: %d\n,sizeof(unsigned long));
#ifdef FP_64BIT
printf(FP_64BIT: %d\n,FP_64BIT);
#else
printf(FP_64BIT not defined\n);
#endif
#ifdef DIGIT_BIT
printf(DIGIT_BIT: %d\n,DIGIT_BIT);
#else
printf(DIGIT_BIT not defined\n);
#endif
#ifdef CHAR_BIT
printf(CHAR_BIT: %d\n,CHAR_BIT);
#else
printf(CHAR_BIT not defined\n);
#endif
#ifdef FP_MAX_SIZE
printf(FP_MAX_SIZE: %d\n,FP_MAX_SIZE);
#else
printf(FP_MAX_SIZE not defined\n);
#endif
#ifdef FP_SIZE
printf(FP_SIZE: %d\n,FP_SIZE);
#else
printf(FP_SIZE not defined\n);
#endif
#ifdef TFM_ASM
printf(TFM_ASM: defined\n);
#else
printf(TFM_ASM not defined\n);
#endif
exit(0);
}
The result was as follows.
fp_digit: 8
unsigned long: 8
FP_64BIT not defined
DIGIT_BIT: 64
CHAR_BIT: 8
FP_MAX_SIZE: 8704
FP_SIZE: 136
TFM_ASM not defined
Can you find a problem by this result?
Thanks.
--
T.Oyamada
___
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net
I do not have an immediate fix, but that information does give me
some
leads.
Basic issue: the tomsfastmath code must be falling through to the
code
block on lines 280-302 of fp_mul_comba.c.
1) The right shift causing the warning is DIGIT_BIT (64).
2) The datatype being shifted is fp_word.
3) fp_word defined as typedef ulong64 fp_word; from bignum_fast.h
line
253
4) ulong64 defined as typedef unsigned long long ulong64; from
bignum_fast.h line 248
I think the problem is one of three issues:
A) fp_word is not defined as a 64-bit datatype.
B) line 301 of tomsfastmath/mul/fp_mul_comba.c is mistakenly
downcasting t
from fp_word to fp_digit before shifting.
C) s390 is not allowing use of all 64 bits of fp_word.
Problems A or B are easier fixed than C.
Please add these lines to your test and re-run:
printf(fp_word: %d\n,sizeof(fp_word));
printf(ulong64: %d\n,sizeof(ulong64));
printf(unsigned long long: %d\n,sizeof(unsigned long long));
#ifdef CRYPT
printf(CRYPT: defined\n);
#else
printf(CRYPT not defined\n);
#endif
I would like to see the config.log file generated by running
configure. It
would also be useful to have the full output from running make. The
log
snip shows line 91, but I expect that it first warned about line 15.
The easiest way to continue and share logfiles is via Bugzilla.
Please
open a bug report on bugzilla.clamav.net on this issue. You can then
attach the files to that bug.
Hope this helps,
Dave R.
--
---
Dave
Re: [Clamav-devel] build for s390x system
Hi,
I investigated the value using the following programs.
#include stdlib.h
#include bignum_fast.h
int main(int argc, char **argv) {
printf(fp_digit: %d\n,sizeof(fp_digit));
printf(unsigned long: %d\n,sizeof(unsigned long));
#ifdef FP_64BIT
printf(FP_64BIT: %d\n,FP_64BIT);
#else
printf(FP_64BIT not defined\n);
#endif
#ifdef DIGIT_BIT
printf(DIGIT_BIT: %d\n,DIGIT_BIT);
#else
printf(DIGIT_BIT not defined\n);
#endif
#ifdef CHAR_BIT
printf(CHAR_BIT: %d\n,CHAR_BIT);
#else
printf(CHAR_BIT not defined\n);
#endif
#ifdef FP_MAX_SIZE
printf(FP_MAX_SIZE: %d\n,FP_MAX_SIZE);
#else
printf(FP_MAX_SIZE not defined\n);
#endif
#ifdef FP_SIZE
printf(FP_SIZE: %d\n,FP_SIZE);
#else
printf(FP_SIZE not defined\n);
#endif
#ifdef TFM_ASM
printf(TFM_ASM: defined\n);
#else
printf(TFM_ASM not defined\n);
#endif
exit(0);
}
The result was as follows.
fp_digit: 8
unsigned long: 8
FP_64BIT not defined
DIGIT_BIT: 64
CHAR_BIT: 8
FP_MAX_SIZE: 8704
FP_SIZE: 136
TFM_ASM not defined
Can you find a problem by this result?
Thanks.
--
T.Oyamada
On Mon, 23 Sep 2013 12:56:59 -0400
David Raynor dray...@sourcefire.com wrote:
On Mon, Sep 23, 2013 at 11:00 AM, Tsutomu Oyamada
oyam...@promark-inc.comwrote:
Hi, all.
We are using ClamAV for IBM zLinux (s390x architecture)
So many Warnings were output as follows, when we made a new build
with using the new release 0.98.
# ./configure --prefix=/usr/lib/clamav --exec-prefix=/usr/lib/clamav
--bindir=/usr/lib/clamav --sbindir=/usr/lib/clamav --sysconfdir=/etc/clamav
--libdir=/usr/lib/clamav --datarootdir=/usr/lib/clamav
--with-dbdir=/usr/lib/clamav --disable-clamav --with-zlib=/usr/local
--with-libbz2-prefix=/usr/local
(snip)
# make
(snip)
tomsfastmath/mul/fp_mul_comba_20.c:91: warning: right shift count = width
of type
tomsfastmath/mul/fp_mul_comba_20.c:91: warning: right shift count = width
of type
tomsfastmath/mul/fp_mul_comba_20.c:91: warning: right shift count = width
of type
And, the binary did not work properly as a result.
Is there any special settings in a case of make for s390?
Can I have any advice/suggestion?
Best Regards,
Oyamada
___
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net
That line (and other ones like it in fp_mul_comba_20.c) are doing
calculations using an array of elements of type fp_digit. fp_digit is
defined in libclamav/bignum_fast.h.
I don't have access to a s390 to test with and I don't see any notes on
tomsfastmath and s390, so I will need your help to investigate. Can you get
me some values as calculated by bignum_fast.h?
1) Sizes of two types: sizeof(fp_digit), sizeof(unsigned long)
2) Values of these defined macros, if defined: FP_64BIT, DIGIT_BIT,
CHAR_BIT, FP_MAX_SIZE, FP_SIZE, TFM_ASM
Thanks,
Dave R.
--
---
Dave Raynor
Sourcefire Vulnerability Research Team
dray...@sourcefire.com
___
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net
___
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net
Re: [Clamav-devel] build for s390x system
Hi, Dave.
Thanks for your advice and quick respons.
I tried it.
fp_digit: 8
unsigned long: 8
FP_64BIT not defined
DIGIT_BIT: 64
CHAR_BIT: 8
FP_MAX_SIZE: 8704
FP_SIZE: 136
TFM_ASM not defined
fp_word: 8
ulong64: 8
unsigned long long: 8
CRYPT not defined
What should I just do in order to fix this problem?
Please teach me how to set size of fp_word to 16.
T.Oyamada
On Tue, 24 Sep 2013 18:16:26 -0400
David Raynor dray...@sourcefire.com wrote:
On Tue, Sep 24, 2013 at 4:37 PM, David Raynor dray...@sourcefire.comwrote:
On Tue, Sep 24, 2013 at 2:05 AM, Tsutomu Oyamada
oyam...@promark-inc.comwrote:
Hi,
I investigated the value using the following programs.
#include stdlib.h
#include bignum_fast.h
int main(int argc, char **argv) {
printf(fp_digit: %d\n,sizeof(fp_digit));
printf(unsigned long: %d\n,sizeof(unsigned long));
#ifdef FP_64BIT
printf(FP_64BIT: %d\n,FP_64BIT);
#else
printf(FP_64BIT not defined\n);
#endif
#ifdef DIGIT_BIT
printf(DIGIT_BIT: %d\n,DIGIT_BIT);
#else
printf(DIGIT_BIT not defined\n);
#endif
#ifdef CHAR_BIT
printf(CHAR_BIT: %d\n,CHAR_BIT);
#else
printf(CHAR_BIT not defined\n);
#endif
#ifdef FP_MAX_SIZE
printf(FP_MAX_SIZE: %d\n,FP_MAX_SIZE);
#else
printf(FP_MAX_SIZE not defined\n);
#endif
#ifdef FP_SIZE
printf(FP_SIZE: %d\n,FP_SIZE);
#else
printf(FP_SIZE not defined\n);
#endif
#ifdef TFM_ASM
printf(TFM_ASM: defined\n);
#else
printf(TFM_ASM not defined\n);
#endif
exit(0);
}
The result was as follows.
fp_digit: 8
unsigned long: 8
FP_64BIT not defined
DIGIT_BIT: 64
CHAR_BIT: 8
FP_MAX_SIZE: 8704
FP_SIZE: 136
TFM_ASM not defined
Can you find a problem by this result?
Thanks.
--
T.Oyamada
___
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net
I do not have an immediate fix, but that information does give me some
leads.
Basic issue: the tomsfastmath code must be falling through to the code
block on lines 280-302 of fp_mul_comba.c.
1) The right shift causing the warning is DIGIT_BIT (64).
2) The datatype being shifted is fp_word.
3) fp_word defined as typedef ulong64 fp_word; from bignum_fast.h line
253
4) ulong64 defined as typedef unsigned long long ulong64; from
bignum_fast.h line 248
I think the problem is one of three issues:
A) fp_word is not defined as a 64-bit datatype.
B) line 301 of tomsfastmath/mul/fp_mul_comba.c is mistakenly downcasting t
from fp_word to fp_digit before shifting.
C) s390 is not allowing use of all 64 bits of fp_word.
Problems A or B are easier fixed than C.
Please add these lines to your test and re-run:
printf(fp_word: %d\n,sizeof(fp_word));
printf(ulong64: %d\n,sizeof(ulong64));
printf(unsigned long long: %d\n,sizeof(unsigned long long));
#ifdef CRYPT
printf(CRYPT: defined\n);
#else
printf(CRYPT not defined\n);
#endif
I would like to see the config.log file generated by running configure. It
would also be useful to have the full output from running make. The log
snip shows line 91, but I expect that it first warned about line 15.
The easiest way to continue and share logfiles is via Bugzilla. Please
open a bug report on bugzilla.clamav.net on this issue. You can then
attach the files to that bug.
Hope this helps,
Dave R.
--
---
Dave Raynor
Sourcefire Vulnerability Research Team
dray...@sourcefire.com
I think I read something wrong, and I think I have an idea. It still needs
to be confirmed by the additional test lines above. Re-reading the output,
I think that the code is depending on fp_word being twice the size of
fp_digit. Based on fp_digit size of 8 that means it would expect it to be
16. If sizeof(fp_word) is resolving to 8 and sizeof(fp_digit) is 8, that
could be the problem. Then the fix would depend on whether fp_word can be
made size 16 or must be constrained to size 8.
Let me know what you find,
Dave R.
--
---
Dave Raynor
Sourcefire Vulnerability Research Team
dray...@sourcefire.com
___
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net
___
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net
[Clamav-devel] build for s390x system
Hi, all. We are using ClamAV for IBM zLinux (s390x architecture) So many Warnings were output as follows, when we made a new build with using the new release 0.98. # ./configure --prefix=/usr/lib/clamav --exec-prefix=/usr/lib/clamav --bindir=/usr/lib/clamav --sbindir=/usr/lib/clamav --sysconfdir=/etc/clamav --libdir=/usr/lib/clamav --datarootdir=/usr/lib/clamav --with-dbdir=/usr/lib/clamav --disable-clamav --with-zlib=/usr/local --with-libbz2-prefix=/usr/local (snip) # make (snip) tomsfastmath/mul/fp_mul_comba_20.c:91: warning: right shift count = width of type tomsfastmath/mul/fp_mul_comba_20.c:91: warning: right shift count = width of type tomsfastmath/mul/fp_mul_comba_20.c:91: warning: right shift count = width of type And, the binary did not work properly as a result. Is there any special settings in a case of make for s390? Can I have any advice/suggestion? Best Regards, Oyamada ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net
