Re: [RFC] Change PCH "checksum"

[Mark Wielaard]

On Fri, 2019-02-22 at 12:29 +0100, Richard Biener wrote:
> +struct build_id_note {
> +/* The NHdr.  */
> +uint32_t namesz;
> +uint32_t descsz;
> +uint32_t type;
> +
> +char name[4]; /* Note name for build-id is "GNU\0" */
> +unsigned char build_id[16];
> +};

Note that build-ids can be of different sizes depending on the style
used to generate them, you get the correct size by looking at the
descsz.

> +static int
> +get_build_id_1 (struct dl_phdr_info *info, size_t, void *data)
> +{
> +  for (unsigned i = 0; i < info->dlpi_phnum; ++i)
> +{
> +  if (info->dlpi_phdr[i].p_type != PT_NOTE)
> + continue;
> +  build_id_note *note
> + = (build_id_note *)(info->dlpi_addr + info->dlpi_phdr[i].p_vaddr);
> +  ptrdiff_t size = info->dlpi_phdr[i].p_filesz;
> +  while (size >= (ptrdiff_t)sizeof (build_id_note))
> + {
> +   if (note->type == NT_GNU_BUILD_ID
> +   && note->namesz == 4
> +   && note->descsz >= 16)
> + {
> +   memcpy (data, note->build_id, 16);
> +   return 1;
> + }
> +   size_t offset = (sizeof (uint32_t) * 3
> ++ ALIGN(note->namesz, 4)
> ++ ALIGN(note->descsz, 4));
> +   note = (build_id_note *)((char *)note + offset);
> +   size -= offset;

Since the introduction of GNU Property notes this is (sadly) no longer
the correct way to iterate through ELF notes. The padding of names and
desc  might now depend on the alignment of the PT_NOTE segment.
https://sourceware.org/ml/binutils/2018-09/msg00359.html

Cheers,

Mark

Re: AVR __progmem__ variable reading

[Łukasz Kostka]

> Wiadomość napisana przez David Brown  w dniu 
> 25.02.2019, o godz. 08:43:
> 
> 
> On 24/02/2019 18:29, Łukasz Kostka wrote:
>>> Wiadomość napisana przez David Brown  w dniu 
>>> 24.02.2019, o godz. 14:58:
>>> 
>>> 
>>> 
>>> On 24/02/2019 14:47, Łukasz Kostka wrote:
> Wiadomość napisana przez David Brown  > w dniu 24.02.2019, o godz. 12:13:
> 
> 
> This sort of thing has been an issue for all sorts of small 
> microcontrollers, and all their compilers, since their inception.  It is 
> not solvable in an ideal way that gives maximal convenience to 
> programmers and still results in efficient code.  The only good solution 
> is to move away from such cpu designs - there are very few reasons for 
> choosing a core such as the AVR rather than an ARM, MIPS or RISC-V 
> alternative.  (You might choose the AVR device for its peripherals, or 
> pin package, or power usage - but not for its core.)
 Yes I know that AVR are old architecture.
 I will move sooner or later to RISC-V or ARM. In fact bought some board 
 from sparkfun.
 Does it mean that in newer cpu designs storing read only variables in 
 flash is easier than in AVR ?
>>> 
>>> Most 16-bit and 32-bit cpus have a single address space.  Since the same 
>>> instructions are used to access data whether it is in ram or flash (or, in 
>>> most cases, IO register areas), there is no longer any issue.
>>> 
>>> The AVR uses different instructions for accessing data from flash and from 
>>> ram, which is what causes the complications.
>> Thx for clarification
>> BTW. Do you know if any ARM cortex or RISC-V provide such instructions to 
>> access data in flash / rodata ?
> 
> No, neither ARM nor RISC-V has instructions to access data in flash or 
> read-only data - that is /precisely/ the point.  Such data is accessed 
> exactly like ram data and any other data, using the same instructions and 
> from the same single flat memory space.
Aha :-) So I just declare variable static const and voila. Well that is great. 
Another strong paint to migrate to newer platforms.

Re: AVR __progmem__ variable reading

[David Brown]

On 25/02/2019 18:09, Łukasz Kostka wrote:
> 
> 
>> Wiadomość napisana przez David Brown  w dniu 
>> 25.02.2019, o godz. 08:43:
>>
>>
>> On 24/02/2019 18:29, Łukasz Kostka wrote:
 Wiadomość napisana przez David Brown  w dniu 
 24.02.2019, o godz. 14:58:



 On 24/02/2019 14:47, Łukasz Kostka wrote:
>> Wiadomość napisana przez David Brown > > w dniu 24.02.2019, o godz. 12:13:
>>
>>
>> This sort of thing has been an issue for all sorts of small 
>> microcontrollers, and all their compilers, since their inception.  It is 
>> not solvable in an ideal way that gives maximal convenience to 
>> programmers and still results in efficient code.  The only good solution 
>> is to move away from such cpu designs - there are very few reasons for 
>> choosing a core such as the AVR rather than an ARM, MIPS or RISC-V 
>> alternative.  (You might choose the AVR device for its peripherals, or 
>> pin package, or power usage - but not for its core.)
> Yes I know that AVR are old architecture.
> I will move sooner or later to RISC-V or ARM. In fact bought some board 
> from sparkfun.
> Does it mean that in newer cpu designs storing read only variables in 
> flash is easier than in AVR ?

 Most 16-bit and 32-bit cpus have a single address space.  Since the same 
 instructions are used to access data whether it is in ram or flash (or, in 
 most cases, IO register areas), there is no longer any issue.

 The AVR uses different instructions for accessing data from flash and from 
 ram, which is what causes the complications.
>>> Thx for clarification
>>> BTW. Do you know if any ARM cortex or RISC-V provide such instructions to 
>>> access data in flash / rodata ?
>>
>> No, neither ARM nor RISC-V has instructions to access data in flash or 
>> read-only data - that is /precisely/ the point.  Such data is accessed 
>> exactly like ram data and any other data, using the same instructions and 
>> from the same single flat memory space.
> Aha :-) So I just declare variable static const and voila. Well that is 
> great. Another strong paint to migrate to newer platforms.
> 

Exactly, yes.  (Or you can use non-static const if that is more
appropriate.)

With the AVR, you can also use "const" like normal - but the data will
be allocated a space in ram and copied over from flash to ram at
startup.  That way it can be read like any other data, without special
consideration, address spaces, pgm_read_byte, etc.  But of course, it
takes up space in ram - so it is fine for small constants, but perhaps a
waste of valuable ram resources for tables or strings.

And remember that on any target, if you have "static const" data and the
compiler can figure out that the data can be used directly for
calculations, immediate data, etc., and no storage is necessary, then no
storage will be allocated (in ram, flash, or anywhere else).

Re: Question regarding constraint usage within inline asm

[Michael Matz]

Hi,

On Thu, 21 Feb 2019, Segher Boessenkool wrote:

> > That said, the "bug" in the case we're seeing, is that asmcons rewrote 
> > all of "input"'s pseudos, and it should be more careful to not create 
> > rtl with illegal constraint usage that LRA cannot fix up.  With the 
> > fix, operand %1 in the inline asm is no longer hard coded to r3 and it 
> > uses the pseudo instead, so everything is copacetic.
> 
> And that expand used one pseudo for everything in the asm is bad 
> already.

I'll contest that.  Asms aren't that special from an input-output 
perspective and shouldn't be (makes for clearer and hence more correct 
code).  hardregs are special, OTOH.  expand doesn't (and shouldn't) do 
anything special for

   _2 = _1 + _1;

