Bill Westfield | 6 Feb 10:17
Picon

getting a short interrupt vector table, and PROGMEM vs .init0

In the case where a size-limited program is only using one interrupt
(this is "usbtiny" on an ATtiny2313, and avr-gcc 4.3.2), is there a
good way to get an "abbreviated" vector table instead of having
vectors for everything?

Assuming not, I figured I'd supress the normal gcc init files
(-nostdlib -nostartfiles) and create my own vector table:
extern void __vector_1(void);
void myinit(void) __attribute__((naked)) __attribute__ ((section (".init1")));
void myinit(void)
{
	asm volatile(
		"  rjmp main\n"
		"  rjmp __vector_1");
}

This seems to work OK, except that data defined with PROGMEM seems to
get put in my .elf file ahead of the .init1 code.
How come?  Any way around that?  I tired used a section .init9
attribute on the data instead of PROGMEM, but that doesn't seem to do
what I want either (leaves it in the data section...)

Thanks
Bill W

(short program that shows the problem attached.  Compile with "avr-gcc
-nostdlib -g -mmcu=attiny2313 -nostartfiles -o foo.elf foo.c"
(Yes, I know that this isn't a correct program as-is.  That's not the
question.))
(Continue reading)

Jan Waclawek | 6 Feb 10:38
Picon

Re: getting a short interrupt vector table, and PROGMEM vs .init0

That's because .initX sections *are* located after .progmem etc.

You want to have a look at the default linker scripts, and probably want to place your experimental stuff
into .vectors (which would probably be sort of obvious if you had a look at the original vectors table
source in gcrt1.S).

JW

----- Original Message ---------------
>In the case where a size-limited program is only using one interrupt
>(this is "usbtiny" on an ATtiny2313, and avr-gcc 4.3.2), is there a
>good way to get an "abbreviated" vector table instead of having
>vectors for everything?
>
>Assuming not, I figured I'd supress the normal gcc init files
>(-nostdlib -nostartfiles) and create my own vector table:
>extern void __vector_1(void);
>void myinit(void) __attribute__((naked)) __attribute__ ((section (".init1")));
>void myinit(void)
>{
>	asm volatile(
>		"  rjmp main\n"
>		"  rjmp __vector_1");
>}
>
>This seems to work OK, except that data defined with PROGMEM seems to
>get put in my .elf file ahead of the .init1 code.
>How come?  Any way around that?  I tired used a section .init9
>attribute on the data instead of PROGMEM, but that doesn't seem to do
>what I want either (leaves it in the data section...)
(Continue reading)

Joerg Wunsch | 6 Feb 11:04
Picon

Re: getting a short interrupt vector table, and PROGMEM vs .init0

As Bill Westfield wrote:

> In the case where a size-limited program is only using one interrupt
> (this is "usbtiny" on an ATtiny2313, and avr-gcc 4.3.2), is there a
> good way to get an "abbreviated" vector table instead of having
> vectors for everything?

I think the best way is to clone gcrt1.S into your project, and modify
it to your needs.  Make sure to spell the gcrt1.o file as the very
first object file in your (-nostartfiles) linker commandline.

The way Jan Waclawek described might work as well.
--

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
Georg-Johann Lay | 6 Feb 11:09
Picon
Favicon

Re: getting a short interrupt vector table

Bill Westfield schrieb:
> In the case where a size-limited program is only using one interrupt
> (this is "usbtiny" on an ATtiny2313, and avr-gcc 4.3.2), is there a
> good way to get an "abbreviated" vector table instead of having
> vectors for everything?

Jörg, would it help to make ./crt1/gcrt1.S:__vectors weak so that
user can provide his own vector table?

With 1.7.1 an error will occur if one tries to:

main.o: In function `__vectors':
main.c:(.vectors+0x0): multiple definition of
`__vectors'
./bin/../lib/gcc/avr/4.7.0/../../../../avr/lib/avr5/crtm168.o:../../../../../../source/avr-libc-1.7.1/crt1/gcrt1.S:52: 
first defined here
./bin/../lib/gcc/avr/4.7.0/../../../../avr/bin/ld.exe: Disabling 
relaxation: it will not work with multiple definitions
collect2.exe: error: ld returned 1 exit status

Johann
Joerg Wunsch | 6 Feb 11:15
Picon

Re: getting a short interrupt vector table

As Georg-Johann Lay wrote:

> Jörg, would it help to make ./crt1/gcrt1.S:__vectors weak so that
> user can provide his own vector table?

Don't know.  Someone could give that a try, and if it works, we change
the library definition.  That "someone" would hopefully also write up
a few lines for the documentation ;-), perhaps a FAQ entry: "How do I
build my own vector table?"
--

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
Weddington, Eric | 6 Feb 23:38

