Robert,
There is some difference, though: you can't count on such variables to be
initialised to zero.
JW
- Original Message ---
Schwichtenberg, Knut wrote:
Robert,
there is no difference in handling. So create your special section and put
the variables into it as you
I simply require a way to fix absolutely this jump table in memory.
Whether I write it in C or assembler seems to me to be irrelevant, as is
using an array of pointer to functions, because I still have the problem
of fixing these at absolute addresses.
If anyone knows a way to do this, I would
Since it understands the concept of a string as a constant,
it stores the string constant in flash and then copies it into the stack
frame (your first example).
Unfortunately, much worse than that.
The constant initialiser is stored in initialised .data. I.e. it eats FLASH
(as the .data
-specific backend, to reduce the overhead when using
initialised char-short-long. That's IMHO the place where a bit more work might
bring benefit.
The string initialiser *might* be a different issue, I see that.
Jan Waclawek
-Original Message-
Note that this behaviour is only
Parthasaradhi Nayani wrote:
I have a structure prclkp of size 32 bytes. When I define
struct prclkp XFLASH PLULOC1[1023]; No error is reported, whereas
struct prclkp XFLASH PLULOC1[1024]; generates an error - size of array too
large
You've probably reached a built-in limit in gcc. It
So, it appears to be limit of avr-gcc specifically.
Sure, it depends from sizeof(int).
Hummm, for me, the relationship is not quite sure. Can you explain that in
more detail, please?
Also, how does it imply the 32k limit on the initialiser and the lack of
warning when crossed?
Jan Waclawek
What are these bytes ?
Most probably these are initialiser values for initialised data.
Have a look into the .map file.
Jan Waclawek
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
What if instead of concetrating on this aliasing stuff you'd been already told
is not pertinent to avr-gcc, you finally start to examine the compiled code?
Or, post it.
JW
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
at
http://sourceware.org/binutils/docs/as/AVR_002dModifiers.html .
Thanks,
Jan Waclawek
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
By filing a bug report + patch
OK, so here we go again, Joerg.
First, I have no idea what the source of docs is (and I suspect it is in some
arcane language I would have trouble to work with anyway), where it is nor how
to prepare a patch the high esteemed gnu gurus would be akin to have a
If you don't know something, you can simply ask.
Okay.
What do pm() and gs() exactly do?
Btw., as a stop-gap measure, we added it to the avr-libc documentation
some time ago,
Could you please point me at it, I can't find it. I can find a mention of pm in
http://www.avrfreaks.net/index.php?name=PNphpBB2file=viewtopict=88210highlight=
JW
- Original Message ---
Where can I find out more about the discontinuation of WinAVR, please?
Graham.
- Original Message -
From: Weddington, Eric eric.wedding...@atmel.com
... not
to disjunct blocks.
I could not produce a simple testcase either, that's why I never reported it as
a bug.
Jan Waclawek
- Original Message ---
Dale wrote:
Hi @2010.06.09_14:42:49_+0200
Here's some code which shows this.
This code doesn't show
Yes, I can agree to that, but I don't know if I could fully characterize =
this as a bug.
Call it missed optimisation, then.
JW
- Original Message ---
But you agree that there's stack used and never returned for reuse?
=20
Yes, I can agree to that, but I don't know if I
are only a variation of this problem.
Still I wouldn't call this a bug, but that's just terminology. Let's just call
it a serious case of missed optimisation... :-)
Jan Waclawek
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http
For -O0 it works but upgrading to -Os makes the code non functional.
Indeed. The bug is present only with -O2, -O3 and -Os. -O0 and -O1 produces
stack frame of expected size...
I'd requalify it from missed optimisation to pessimisation, then... :-)
Jan
For those who believe in reporting bugs but don't visit avrfreaks.net,
http://www.avrfreaks.net/index.php?name=PNphpBB2file=viewtopicp=764532#764532
and above and below describes a yummy avr-ld bug related to --relax.
I know it is not a -gcc but binutils bug, but there is no avr-binutils
I know it is not a -gcc but binutils bug, but there is no avr-binutils
mailing list, so where would I post this.
No, but there is an official GNU Binutils website here:
http://www.gnu.org/software/binutils/
Which then has a link to a bug database where you fill out a bug report. Mark
the
, which yields the
expected result straightforwardly.
The keywords for further reading are integer promotion and usual arithmetic
conversions. Enjoy!
Jan Waclawek (The C-hater)
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
https://lists.nongnu.org
The jump targets in jump tables from switch_case/.ctors/.dtors are located in
lower flash and their entries are gs() and use relaxation magic to have jumping
pads generated.
AFAIK, the linker creates the trampoline/jumptable regardless of relaxation.
It's just that in certain (in practice most)
Confused. EIND could be set once at program start (e.g. to 1) and then left so
forever but avr-gcc requires EIND = 0?
No. You are mixing two independent answers.
I was just trying to hint a possible reason why the EI stuff was used at all, a
possible idea which might have been abandoned later.
So then the binutily have to be fixed. avr-gcc already relies on relaxation.
Are you saying that I can't use avr-gcc WITHOUT using -relax on avr-ld? Then
avr-gcc or directly avr-ld should at least warn about it, or even better, force
it.
Nevertheless, I don't think that's a good idea. The
of applications is not appropriate for
AVRs, and that the existing support for what we discuss here is sufficient.
The extended indirect stuff in gcc is already there for a couple of years.
Johann was just trying to clean it up, as it appears it is not needed at the
present state of affairs.
Jan
On Tue, 01 Nov 2011 02:06:07 +0100
Georg-Johann Lay a...@gjlay.de wrote:
Jan Waclawek schrieb:
You have a description of the bug? Just saw a rather lengthy chat
on freaks without pointing to the very problem...
Actually, the *pointers* were given several times, e.g. in
http
Johann,
thanks for explaining me how to submit a proper binutils bug. I will make use
of this information when I will have a bug I want to submit. This time, I
simply don't *want* to do it, and I also don't *want* to discuss further my
incentives to do or not to do so. Please don't imply I am
desire control over code size (and other aspects of the code too),
resort to assembler.
Jan Waclawek
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
my wording.
Jan Waclawek
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
As the first step, I'd recommend you to use a proven toolchain, like
WinAVR20100110. I don't say it does not have issues but at least it's not a
moving target. The notable two issues I am aware of are a library issue where
rjmp/rcall between functions fall too far apart, and a linker bug
Eric,
You should consider posting a minimal compilable example exhibiting the
problem, together with the command line switches etc. IMHO a better place to
do that is the avr-gcc section of avrfreaks' forum, rather than this list.
Please don't refer people to post code to AVR Freaks
In support of my arguments: [binutils]/ld/emutempl/avrelf.em contains a
specific handler for the case of stubs without relax:
static void
avr_elf_after_allocation (void)
{
if (!avr_no_stubs ! RELAXATION_ENABLED)
{
/* If relaxing, elf32_avr_size_stubs will be called from
, c, d, e, f);
printf(buffer);
}
compiles cleanly with avr-gcc (I tried both 4.2.2 and 4.7.1), even with
-std=c99.
My understanding of C99, 6.4.4.4, especially footnote 65, indicates, that the
\% sequence should result in compiler error.
Comments, please?
Jan Waclawek
const char c[] = \%;
compile
$ gcc file.c -std=c99 -fsyntax-only -pedantic-errors
file.c:1:18: unknown escape sequence '\%'
Tested with gcc 3.4 and gcc 4.7
My understanding of C99, 6.4.4.4, especially footnote 65, indicates,
that the \% sequence should result in compiler error.
Yes.
* PR13812 .trampolines location in linker script cause
internal error: out of range error
Dunno if this is still an issue resp. can be solved by a better
default linker script. Maybe a user-specific ld script is needed
here, too.
I'd say, this is not a bug, but abuse of
Starting with gcc 4.7.x, code
beyond 128 KB works right away provided you link with relaxation turned
on
Why would relaxation needed to be turned on?
That was because of PR 14058, which, I just realized, is already fixed
Ah, so.
I put up this question already twice, once on
http://sourceware.org/bugzilla/show_bug.cgi?id=13697
JW
- Original Message ---
It appears that a global SRAM uint8_t variable is placed at address
0x060 by avr-gcc versions 4.6.2 and 7.3.2.
___
AVR-GCC-list mailing list
Will avr-gcc use the right relocation when picking one function from the
array and calling it?
No, the relocation happened earlier, when the function pointer is getting
allocated during linking (i.e when the *value* of the function pointer is
getting determined). All the function pointers are
What is your avr-gcc version?
Jan
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
I googled a lot on this problem and this time tried to build the chain on
MacOSX (recipe below). I still hit the same problem. It simply won't build
code for the atmega2560 chip! :-(
The device list in gcc is in gcc/config/avr/avr-devices.c - can you see
atmega2560/2561 there?
JW
No, it's the other way round.
The FLASH is 16-bit wide, and the write-to-register logic around LPM
provides the byte-access exception.
Note how SPM works.
JW
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
the assembly listing is fresh each time I try.
Are you sure?
Try to add
static volatile uint8_t tmp2;
tmp2 = __x;
into clock_prescale_set() and check what happens with the asm listing.
JW
___
AVR-GCC-list mailing list
40 matches
Mail list logo
