Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > inline functions

Reply
Thread Tools

inline functions

 
 
Sergio Durigan Junior
Guest
Posts: n/a
 
      11-29-2012
On Thursday, November 29 2012, James Kuyper wrote:

> On 11/29/2012 10:24 AM, Malcolm McLean wrote:
> ...
>> But I usually find diagnostic printfs() easier to work with than debuggers.

>
> [...] We're now using exclusively
> gcc, and I have only gdb to debug with, and even when I compile with
> -O0, the behavior of the code as displayed by gdb quite frequently
> deviates significantly from what I wrote. I can't be sure whether this
> is due to the compiler or the debugger, or both.


This really shouldn't happen. Have you filed any bugs for GDB? If not,
I'd suggest you do so. What is the version of GCC and GDB that you're
using? It is very hard to say, but it seems GCC is generating wrong
debug information and GDB is getting lost.

Anyway, I was one of the 'printf' guys before myself, but when I really
learned how to use a debugger in a decent way, I must confess that it's
been ages since I don't do printf-debugging . But of course, I guess
this is more a matter of taste than anything else.

--
Sergio
 
Reply With Quote
 
 
 
 
Ian Collins
Guest
Posts: n/a
 
      11-29-2012
James Kuyper wrote:
> On 11/29/2012 10:24 AM, Malcolm McLean wrote:
> ....
>> But I usually find diagnostic printfs() easier to work with than debuggers.

>
> In my experience, that depends upon the debugger, the compiler, and the
> type of problem being debugged. We used to use the Irix MIPS-Pro C
> compiler, and I used dbx to debug problems when necessary; I only rarely
> felt the need to use debugging printf()s. We're now using exclusively
> gcc, and I have only gdb to debug with, and even when I compile with
> -O0, the behavior of the code as displayed by gdb quite frequently
> deviates significantly from what I wrote. I can't be sure whether this
> is due to the compiler or the debugger, or both.
> As a result, I've often found it necessary to use debugging printf()s to
> extract information about what's going on that's actually consistent
> with the way I wrote the code.


If you are working on OS X, Solaris or FeeeBSD, you can insert DTrace
probes in your code to extract information about what's going on and
leave them there to help you analyse performance in production. Very handy!

--
Ian Collins
 
Reply With Quote
 
 
 
 
Les Cargill
Guest
Posts: n/a
 
      11-29-2012
Sergio Durigan Junior wrote:
> On Thursday, November 29 2012, James Kuyper wrote:
>
>> On 11/29/2012 10:24 AM, Malcolm McLean wrote:
>> ...
>>> But I usually find diagnostic printfs() easier to work with than debuggers.

>>
>> [...] We're now using exclusively
>> gcc, and I have only gdb to debug with, and even when I compile with
>> -O0, the behavior of the code as displayed by gdb quite frequently
>> deviates significantly from what I wrote. I can't be sure whether this
>> is due to the compiler or the debugger, or both.

>
> This really shouldn't happen. Have you filed any bugs for GDB? If not,
> I'd suggest you do so. What is the version of GCC and GDB that you're
> using? It is very hard to say, but it seems GCC is generating wrong
> debug information and GDB is getting lost.
>
> Anyway, I was one of the 'printf' guys before myself, but when I really
> learned how to use a debugger in a decent way, I must confess that it's
> been ages since I don't do printf-debugging . But of course, I guess
> this is more a matter of taste than anything else.
>



it's a matter of having a competent debugger to work with. And a
debugger isn't likely to help much with "emergent" defects - stuff
that fails only in the final hardware in a real configuration.

--
Les Cargill
 
Reply With Quote
 
Sergio Durigan Junior
Guest
Posts: n/a
 
      11-29-2012
On Thursday, November 29 2012, Ian Collins wrote:

> If you are working on OS X, Solaris or FeeeBSD, you can insert DTrace
> probes in your code to extract information about what's going on and
> leave them there to help you analyse performance in production. Very
> handy!