(i.e. it should assign the same pseudo to both inputs), from which follows 
that it shouldn't do anything special for

  asm("" : "=r" (_2) : "r" (_1), "w" (_1))

either.  The picture changes if _1 corresponds to a local decl with an 
associated hard reg; those don't get SSA names for a reason.  But I 
believe you're worrying about the common case of off-the-mill SSA 
names.

Anything that would cause breakage by such behaviour of expand is to be 
rectified by LRA/reload, not by hackery within expand.

> If two inputs have identical constraints, sure, then it makes 
> sense perhaps (but does it really safe anything anyway?)  Otherwise it 
> does not.

The thing is that it doesn't make sense to do anything special for asms in 
this respect, and it actually goes against the natural flow of things to 
do anything special.  Think about how you would retain the necessary 
copies if we were to implement the restriction you want.  Say, given

  asm ("" :: "r" (_1), "w" (_1));

and you want to enforce that both inputs get different pseudo; so you 
start generating

  (set (p60) (p59))   // assume _1 sits in pseudo 59
  (set (p61) (p59))
  (asm (...) ("r" p60) ("w" p61))

How do you propose the (right now) obviously useless copies between two 
perfectly normal pseudos to be retained during the course of RTL 
optimization to not immediately end up with:

  (asm (...) ("r" p59) ("w" p59))