Re: getting a short interrupt vector table


> -----Original Message-----
> From: avr-libc-dev-bounces+eric.weddington=atmel.com <at> nongnu.org [mailto:avr-
> libc-dev-bounces+eric.weddington=atmel.com <at> nongnu.org] On Behalf Of Georg-
> Johann Lay
> Sent: Monday, February 06, 2012 3:10 AM
> To: Bill Westfield
> Cc: avr-libc-dev
> Subject: Re: [avr-libc-dev] getting a short interrupt vector table
> 
> Bill Westfield schrieb:
> > In the case where a size-limited program is only using one interrupt
> > (this is "usbtiny" on an ATtiny2313, and avr-gcc 4.3.2), is there a
> > good way to get an "abbreviated" vector table instead of having
> > vectors for everything?
> 
> Jörg, would it help to make ./crt1/gcrt1.S:__vectors weak so that
> user can provide his own vector table?
> 

Philosophically, I have no problem with it. As long as everything still works "out of the box" for normal
use, then I think that it's good that we allow the expert user to change things as they see fit.

Eric
Weddington, Eric | 6 Feb 23:38

Re: getting a short interrupt vector table


> -----Original Message-----
> From: avr-libc-dev-bounces+eric.weddington=atmel.com <at> nongnu.org [mailto:avr-
> libc-dev-bounces+eric.weddington=atmel.com <at> nongnu.org] On Behalf Of Joerg
> Wunsch
> Sent: Monday, February 06, 2012 3:16 AM
> To: avr-libc-dev <at> nongnu.org
> Subject: Re: [avr-libc-dev] getting a short interrupt vector table
> 
> As Georg-Johann Lay wrote:
> 
> > Jörg, would it help to make ./crt1/gcrt1.S:__vectors weak so that
> > user can provide his own vector table?
> 
> Don't know.  Someone could give that a try, and if it works, we change
> the library definition.  That "someone" would hopefully also write up
> a few lines for the documentation ;-), perhaps a FAQ entry: "How do I
> build my own vector table?"

Agreed.
Bill Westfield | 7 Feb 07:32
Picon

Re: getting a short interrupt vector table

> > would it help to make ./crt1/gcrt1.S:__vectors weak so that
> > user can provide his own vector table?
>
> Don't know.  Someone could give that a try,

Ok, I gave it a try.  Downloaded avr-libc1.6.4 (which is what I think
I have, but the object files don't match), and added a .weak for
__vectors:
	.section .vectors,"ax",@progbits
	.global	__vectors
	.func	__vectors
	.weak	__vectors
__vectors:

And then in my main.c did:

void __vectors(void) __attribute__((naked)) __attribute__ ((section
(".vectors")));
void __vectors(void)
{
	asm volatile(
		"  rjmp main\n"
		"  rjmp __vector_1");
}

This ended up resulting in including BOTH vector tables in the final
.elf file (but no complaint about the symbols.)  However, if I link
with "-nostartfiles" I seem to get the desired behavior.  (but
-nostartfiles doesn't normally suppress the vector table...)

(Continue reading)

Joerg Wunsch | 7 Feb 08:16
Picon

Re: getting a short interrupt vector table

As Bill Westfield wrote:

> However, if I link
> with "-nostartfiles" I seem to get the desired behavior.

That's what you are supposed to do, yes.

> How is the crtxxx file linked into the final target?  In order for the
> weak symbol to be overridden by my own definition, it would have to be
> treated as a library, and should come "after" my code, right?

No, the crt*.o file is explicitly linked as the very first object file
on the linker commandline.  You can watch this by adding -v to the
compiler commandline.

When thinking about it, it probably doesn't make sense to declare it
weak in the library, as there's no way around using -nostartfiles, but
then, the (non-weak) vector table from crt*.o isn't in the way anyway.

I don't know whether it would be possible to move the crt*.o file into
a library at all (*), at least historically, it's never been the case.
For example, on my host system, it looks like:

$ echo 'int main(void) { return 42; }' > foo.c
$ cc -v -o foo foo.c
Using built-in specs.
Target: i386-undermydesk-freebsd
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 4.2.1 20070719  [FreeBSD]
(Continue reading)

Bill Westfield | 7 Feb 10:43
Picon

Re: getting a short interrupt vector table, and PROGMEM vs .init0

> you probably want to place your experimental stuff into .vectors

Yes, that works...

I tend to leave "reading the source code" as a last resort.
Though perhaps it's better than looking at linker scripts.
Documentation, web search, forums, more obscure forums, source code
(hopefully with helpful pointers.)

Gmane