RAMPZ is a different issue, we shouldn't mix them up and solve the problems
independently.
RAMPZ is set in __do_copy_data, __do_global_ctors and __do_global_dtors and
thus set appropriately in __tablejump_elpm__.
__tablejump__ does not use ELPM and assumes that jump tables are located in
the
Hi All,
I have couple of comments on this patch, which I think are important
discussing with the avr-gcc community.
Comment - 1:
Has any one verified prologue for functions using global variables? I
think this patch generates incorrect prologue for such cases.
int global;
void func(int p)
{
=atmel@nongnu.org] On
Behalf Of Boyapati, Anitha
Sent: Thursday, October 13, 2011 1:18 PM
To: AVR-GCC-list@nongnu.org
Subject: Re: [avr-gcc-list] [AVR] RTL prologue/epilogue ver.3
Hi All,
I have couple of comments on this patch, which I think are important
discussing with the avr-gcc community
-Original Message-
From: avr-gcc-list-bounces+anitha.boyapati=atmel@nongnu.org
[mailto:avr-gcc-list-bounces+anitha.boyapati=atmel@nongnu.org] On
Behalf Of Georg-Johann Lay
Sent: Thursday, October 13, 2011 1:55 AM
To: avr-gcc-list@nongnu.org
Cc: Jörg Wunsch; Denis Chertykov
-Original Message-
From: Georg-Johann Lay [mailto:a...@gjlay.de]
Sent: Thursday, October 13, 2011 10:14 PM
To: Boyapati, Anitha
Cc: AVR-GCC-list@nongnu.org
Subject: Re: [avr-gcc-list] [AVR] RTL prologue/epilogue ver.3
Boyapati, Anitha schrieb:
Hi All,
I have couple of comments
I am completely in line with Eric: Your debugger will have to get
smarter
and
not the compiler get dumb again.
Johann
As it was put, it is more of a performance question than about the
correctness of it. I am not sure what exactly the issue is, but you are
right that one cannot rely on
If some .data section is loaded in memory then definitely it should be
allocated some memory.
Yes, but not vice-versa. Take .bss for example which is allocatable but not
loadable.
This link also specifies that some section are lodable but not allocatable
Overlays.
These are not
testsuite
Boyapati, Anitha anitha.boyap...@atmel.com wrote:
../../src/adc.c: In function 'adc_intr_cb':
../../src/adc.c:270: error: cast from pointer to integer of different
size
Does the attached patch fix this issue?
Yes it does :-)
Anitha
___
AVR-GCC
Hi All,
Build with DWARF-2 support now works fine for AVR Target for gcc 4.6 branch and
trunk. The following revisions fix it:
GCC 4.6 Branch - http://gcc.gnu.org/viewcvs?view=revisionrevision=175150
GCC Trunk - http://gcc.gnu.org/viewcvs?view=revisionrevision=175018
All the
-Original Message-
From: Marcin S [mailto:msporys...@gmail.com]
Sent: Friday, June 17, 2011 11:26 AM
To: Boyapati, Anitha
Subject: Re: [avr-gcc-list] gcc-4.6 branch build
2011/6/16 Boyapati, Anitha anitha.boyap...@atmel.com:
Hi,
Can someone try building latest gcc-4.6-branch for AVR
-Original Message-
From: Weddington, Eric
Sent: Friday, June 17, 2011 1:52 PM
To: Boyapati, Anitha; avr-gcc-list@nongnu.org
Subject: RE: [avr-gcc-list] AVR GDB testsuite
Hi Anitha,
I'm not sure if anyone has run the *GDB* test suite. Most developers that I
know usually run the GCC
-Original Message-
From: Georg-Johann Lay [mailto:a...@gjlay.de]
Sent: Saturday, June 18, 2011 2:26 AM
To: Boyapati, Anitha
Cc: Weddington, Eric; avr-gcc-list@nongnu.org
Subject: Re: [avr-gcc-list] AVR GDB testsuite
Boyapati, Anitha schrieb:
Aah..I am already running into strange
with: relocation truncated
tofit:R_AVR_13_PCREL
Boyapati, Anitha anitha.boyap...@atmel.com wrote:
1. Why can't rcall/rjmp be used against external symbols?
They can, and they (usually) do.
If the value falls outside the legal range, linker relaxation can
handle it.
No. Linker relaxations can only
Hi,
Can someone try building latest gcc-4.6-branch for AVR with dwarf2 support?
Please let me know if it builds.
Configured with: ../configure --target=avr --prefix=/home/anitha/install/
--with-dwarf2 --enable-languages=c --disable-libssp --disable-nls
--with-gmp=/proj/install/gmp-4.3.2/
-Original Message-
From: Georg-Johann Lay [mailto:a...@gjlay.de]
Sent: Thursday, June 16, 2011 2:24 PM
To: Boyapati, Anitha
Cc: avr-gcc-list@nongnu.org; Denis Chertykov
Subject: Re: [avr-gcc-list] Trouble with: relocation truncated to
fit:R_AVR_13_PCREL
Boyapati, Anitha schrieb
The command line is a typical commandline used in testsuite regression
test runs for avr-gcc.
$avr-libc/libm/fplib/log.S shows explicit use of RCALL/RJMP to
external symbols which should definitely not be there.
1. Why can't rcall/rjmp be used against external symbols? If the value falls
Hi,
I am trying to build recent snapshot gcc-4.7-20110604 without any patches.
Build fails for libgcc2.c. Unless I am doing something wrong, I think the trunk
is broken. Can someone confirm this?
--
checking for suffix of object
Hi,
I am trying to build recent snapshot gcc-4.7-20110604 without any
patches.
Build fails for libgcc2.c. Unless I am doing something wrong, I think the
trunk is broken. Can someone confirm this?
--
checking for suffix of
Further probing shows that dwarf-2 information generation is affected.
--
configure:3056: /home/anitha/gcc-4.7-20110604/objdir/./gcc/xgcc -
B/home/anitha/gcc-4.7-20110604/objdir/./gcc/ -B/usr/local/avr/bin/ -
SHF_WRITE This section contains data that should be writable during
process
execution.
SHF_ALLOC This section occupies memory during process execution. Some
con‐
trol sections do not reside in the memory image of an
object
file.
On 26.02.11 20:22, Boyapati, Anitha wrote:
➢ asm( .section .version,\x\\n
Actually, looking back, I don’t get the meaning of this.
Having just now seen this post, I'll offer the following thoughts.
The flags provide independent control of section attributes. If I have a
separate mechanism
Yes. That is where the confusion stemmed from.
Hi Anitha,
Last time, I didn't look exhaustively for flags in the ELF format. With
the aid of readelf -e test.elf, we can see that there are more section
flags in the section header:
...
Key to Flags:
W (write), A (alloc), X (execute), M
-Original Message-
From: avr-gcc-list-bounces+anitha.boyapati=atmel@nongnu.org
[mailto:avr-gcc-list-bounces+anitha.boyapati=atmel@nongnu.org] On
Behalf Of Boyapati, Anitha
Sent: Wednesday, May 25, 2011 10:34 PM
To: dva...@internode.on.net; avr-gcc-list@nongnu.org
Subject: Re
Quick comment on the new description
emit_move_insn(gen_rtx_MEM(QImode,address+1), GEN_INT(value 8));
emit_move_insn(gen_rtx_MEM(QImode,address), GEN_INT(value 0xff));
gen_rtx_MEM() expects type rtx not short. Also you consider using gen_rtx_PLUS
for (address+1)
Anitha
-Original Message-
From: avr-gcc-list-bounces+anitha.boyapati=atmel@nongnu.org
[mailto:avr-gcc-list-bounces+anitha.boyapati=atmel@nongnu.org] On
Behalf Of Georg-Johann Lay
Sent: Friday, April 01, 2011 4:34 PM
To: Joerg Wunsch
Cc: avr-gcc-list@nongnu.org
Subject: Re:
I am trying to understand relocation types in AVR. To start with,
can someone illustrate how R_AVR_16 works in the following case?
I can only guess. Don't know whether there's someone with more
insight.
Yea...I was hoping if someone who ported binutils to AVR is also here. But I
guess I am
Hi,
[Ideally this is the binutils part of it. But I am continuing anyway hoping to
get some immediate help in AVR target.]
I am trying to understand relocation types in AVR. To start with, can someone
illustrate how R_AVR_16 works in the following case?
long i;
int main()
{
return
What I'm after is basically a way to extend the variables storage
within the gcc/libc framework. To store variables in an external sram
rather than internal sram. My (limited) understanding is that is the
heap storage.
Heap storage is used only for dynamic memory allocation. All local and
Hi Ray,
As for the other concerns, I am not really looking at pushing this
upstream but more a project for myself that I would make available to
the world as an optional patch.
I think it is too preliminary to decide whether this can go upstream. Let the
requirement and design evolve. Then we
➢ asm( .section .version,\x\\n
Actually, looking back, I don’t get the meaning of this. How can a section be
‘executable’ without being ‘allocatable’ in ELF?
Anitha
From: avr-gcc-list-bounces+anitha.boyapati=atmel@nongnu.org
Hi Rieker,
I think 'AVR Freaks' might be a better place to know more about device
troubleshooting.
HTH
Anitha
-Original Message-
From: avr-gcc-list-bounces+anitha.boyapati=atmel@nongnu.org
[mailto:avr-gcc-list-bounces+anitha.boyapati=atmel@nongnu.org] On
Behalf Of Rieker Flaik
Hi Erik,
Anitha, a quick test shows that this linker script addition provides
cumulative overflow detection (using binutils 2.18.0):
. = ASSERT (_etext + SIZEOF (.data) = 32K , Error: .text + .data
collectively overflow the text region. ) ;
(Or use ADDR (.text) + SIZEOF (.text) in place of
-Original Message-
From: avr-gcc-list-bounces+anitha.boyapati=atmel@nongnu.org
[mailto:avr-gcc-list-bounces+anitha.boyapati=atmel@nongnu.org] On
Behalf Of Erik Christiansen
Sent: Monday, February 14, 2011 7:59 PM
To: avr-gcc-list@nongnu.org
Subject: Re: [avr-gcc-list] strange
Hello Max,
In the linker script be sure the MEMORY command is:
MEMORY
{
text (rx) : ORIGIN = 0, LENGTH = 32K
data (rw!x) : ORIGIN = 0x800060, LENGTH = 2K
eeprom (rw!x) : ORIGIN = 0x81, LENGTH = 1K
}
text region is as long as 32KB, as atmega32's flash.
If you compile you will
Hello Bob,
Firstly, I don't think an avr-gcc bug is filed on this...
Back in June I said that I would do that, then Eric came up with a
patch so I did not.
I can open one if it helps.
Yes. I think it helps as I think there are more places in avr-gcc which
requires changes. It can atleast
(Somehow I could not send the message!)
-Original Message-
From: Boyapati, Anitha
Sent: Saturday, February 12, 2011 11:26 PM
To: avr-gcc-list@nongnu.org
Subject: [avr-ggc-list]RE: [bug #29774] prologue/epiloguestack
pointermanipulation not interrupt safe in XMega
Hello Bob,
Firstly
Hello Bob,
Firstly, I don't think an avr-gcc bug is filed on this...
Back in June I said that I would do that, then Eric came up with a
patch so I did not.
I can open one if it helps.
Yes. I think it helps as I think there are more places in avr-gcc which
requires changes. It can atleast
Hello Bob,
This is quite an interesting bug!! (Sorry to say that, but it is) Took me
sometime to understand all the previous conversations.
Firstly, I don't think an avr-gcc bug is filed on this... If you happen to know
the avr-gcc bug number, please let me know.
Secondly, can you the gcc
-Original Message-
From: avr-gcc-list-bounces+anitha.boyapati=atmel@nongnu.org
[mailto:avr-gcc-list-bounces+anitha.boyapati=atmel@nongnu.org] On
Behalf Of Paul Thomas
Sent: Friday, February 04, 2011 3:04 AM
To: avr-gcc-list@nongnu.org
Subject: [avr-gcc-list] xmega support in
-Original Message-
From: avr-gcc-list-bounces+anitha.boyapati=atmel@nongnu.org
[mailto:avr-gcc-list-bounces+anitha.boyapati=atmel@nongnu.org] On
Behalf Of larry barello
Sent: Thursday, December 30, 2010 2:31 AM
To: tomd...@speakeasy.org; avr-gcc-list@nongnu.org
Subject: RE:
Hello,
I am doing a preliminary analysis for supporting call frame debugging
information in avr. (gcc bug 17994). When I build, I am facing ICE in
dwarf2out. Obviously the code goes to gcc_unreachable() in the big function:
dwarf2out_frame_debug_expr(). Before I proceed further, I would like
This is quite an old change date 2 years ago.
http://gcc.gnu.org/viewcvs?view=revisionrevision=136238
Please check the diff done in avr.c file in revision 136238 w.r.t to its
previous revision.
http://gcc.gnu.org/viewcvs/trunk/gcc/config/avr/avr.c?r1=135953r2=136238pathrev=136238
Interrupt
Hi Anatoly,
On the other hand in main function interrupt may be enabled and writing
to
SP soul be de done in safe way.
Thanks for the quick response.
Regards
Anitha
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
Try the files and simulator craeted as part of WINAVR
http://winavr.cvs.sourceforge.net/viewvc/winavr/avrtest/
Edit some paths to match your filespace.
Thanks Andy. I think avrtest worked much better. I managed to get 42K passes!
=== gcc Summary ===
# of expected passes
-Original Message-
From: Weddington, Eric
Sent: Saturday, October 24, 2009 5:32 AM
To: Boyapati, Anitha; avr-gcc-list@nongnu.org
Subject: RE: [avr-gcc-list] AVR atmega128 GCC 4.3.3 Testresults
comparision
make check RUNTESTFLAGS=--target_board=atmega128-sim
I see lot
Hello,
I am running GCC DejaGNU testsuite for target AVR atmega128 on VM (Virtual box
with Windows XP as host OS and Kubuntu as guest OS). Basically, the testing is
carried out using avr-gdb which attaches to simulavr using target remote
protocol (I can attach the expect scripts and
46 matches
Mail list logo