And if you're working on GNU/Linux, you can also insert SDT probes in
your code to achieve the same effect. These probes are also known as
SystemTap userspace probes, and all you need to to is to install
`systemtap-sdt-devel' (if you're on Fedora), and #include <sys/sdt.h> in
your code.

Recently, GDB became aware of such probes as well, so you can access
them inside the debugger. I made a series of blog posts to ilustrate
the process of including the probes in your program and accessing them
inside GDB:

http://blog.sergiodj.net/post/2012-0...probes-part-1/

http://blog.sergiodj.net/post/2012-1...probes-part-2/

http://blog.sergiodj.net/post/2012-1...probes-part-3/

Hope that helps .

--
Sergio
 
Reply With Quote
 
Sergio Durigan Junior
Guest
Posts: n/a
 
      11-29-2012
On Thursday, November 29 2012, Les Cargill wrote:

> it's a matter of having a competent debugger to work with. And a
> debugger isn't likely to help much with "emergent" defects - stuff
> that fails only in the final hardware in a real configuration.


Sorry, but I fail to see your point. I understand that debugging
failures in a production environment sometimes is hard not just because
of the problem itself, but because you just can't stop your business.
Is that what you mean? If it is, I agree, but then I believe you can
try other solutions (like inserting probes in your code, mentioned in
another reply to this sub-thread). However, eventually you will have to
debug your application in a test environment to (at least try to)
replicate the problem you saw on production. In this case, a debugger
helps a lot.

--
Sergio
 
Reply With Quote
 
Les Cargill
Guest
Posts: n/a
 
      11-30-2012
Sergio Durigan Junior wrote:
> On Thursday, November 29 2012, Les Cargill wrote:
>
>> it's a matter of having a competent debugger to work with. And a
>> debugger isn't likely to help much with "emergent" defects - stuff
>> that fails only in the final hardware in a real configuration.

>
> Sorry, but I fail to see your point. I understand that debugging
> failures in a production environment sometimes is hard not just because
> of the problem itself, but because you just can't stop your business.
> Is that what you mean?



No. These are the sort of bugs you find only in a fully loaded system.
They're generally requirement-based defects, not coding errors. I found
that I didn't know well enough how to test to requirements, so that
was the next educational step.

> If it is, I agree, but then I believe you can
> try other solutions (like inserting probes in your code, mentioned in
> another reply to this sub-thread).


yes - that's what I'd generally do ( lots of logging ).

> However, eventually you will have to
> debug your application in a test environment to (at least try to)
> replicate the problem you saw on production. In this case, a debugger
> helps a lot.
>


Right - although I found test harnesses to have more lasting
value, because you can add to them to make a living
regression suite.

--
Les Cargill

 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      12-05-2012
On Wed, 2012-11-28, James Kuyper wrote:
> On 11/28/2012 04:27 PM, Jorgen Grahn wrote:
>> On Mon, 2012-11-26, David Brown wrote:
>> ...
>>> To get good code, it is
>>> important to give the compiler freedom to generate it's best code - that
>>> means [...] and either turning off debug information generation,
>>> or at least picking the most expressive possible debug format (so that
>>> the compiler does not restrict code generation to suit debugger
>>> capabilities).

>>
>> Do any compilers still work that way? Which ones? I remember fighting
>> that idea fifteen years ago. People kept saying
>>
>> "We can't enable debug symbols, because that would disable
>> optimization."
>>
>> or the dreaded
>>
>> "We'll enable optimization later, when we ship the code. We can't
>> do it now, because it would disable debug information."
>>
>> even though our particular compiler's documentation clearly showed
>> that these were unrelated settings.
>>
>> Come to think of it, the fight is still ongoing. Only a month ago I
>> enabled optimization for a piece of performance-critical code.

>
> It's not just a matter of ancient compilers that can't combine debugging
> with optimization.


True, there are other considerations. But the claim was that compilers
can't generate optimized code if debug info is enabled, and that was
what I was questioning.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
Sergio Durigan Junior
Guest
Posts: n/a
 
      12-05-2012
On Saturday, November 24 2012, Jens Gustedt wrote:

> or change to clang, that produces quite readable, annotated assembler
> with the -S option, for which it is much easier to keep track of the
> source lines, much better than gcc


Don't want to cause any flamewars here (nor to hijack the thread), but
can you provide an example? You can use the various -d* (I'm thinking
about -dp here, actually) options on GCC to make it annotate the
assembler. Don't know how clang annotates it, I don't have it installed
here.

Thanks,

--
Sergio
 
Reply With Quote
 
Jens Gustedt
Guest
Posts: n/a
 
      12-05-2012
Am 05.12.2012 06:19, schrieb Sergio Durigan Junior:
> On Saturday, November 24 2012, Jens Gustedt wrote:
>
>> or change to clang, that produces quite readable, annotated assembler
>> with the -S option, for which it is much easier to keep track of the
>> source lines, much better than gcc

>
> Don't want to cause any flamewars here (nor to hijack the thread),


me neither

> but can you provide an example?


> You can use the various -d* (I'm thinking
> about -dp here, actually) options on GCC to make it annotate the
> assembler.


-dp provides a very low level annotation of every assembler statement,
usually not what *I* need to understand the assembler something like

uComp:
..LFB683:
.cfi_startproc
testq %rdx, %rdx # 10 *cmpdi_ccno_1/1 [length = 3]
je .L586 # 11 *jcc_1 [length = 2]
movq (%rdx), %rcx # 13 *movdi_internal_rex64/2 [length = 3]
xorl %edx, %edx # 88 *movdi_xor [length = 2]
movq (%rdi), %rax # 14 *movdi_internal_rex64/2 [length = 3]
divq %rcx # 76 *udivmoddi4_noext [length = 3]
movq (%rsi), %rax # 17 *movdi_internal_rex64/2 [length = 3]
movq %rdx, %rdi # 71 *movdi_internal_rex64/2 [length = 3]
xorl %edx, %edx # 89 *movdi_xor [length = 2]
divq %rcx # 78 *udivmoddi4_noext [length = 3]
xorl %ecx, %ecx # 90 *movsi_xor [length = 2]
cmpq %rdx, %rdi # 91 *cmpdi_1/1 [length = 3]
movl $-1, %eax # 7 *movsi_internal/1 [length = 5]
seta %cl # 92 *setcc_qi_slp [length = 3]
cmovae %ecx, %eax # 63 *movsicc_noc/1 [length = 3]
ret # 82 return_internal [length = 1]
.p2align 4,,10
.p2align 3
..L586:
movq (%rsi), %rcx # 72 *movdi_internal_rex64/2 [length = 3]
xorl %edx, %edx # 85 *movsi_xor [length = 2]
movl $-1, %eax # 6 *movsi_internal/1 [length = 5]
cmpq %rcx, (%rdi) # 86 *cmpdi_1/1 [length = 3]
seta %dl # 87 *setcc_qi_slp [length = 3]
cmovae %edx, %eax # 67 *movsicc_noc/1 [length = 3]
ret # 84 return_internal [length = 1]
.cfi_endproc
..LFE683:
.size uComp, .-uComp


> Don't know how clang annotates it, I don't have it installed
> here.


Clang (with just -S) annotates the same code more lightly but with
higher level annotations corresponding to the structure of the source,
here in particular the if-then-else constructs that generated the
branching.

uComp: # @uComp
.cfi_startproc
# BB#0: # %entry
testq %rdx, %rdx
je .LBB9_3
# BB#1: # %if.then
movq (%rsi), %rax
movq (%rdx), %rsi
xorl %edx, %edx
divq %rsi
movq %rdx, %rcx
movq (%rdi), %rax
xorl %edx, %edx
divq %rsi
movl $-1, %eax
cmpq %rcx, %rdx
jb .LBB9_5
# BB#2: # %cond.false
cmpq %rcx, %rdx
jmp .LBB9_4
..LBB9_3: # %if.else
movq (%rsi), %rcx
movq (%rdi), %rdx
movl $-1, %eax
cmpq %rcx, %rdx
jb .LBB9_5
..LBB9_4: # %cond.false.i
seta %al
movzbl %al, %eax
..LBB9_5: # %return
ret
..Ltmp115:
.size uComp, .Ltmp115-uComp
.cfi_endproc


Jens
 
Reply With Quote
 
Noob
Guest
Posts: n/a
 
      12-05-2012
Jorgen Grahn wrote:

> True, there are other considerations. But the claim was that compilers
> can't generate optimized code if debug info is enabled, and that was
> what I was questioning.


On a related note, gcc now supports a "-Og" optimization level.

http://gcc.gnu.org/onlinedocs/gcc/Op...l#index-Og-734

> Optimize debugging experience. -Og enables optimizations that do not
> interfere with debugging. It should be the optimization level of
> choice for the standard edit-compile-debug cycle, offering a
> reasonable level of optimization while maintaining fast compilation
> and a good debugging experience.


Regards.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Multiple functions (one version being inline and other beingnon-inline) Rahul C++ 3 02-28-2008 03:28 PM
converting inline functions to C functions jamihuq C Programming 7 05-17-2006 08:46 AM
Tool which expands implicitly inline inline functions tthunder@gmx.de C++ 3 06-16-2005 12:54 AM
External inline functions calling internal inline functions Daniel Vallstrom C Programming 2 11-21-2003 01:57 PM
inline or not to inline in C++ Abhi C++ 2 07-03-2003 12:07 AM



Advertisments