?  Sure, you could implement more of the hackery that looks at users of 
the copies and disable forwarding if they feed asms, but what for?  You 
can't remove LRA/reload code that deals with this situation anyway, so why 
not let it deal with it?  Another way to look at this is that LRA makes it 
so that those copies are implicitely always there but are only 
materialized if necessary because of conflicting constraints.

(Again the picture completely changes if one of the decls, and hence 
associated pseudo, has a hard-reg; and for that we do deal mostly 
correctly with it, except for the asmcons problem discussed here).


Ciao,
Michael.

Re: AVR __progmem__ variable reading

[Łukasz Kostka]

> Wiadomość napisana przez David Brown  w dniu 
> 25.02.2019, o godz. 18:19:
> 
> On 25/02/2019 18:09, Łukasz Kostka wrote:
>> 
>> 
>>> Wiadomość napisana przez David Brown  w dniu 
>>> 25.02.2019, o godz. 08:43:
>>> 
>>> 
>>> On 24/02/2019 18:29, Łukasz Kostka wrote:
> Wiadomość napisana przez David Brown  w dniu 
> 24.02.2019, o godz. 14:58:
> 
> 
> 
> On 24/02/2019 14:47, Łukasz Kostka wrote:
>>> Wiadomość napisana przez David Brown >> > w dniu 24.02.2019, o godz. 12:13:
>>> 
>>> 
>>> This sort of thing has been an issue for all sorts of small 
>>> microcontrollers, and all their compilers, since their inception.  It 
>>> is not solvable in an ideal way that gives maximal convenience to 
>>> programmers and still results in efficient code.  The only good 
>>> solution is to move away from such cpu designs - there are very few 
>>> reasons for choosing a core such as the AVR rather than an ARM, MIPS or 
>>> RISC-V alternative.  (You might choose the AVR device for its 
>>> peripherals, or pin package, or power usage - but not for its core.)
>> Yes I know that AVR are old architecture.
>> I will move sooner or later to RISC-V or ARM. In fact bought some board 
>> from sparkfun.
>> Does it mean that in newer cpu designs storing read only variables in 
>> flash is easier than in AVR ?
> 
> Most 16-bit and 32-bit cpus have a single address space.  Since the same 
> instructions are used to access data whether it is in ram or flash (or, 
> in most cases, IO register areas), there is no longer any issue.
> 
> The AVR uses different instructions for accessing data from flash and 
> from ram, which is what causes the complications.
 Thx for clarification
 BTW. Do you know if any ARM cortex or RISC-V provide such instructions to 
 access data in flash / rodata ?
