changelog of trunk including comments / devtalk - page 29 - General Discussion and Assistance - CHDK Forum

changelog of trunk including comments / devtalk

  • 288 Replies
  • 148495 Views
*

Offline srsa_4c

  • ******
  • 3904
Re: changelog of trunk including comments / devtalk
« Reply #280 on: 21 / May / 2019, 13:25:22 »
Advertisements
Compiling current trunk (r5210...5214) gives me this:
Code: [Select]
ptp_op_names.c:243:12: error: 'NULL' undeclared (first use in this function)
     return NULL;
            ^
My host compiler is
Code: [Select]
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.8/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.8 --enable-ssp --disable-libssp --disable-plugin --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --enable-linker-build-id --enable-linux-futex --program-suffix=-4.8 --without-system-libunwind --with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux --host=x86_64-suse-linux
Thread model: posix
gcc version 4.8.5 (SUSE Linux)
Apparently, no such problems on the autobuild and at the other devs. What could I be missing?

*

Offline reyalp

  • ******
  • 11897
Re: changelog of trunk including comments / devtalk
« Reply #281 on: 21 / May / 2019, 13:40:09 »
Apparently, no such problems on the autobuild and at the other devs. What could I be missing?
I added stddef which should ensure it's defined. Not including it was a mistake, which I didn't notice because apparently NULL gets implicitly defined by stdint on some compilers.

My host compiler is
Code: [Select]
$ gcc -v
Using built-in specs.
COLLECT_GCC=C:\msys64\mingw32\bin\gcc.exe
COLLECT_LTO_WRAPPER=C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/7.4.0/lto-wrapper.exe
Target: i686-w64-mingw32
Configured with: ../gcc-7.4.0/configure --prefix=/mingw32 --with-local-prefix=/mingw32/local --build=i686-w64-mingw32 --host=i686-w64-mingw32 --target=i686-w64-mingw32 --with-native-system-header-dir=/mingw32/i686-w64-mingw32/include --libexecdir=/mingw32/lib --enable-bootstrap --with-arch=i686 --with-tune=generic --enable-languages=c,lto,c++,objc,obj-c++,fortran,ada --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-time=yes --enable-libstdcxx-filesystem-ts=yes --disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check --enable-lto --enable-libgomp --disable-multilib --enable-checking=release --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw32 --with-mpfr=/mingw32 --with-mpc=/mingw32 --with-isl=/mingw32 --with-pkgversion='Rev1, Built by MSYS2 project' --with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as --with-gnu-ld --disable-sjlj-exceptions --with-dwarf2
Thread model: posix
gcc version 7.4.0 (Rev1, Built by MSYS2 project)
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 3904
Re: changelog of trunk including comments / devtalk
« Reply #282 on: 21 / May / 2019, 14:07:41 »
I added stddef which should ensure it's defined.
Thanks.
Quote
Not including it was a mistake, which I didn't notice because apparently NULL gets implicitly defined by stdint on some compilers.
Since this was the second time such things happened to me, I looked up the cause:
Standards.html packaged with gcc 4 states that
Quote
The default, if no C language dialect options are given,
is -std=gnu90; this is intended to change to -std=gnu11 in some future release.
Current gcc docs say that
Quote
The default, if no C language dialect options are given, is -std=gnu11.
Maybe we should specify -std in our makefiles?

*

Offline reyalp

  • ******
  • 11897
Re: changelog of trunk including comments / devtalk
« Reply #283 on: 22 / May / 2019, 02:53:19 »
Maybe we should specify -std in our makefiles?
That seems like a good idea in general, but in my environment at least setting -std=gnu90 or -std=gnu11 makes to no difference for the NULL issue. The msys stdint.h appears to define NULL through one of things it includes.

I don't think NULL should be defined implicitly by any version of the C standard, but I could be wrong.
« Last Edit: 22 / May / 2019, 18:10:04 by reyalp »
Don't forget what the H stands for.


*

Offline srsa_4c

  • ******
  • 3904
