Hi Jim,
That becomes a bit harder when there are many many items:
https://git.zx2c4.com/WireGuard/tree/src/crypto/zinc/selftest/chacha20poly1305.h#n87
Here I'd like to use compound literals to avoid wasting space, as
several members are variably sized. Unfortunately I can't do that per
https://g
On Fri, Sep 14, 2018 at 7:44 AM Jason A. Donenfeld wrote:
> Assuming this is an array of a huge amount of
> chacha20poly1305_testvec, I'm not sure if there's a syntax for me to
> define the symbol inline with the declarations. Any ideas?
Don't do it inline.
u8[] __stuffdata key_value = ...
...
.
Hi Jim,
On Thu, Sep 13, 2018 at 10:39 PM Jim Wilson wrote:
> The
> compound literal could have an address, but we don't have a way to
> attach attributes to compound literals.
Thanks for the confirmation of the problem.
> Since your testcase already has a symbol in the right section, you could
On 09/10/2018 10:46 PM, Jason A. Donenfeld wrote:
Hello,
I'd like to have a compound literal exist inside a certain linker
section. However, it doesn't appear to work as I'd like:
#define __stuffdata __attribute__((__section__("stuff")))
const u8 works[] __stuffdata = { 0x1, 0x2, 0x3, 0x4 };
co
Hello,
I'd like to have a compound literal exist inside a certain linker
section. However, it doesn't appear to work as I'd like:
#define __stuffdata __attribute__((__section__("stuff")))
const u8 works[] __stuffdata = { 0x1, 0x2, 0x3, 0x4 };
const u8 *breaks = (const u8[] __stuffdata){ 0x1, 0x2,
My mistake here.
I have not used the section attribute myself much and was looking at gcc
code
just passed the right handside of the .section to the attribute string.
# Stub function for foovf (float)
.section.mips16.fn.foovf,"ax",@progbits
.align2
.set
I tried to report a bug against llvm for not properly handling the
section attribute but they claim that it's not the intention for gcc to
work this way.
I reported it as an X86 problem because it's more generally
understandable to people but actually the problem occurs when mips16
Hello all,
For a gcc port i need to add new section. This new section has both
the variations i.e initialized and uninitialized say .sbss and .sdata
After going through the internals this is what i understood
1. Only one section attribute is need. Depending on whether the
variable is initialized
On Fri, Jun 10, 2005 at 10:50:01AM -0400, DJ Delorie wrote:
> typedef int __attribute__((section("foo"))) FOOINT;
>
> FOOINT a;
>
> Would it make sense to allow this sort of thing?
No more than it would make sense to have
typedef static int FOOINT;
IMO.
r~
On Fri, 10 Jun 2005, DJ Delorie wrote:
> What about this scenario?
>
> typedef int __attribute__((section("foo"))) FOOINT;
>
> FOOINT a;
>
> Would it make sense to allow this sort of thing? Would it be feasible
> to implement?
It might make sense to define "section" as applying to the type -
> The various exceptions of the form "if an attribute is applied to the type
> of a decl which can only apply to a decl, then apply it to the decl" are
> there because they represent forms used by existing code.
What about this scenario?
typedef int __attribute__((section("foo"))) FOOINT;
FOO
> most code and GCC documentation uses the less clear do-what-I-mean
> positions instead.
Ok, that's kinda what I figured. Thanks!
On Thu, 9 Jun 2005, DJ Delorie wrote:
>
> > "section" attributes are presently storage-class-like (similar to
> > "static") and only work on declarations.
>
> Ok, I see that we set the "apply to decl" bit for "section". I guess
> the question is - why? Would it be more consistent to keep track
> "section" attributes are presently storage-class-like (similar to
> "static") and only work on declarations.
Ok, I see that we set the "apply to decl" bit for "section". I guess
the question is - why? Would it be more consistent to keep track of
where it is given, and complain if it is applie
On Thu, 9 Jun 2005, DJ Delorie wrote:
>
> Consider:
>
> int __attribute__((section("foo"))) *var1;
> int * __attribute__((section("foo"))) var2;
>
> var2 is itself in section foo, and points to an int.
>
> Isn't var1 a pointer to something in section foo, and not itself in
> foo? GCC instead
Consider:
int __attribute__((section("foo"))) *var1;
int * __attribute__((section("foo"))) var2;
var2 is itself in section foo, and points to an int.
Isn't var1 a pointer to something in section foo, and not itself in
foo? GCC instead treats var1 like var2.
I couldn't figure out a suitable se
16 matches
Mail list logo
