Hi All,
According to DWARF spec, a subprogram 'may' have DW_AT_return_addr
attribute. Please help me understand the following::
(1). GCC (latest) does not emit DW_AT_return_addr attributes in subprogram tags
(2). If [1] is true, then is it because of the fact that return
address can be computed
On 20 October 2011 20:27, Paulo J. Matos wrote:
> On 20/10/11 15:06, Anitha Boyapati wrote:
>>
>> Firstly, aren't discriminators introduced in DWARF 4? Little more
>> digging shows that the following fix is missing in 4.6.1 release. It
>> breaks the current dwarf
Hi,
I have recently switched to using GCC 4.6.1 (from 4.5.1) for AVR
target which supports only DWARF2 format. Now I notice a change in
.debug_line section format in 4.6.1. A quick look at the assembly
shows that '.loc' directives are emitted with discriminators.
Firstly, aren't discriminators
On 11 February 2011 00:20, Richard Henderson wrote:
> On 02/09/2011 08:55 AM, Anitha Boyapati wrote:
>> Reverse-conditional Branch
>>
>>> (jump_insn 9 8 34 3 gt.c:4 (set (pc)
>>> (if_then_else (gt:CC (cc0)
>>> (const_in
On 9 February 2011 22:28, Richard Guenther wrote:
> On Wed, Feb 9, 2011 at 5:55 PM, Anitha Boyapati
> wrote:
>> On 9 February 2011 20:34, Ian Lance Taylor wrote:
>>
>>>> I would like to know what prompts gcc to decide if "le" can be used in
>>&g
On 9 February 2011 20:34, Ian Lance Taylor wrote:
>> I would like to know what prompts gcc to decide if "le" can be used in
>> the expand pass rather than "gt" operator. Or more precisely why it
>> differs incase of float.
>
> The choice of LE when using int is just a happenstance of the way that
Hello All,
I am trying to understand rtl generation. For the following testcase
I have dumped the rtl... (version: gcc-4.3.3, target: AVR32 not
upstreamed yet)
int main() {
volatile int a, b;
if(a>b) return 1;
else return 2;
}
Expand pass shows that "le"operator is c
Hello,
Could someone comment on the below issue please ? If it is a bug, I
would like to file in bugzilla. But before that I can use some help.
Thanks
Anitha
-- Forwarded message --
From: Anitha Boyapati
Date: 29 December 2010 18:44
Subject: Re: ICE in
Hi,
> +rtx
> +avr_incoming_return_addr_rtx (void)
> +{
> + /* Compute return address which is stored on the stack.
> + Current stack pointer at the begining of frame, before the prologue
> + execution holds the return address. So our job is done if we get
> + the stack pointer registe
Hello All,
I am working on supporting call-stack debugging information for AVR
port. DWARF2 is already supported in gcc-4.4.3 but not call-stack
debug info. GCC internals document refers to INCOMING_RETURN_ADDR_RTX
and RTX_FRAME_RELATED_P. Incase of AVR, there is no link register.
Return addres
Hi,
On a quick look ---
>
> My apologies if this message doesnt seem appropriate on this list.
gcc-help list is appropriate for such issues.
> _handle = dlopen( "./libchrcv.so", RTLD_NOW | RTLD_GLOBAL );
Have you tried with any other library or only this ? I tried the entire
program wit
so as not to spam every
one (Please see the message below for further details).
Thanks!
--
Regards,
Anitha B
@S A N K H Y A
-- Forwarded message --
Date: Wed, 25 Jul 2007 15:15:24 +0530 (IST)
From: Anitha Boyapati <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
S
Hi,
>I know GCC is a wonderful compiler collection. I like it and trust
> it.
That sounds dramatic. Never trust a compiler if you want to test it :)
> But, I can't find any formal docs about Testing GCC, both unit
> testing and integrat testing. I think, as a software, GCC should be
>
13 matches
Mail list logo