Re: changelog of trunk including comments / devtalk
« Reply #284 on: 22 / May / 2019, 14:51:04 »
That seems like a good idea in general, but in my environment at least setting -std=gnu90 or -std=gnu11 makes to difference for the NULL issue. The msys stdint.h appears to define NULL through one of things it includes.

I don't think NULL should be defined implicitly by any version of the C standard, but I could be wrong.
I tried building r5214 with -std=gnu11 added to the host CFLAGS, and it worked.
Which standard do we want? The code has been kept compatible with gnu90 so far.

*

Offline reyalp

  • ******
  • 11897
Re: changelog of trunk including comments / devtalk
« Reply #285 on: 22 / May / 2019, 18:09:35 »
Which standard do we want? The code has been kept compatible with gnu90 so far.
I don't have a strong preference. We're not likely to need the newer features of c11, but some of them could be convenient. From a quick look, it appears that GCC 4.7 added the gnu11 option in 2012 (https://www.gnu.org/software/gcc/gcc-4.7/changes.html) so if people are still building with earlier versions, that would be a reason to use the older one. Most vaguely current distros should be on something newer, even RHEL7 is on 4.8.
I'm not sure what the host compiler on the autobuild is now, but it should be at least 4.7.

We could always switch to a newer standard later.

Setting the gnu90 won't avoid recurrence of the particular problem with NULL, since my setup compiled the offending file with either standard.
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 3904
Re: changelog of trunk including comments / devtalk
« Reply #286 on: 23 / May / 2019, 12:18:09 »
I compared output of the unpatched version with the patched version, with both capstone 3 and 4. No difference for any model I have dumps for. I also did full disassembly of g7x and sx710, and got effectively identical output. On sx710, a few literal pools where garbage previously  disassembled as ssat/usat failed to disassemble instead. All other differences were due CHDK code/stubs changes since the last time I did a full disassembly.

IMO, we should drop capstone 3 support fairly quickly, since it requires a source patch and there's a risk of getting different output from things like the differences in handling invalid code.
I was using a patched 3.0.4 capstone library, up until today. When rebuilding stubs for thumb2 cameras, I noticed that the results differ from official source. Diff attached (a bunch of ptp handlers not identified). I then removed the 3.0.4 files, installed 4.0.1, and got no differences when rebuilding stubs.

*

Offline reyalp

  • ******
  • 11897
Re: changelog of trunk including comments / devtalk
« Reply #287 on: 23 / May / 2019, 13:27:45 »
I was using a patched 3.0.4 capstone library, up until today. When rebuilding stubs for thumb2 cameras, I noticed that the results differ from official source. Diff attached (a bunch of ptp handlers not identified). I then removed the 3.0.4 files, installed 4.0.1, and got no differences when rebuilding stubs.
Thanks for catching that. I'll take a look later, but this is why I'd prefer to standardize on 4.x. I don't want to routinely test multiple versions or maintain all the ifdefs.

In practice, I think this means making sure the windows tool https://chdk.setepontos.com/index.php?topic=12752.0 plays nicely with it. The issue is that the precompiled binaries only work with gcc if linked to the DLL, and then the DLL needs to be on the path, and the library name changes. So we need to either provide a static package (which should be pretty easy) or adjust what options the tool uses. I'll try to put together a static, GCC compiled package that works with the windows toolchain.

Once that's done and posted, I'll probably change the thumb2 tools to error if capstone is the older version, so people know to update.

Don't forget what the H stands for.


*

Offline reyalp

  • ******
  • 11897
Re: changelog of trunk including comments / devtalk
« Reply #288 on: 25 / May / 2019, 03:08:57 »
I was using a patched 3.0.4 capstone library, up until today. When rebuilding stubs for thumb2 cameras, I noticed that the results differ from official source. Diff attached (a bunch of ptp handlers not identified). I then removed the 3.0.4 files, installed 4.0.1, and got no differences when rebuilding stubs.
It looks like a bug in capstone 3.x, arm.operands[1].shift.value is not set. The check doesn't seem to be required for any current firmware, so I commented it out.
Don't forget what the H stands for.

 

Related Topics