Effect of 'register' keyword on debug info
Hello All,
I came across this issue while working with PowerPC GCC tool chain
v4.5.2 for e500mc(64bit)/e5500.
Test case compiled with '-O0 -g'.
/** Test Case /
1: int main()
2: {
3: int i=0;
4:
5: register float f1 = 55.77f;
6: register double d1 = 22.99f;
7:
8: while (i <= 100) ---(A)
9: {
10: i++;
11: f1 = (float)i / 177 + (float)d1;
12: d1 = (double)i / 155677 + f1;
13: i += (int)d1;
14: }
15: }
/ Debug Info */
<2><5d>: Abbrev Number: 3 (DW_TAG_variable)
<5e> DW_AT_name: f1
<61> DW_AT_decl_file : 1
<62> DW_AT_decl_line : 5
<63> DW_AT_type: <0x7f>
<67> DW_AT_location: 2 byte block: 90 3f (DW_OP_regx: 63)
<2><6a>: Abbrev Number: 3 (DW_TAG_variable)
<6b> DW_AT_name: d1
<6e> DW_AT_decl_file : 1
<6f> DW_AT_decl_line : 6
<70> DW_AT_type: <0x86>
<74> DW_AT_location: 2 byte block: 90 3f (DW_OP_regx: 63)
/ Generated Assembly */
...
.LCFI1:
.cfi_def_cfa_register 31
# main.c:3
.loc 1 3 0
li 0,0 # tmp129,
stw 0,48(31) # i, tmp129
# main.c:5
.loc 1 5 0
lfs 31,.LC0@toc(2) #, f1 - > (variable F1)
# main.c:6
.loc 1 6 0
lfd 31,.LC1@toc(2) #, d1 > (variable D1)
# main.c:8
.loc 1 8 0
b .L2#
.
Looking at the debug info and the generated assembly, the values of
variables 'f1' and 'd1' are stored in the same register.
Due to this, while debugging, after setting the break point at (A)
[line no 8], if we print the value of 'f1' i get the wrong value.
/ Debugger Output */
(gdb) n
5 register float f1 = 55.77f;
(gdb) n
6 register double d1 = 22.99f;
(gdb) n
8 while (i <= 100)
(gdb) p f1
$1 = 22.988
(gdb) p d1
$2 = 22.98771118164
//
Q: Is this the side effect of using 'register' keyword? If 'f1' is
getting optimized out, shouldn't we get that info while debugging?
Also, using -fvar-tracking, i get this output while debugging the same code.
/ Debugger Output */
5 register float f1 = 55.77f;
(gdb) n
6 register double d1 = 22.99f;
(gdb) n
8 while (i <= 100)
(gdb) p f1
$5 =
(gdb) p d1
$6 = 22.98771118164
//
Regards,
Rohit
Re: making sizeof(void*) different from sizeof(void(*)())
Michael Meissner wrote: > On Sat, Apr 28, 2012 at 02:32:18PM -0500, Peter Bigot wrote: >> The MSP430's split address space and ISA make it expensive to place >> data above the 64 kB boundary, but cheap to place code there. So I'm >> looking for a way to use HImode for data pointers, but PSImode for >> function pointers. If gcc supports this, it's not obvious how. >> >> I get partway there with FUNCTION_MODE and some hacks for the case >> where the called object is a symbol, but not when it's a >> pointer-to-function data object. As an example, bootstrapping fails >> in libgcc/unwind-dw2-fde.c because the fde_compare pointer-to-function >> object is stored in a HImode register instead of a PSImode register. >> >> The only candidate solution I've seen (and haven't yet tried) is to >> somehow assign all functions to be in a special named address space >> and use TARGET_ADDR_SPACE_POINTER_MODE to override the normal use of >> ptr_mode in build_pointer_type. >> >> I haven't been able to identify an existing back-end that has such a >> case, though I'd swear I've seen memory models like this for some >> other processor in the past. > > In the original 1989 ANSI C standard (which became the 1990 ISO C standard) > function pointers could be a different size than void * pointers. In that > standard, void * and char * had to have the same underlying size and > representation. I don't recall if C99 changed this in any way. > > The D10V port sort of cheated in that it had 16-bit pointers that were byte > pointers for data, and 16-bit pointers that were word pointers for functions, > and it caused a number of issues, back when I did the D10V many years ago. > However, since the D10V has been removed quite some time ago, it is no longer > relevant. The AVR port does the same: Function addresses are word addresses whereas data addresses are byte addresses. Johann > Another way to go is what we do in 64-bit powerpc -- function pointers are > actually pointers to a 3 word descriptor, that contains the real function > address, the value to load into the GOT pointer, and the value to load into > the > register holding the static chain.
mkconfig.sh incrementality?
At the bottom of mkconfig.sh in 4.6.2 and 4.7.0:
# Avoid changing the actual file if possible.
if [ -f $output ] && cmp ${output}T $output >/dev/null 2>&1; then
echo $output is unchanged >&2
rm -f ${output}T
else
mv -f ${output}T $output
fi
# Touch a stamp file for Make's benefit.
rm -f cs-$output
echo timestamp > cs-$output
Shouldn't the timestamp > cs-$output only be a) mainly if the other file
updated, by the mv and b) corner case, if it doesn't exist?
Maybe rm -rf by the mv, and echo if not exist?
- Jay
Re: Effect of 'register' keyword on debug info
Rohit Arul Raj writes: > Looking at the debug info and the generated assembly, the values of > variables 'f1' and 'd1' are stored in the same register. > Due to this, while debugging, after setting the break point at (A) > [line no 8], if we print the value of 'f1' i get the wrong value. > Q: Is this the side effect of using 'register' keyword? If 'f1' is > getting optimized out, shouldn't we get that info while debugging? This question as stated is not really appropriate for the mailing list gcc@gcc.gnu.org, which is for the development of GCC itself. This question would be appropriate for gcc-h...@gcc.gnu.org. Please take any followups to gcc-help. Thanks. This has nothing to do with using the register keyword. Yes, you should ideally be told when a value is unavailable. This specific area of GCC has been much improved since GCC 4.5.2. > Also, using -fvar-tracking, i get this output while debugging the same > code. That looks like better output to me. Ian
Re: mkconfig.sh incrementality?
Jay K writes:
> At the bottom of mkconfig.sh in 4.6.2 and 4.7.0:
>
>
> # Avoid changing the actual file if possible.
> if [ -f $output ] && cmp ${output}T $output >/dev/null 2>&1; then
> echo $output is unchanged >&2
> rm -f ${output}T
> else
> mv -f ${output}T $output
> fi
>
> # Touch a stamp file for Make's benefit.
> rm -f cs-$output
> echo timestamp > cs-$output
>
>
>
> Shouldn't the timestamp > cs-$output only be a) mainly if the other file
> updated, by the mv and b) corner case, if it doesn't exist?
> Maybe rm -rf by the mv, and echo if not exist?
No. This is all about having make do the right thing. Look at the
rules that invoke mkconfig.sh in gcc/Makefile.in.
Ian
Please Update the Installing GCC: Binaries Page
Dear GCC This is Colin Prior from Sunfreeware and UNIX Packages. Please would you be good enough to update http://gcc.gnu.org/install/binaries.html and add www.unixpackages.com We as you will see from the Sunfreeware site we have removed the majority of our packages including GCC (Solaris 2.5, 2.6 7, 8, and 9) over to the our new site. We may well be interested in doing some joint marketing with you. Let me know if that's of interest. BTW you may want to consider removing the Blastwave link as to all intents and purposes that site has been dead for some time now. Cheers Colin Colin Prior Unix Packages +1 206 310 4610 co...@unixpackages.com
MPC/MPFR/GMP Usage
Hey everyone, I'm using gcc-4.6.3 as part of the YAGARTO toolchain (http://www.yagarto.de) with an STM32 ARM Cortex-M3 chip and was wondering: what are the math libraries (MPC, MPFR, and GMP) used for? Are they only required internally by gcc or are they implicitly added to the final binary produced by gcc? Thanks, Andrew
Re: MPC/MPFR/GMP Usage
2012/5/24 Andrew Burks: > Hey everyone, > > I'm using gcc-4.6.3 as part of the YAGARTO toolchain > (http://www.yagarto.de) with an STM32 ARM Cortex-M3 chip and was > wondering: what are the math libraries (MPC, MPFR, and GMP) used for? > Are they only required internally by gcc or are they implicitly added > to the final binary produced by gcc? Only for internally using by GCC. -- Regards, niXman ___ Dual-target(i686/x86_64) MinGW compiler for i686/x86_64 hosts: http://sourceforge.net/projects/mingwbuilds/
Re: C++98/C++11 ABI compatibility for gcc-4.7
I've posted this to http://gcc.gnu.org/wiki/Cxx11AbiCompatibility. I
would greatly appreciate any corrections or improvements.
On Tue, May 22, 2012 at 9:04 AM, Jeffrey Yasskin wrote:
> I've put together the following description of C++98/11 ABI
> (in)compatibility, so people can tell which libraries need to be
> recompiled. This is useful when you've bought a library that didn't
> come with source code, and you're trying to figure out if you need to
> buy a new version. I think this belongs on the Wiki somewhere, but I
> wanted to run it by the list first to make sure it's accurate. You can
> probably skip the first section, since it's just a description of how
> to use the subsequent list.
>
>
>
> This page explains how to identify when your pre-compiled library (.a
> or .so) defines a symbol that has a different enough definition in
> C++98 vs C++11 that it could cause runtime problems if it's linked
> into a program compiled for the other version.
>
> First, get a list of demangled symbols from your .a or .so:
>
> $ (find . -name '*.a'|xargs nm -f posix; find . -name '*.so' | xargs
> nm -f posix -D)|cut -f1 -d' '|LANG=C sort -u|c++filt|sort
>
> (There may be better ways to get this list.)
>
> Next, find instances in this list of the ABI changes listed below.
> For example, you might find:
>
> std::_List_base >::_M_clear()
>
> Since std::_List_base::_M_clear() destroys nodes, it's affected by the
> addition of the _M_size field and can't be used by C++11 code if it
> was compiled for C++98, or vice versa. If it's possible that code
> outside the library would use this instance of _List_base, then you
> have to recompile the library. On the other hand, if FooBar is a type
> used only inside this library, then code using the library is safe.
> If FooBar is defined by the library but exposed in one of the
> library's headers, then the library still needs to be recompiled,
> since code using it could wind up including the other version's
> implementation.
>
>
> === ABI Changes ===
>
> complex::{real,imag}(), std::{real,imag}(complex)
>
> The non-const overloads go from returning _Tp& to _Tp.
> [Since gcc-4.4]
>
>
> std::list, std::_List_impl, and std::_List_base
>
> New _M_size member, meaning any method that adds or removes nodes or
> inspects the size has a new ABI.
> [Since gcc-4.7]
>
>
> std::operator-(reverse_iterator) and std::operator-(__normal_iterator)
> may return a different type if
> reverse_iterator<_IteratorL>::difference_type (respectively,
> __normal_iterator<_IteratorL, _Container>::difference_type) isn't
> accurate.
> [Since gcc-4.4]
>
>
> map::erase(iterator), multimap::erase(iterator),
> set::erase(const_iterator), set::erase(const_iterator,
> const_iterator), multiset::erase(const_iterator),
> multiset::erase(const_iterator, const_iterator):
>
> Return type changes from void to iterator.
> [Since gcc-4.5]
>
>
> _Rb_tree::erase(const_iterator), _Rb_tree T>::erase(const_iterator, const_iterator), _Rb_tree pair>::erase(iterator):
>
> Return type changes from void to iterator. these are instantiated from
> map and set.
> [Since gcc-4.5]
>
>
> vector::data()'s return type changes from pointer to _Tp*
>
> This is a no-op with most allocators, but any allocator that defines a
> non-default pointer typedef will be incompatible.
> [Since gcc-4.6]
>
>
>
> Probably safe: istreambuf_iterator::reference changes from _CharT& to _CharT.
>
> This could affect return types if they mention 'reference', but they
> appear not to mention it when istreambuf_iterator is involved.
> [Since gcc-4.7]
>
>
> Probably safe: map::erase(iterator, iterator),
> multimap::erase(iterator, iterator)
>
> C++11 uses const_iterator, which doesn't collide. Other versions of
> gcc are unlikely to have defined this overload in C++98 mode, and
> C++11 is unlikely to have defined the iterator version.
>
> [Since gcc-4.5]
>
>
> Probably safe: Types with node allocators, like deque and tree
>
> C++11 uses _M_get_Node_allocator().construct(node, ...), while C++98
> uses get_allocator().construct(node->_M_value_field, ...). The node's
> constructor forwards to the value_field's constructor, so this works
> by default. Can this cause problems with some mix of C++98/C++11
> allocator compilations?
>
>
>
>
> I haven't analyzed the debug and profile headers.
>
>
>
>
> I found these differences by grepping for GXX_EXPERIMENTAL_CXX0X
> inside libstdc++, and examining each instance to see if there was an
> #else clause that had different behavior in C++11 vs C++98.
>
>
> === ABI non-changes ===
>
> libstdc++'s binary component is nearly ABI-compatible between C++98
> and C++11. Most incompatibilities are in the templates defined in
> headers, but the complex<> stream operators call the real() and imag()
> methods that change return type. If these calls aren't inlined, (and
> they're likely to be inlined), then libstdc++ (which is compiled in
> C++98 mode by default) could cause problems when linked into C++11
> programs. (http://gc