>>> 
>>> No, neither ARM nor RISC-V has instructions to access data in flash or 
>>> read-only data - that is /precisely/ the point.  Such data is accessed 
>>> exactly like ram data and any other data, using the same instructions and 
>>> from the same single flat memory space.
>> Aha :-) So I just declare variable static const and voila. Well that is 
>> great. Another strong paint to migrate to newer platforms.
>> 
> 
> Exactly, yes.  (Or you can use non-static const if that is more
> appropriate.)
> 
> With the AVR, you can also use "const" like normal - but the data will
> be allocated a space in ram and copied over from flash to ram at
> startup.  That way it can be read like any other data, without special
> consideration, address spaces, pgm_read_byte, etc.  But of course, it
> takes up space in ram - so it is fine for small constants, but perhaps a
> waste of valuable ram resources for tables or strings.
> 
> And remember that on any target, if you have "static const" data and the
> compiler can figure out that the data can be used directly for
> calculations, immediate data, etc., and no storage is necessary, then no
> storage will be allocated (in ram, flash, or anywhere else).
Thx again for clarification.

Re: AVR __progmem__ variable reading

[SenthilKumar.Selvaraj]

David Brown writes:

> On 25/02/2019 18:09, Łukasz Kostka wrote:
>> 
>> 
>>> Wiadomość napisana przez David Brown  w dniu 
>>> 25.02.2019, o godz. 08:43:
>>>
>>>
>>> On 24/02/2019 18:29, Łukasz Kostka wrote:
> Wiadomość napisana przez David Brown  w dniu 
> 24.02.2019, o godz. 14:58:
>
>
>
> On 24/02/2019 14:47, Łukasz Kostka wrote:
>>> Wiadomość napisana przez David Brown >> > w dniu 24.02.2019, o godz. 12:13:
>>>
>>>
>>> This sort of thing has been an issue for all sorts of small 
>>> microcontrollers, and all their compilers, since their inception.  It 
>>> is not solvable in an ideal way that gives maximal convenience to 
>>> programmers and still results in efficient code.  The only good 
>>> solution is to move away from such cpu designs - there are very few 
>>> reasons for choosing a core such as the AVR rather than an ARM, MIPS or 
>>> RISC-V alternative.  (You might choose the AVR device for its 
>>> peripherals, or pin package, or power usage - but not for its core.)
>> Yes I know that AVR are old architecture.
>> I will move sooner or later to RISC-V or ARM. In fact bought some board 
>> from sparkfun.
>> Does it mean that in newer cpu designs storing read only variables in 
>> flash is easier than in AVR ?
>
> Most 16-bit and 32-bit cpus have a single address space.  Since the same 
> instructions are used to access data whether it is in ram or flash (or, 
> in most cases, IO register areas), there is no longer any issue.
>
> The AVR uses different instructions for accessing data from flash and 
> from ram, which is what causes the complications.
 Thx for clarification
 BTW. Do you know if any ARM cortex or RISC-V provide such instructions to 
 access data in flash / rodata ?
>>>
>>> No, neither ARM nor RISC-V has instructions to access data in flash or 
>>> read-only data - that is /precisely/ the point.  Such data is accessed 
>>> exactly like ram data and any other data, using the same instructions and 
>>> from the same single flat memory space.
>> Aha :-) So I just declare variable static const and voila. Well that is 
>> great. Another strong paint to migrate to newer platforms.
>> 
>
> Exactly, yes.  (Or you can use non-static const if that is more
> appropriate.)
>
> With the AVR, you can also use "const" like normal - but the data will
> be allocated a space in ram and copied over from flash to ram at
> startup.  That way it can be read like any other data, without special
> consideration, address spaces, pgm_read_byte, etc.  But of course, it
> takes up space in ram - so it is fine for small constants, but perhaps a
> waste of valuable ram resources for tables or strings.

FWIW, chips with the "avrxmega3" ISA, like the attiny416,
attiny816, attiny3216 (and almost all new devices releaesd in the last
year or so) have flash mapped into the data address space. For those
devices, rodata remains in flash and the compiler emits data address
space instructions (LDS, LD..) for reads - no wasted RAM.

Regards
Senthil