Que tal um Rol??
* [image: No title] [image: No title] [http://d-click.hitsmart.com.br/u/34094/181297/17413229/1894050_0/7a606/?url=https%3A%2F%2Fwww.bodyglove.com.br%2Floja%2F] [image: ] [http://d-click.hitsmart.com.br/u/34094/181297/17413229/1894051_0/7a606/?url=https%3A%2F%2Fproduto.mercadolivre.com.br%2FMLB-1136022093-skate-de-praia-bamboo-long-board-body-glove-brasil-madeira-_JM%3Fquantity%3D1] CNPJ: 14.899.364/0001-60 | Rio de Janeiro | RJ | Brasil | SAC: s...@bodyglove.com.br Para deixar de receber e-mails clique aqui [http://d-click.hitsmart.com.br/u/34094/181297/17413229/1894052_0/7a606/?url=https%3A%2F%2Fwww.becommerce.com.br]. Se voc? n?o deseja receber e-mails promocionais, cancele o recebimento. [http://d-click.hitsmart.com.br/u/34094/181297/17413229/1894053_0/7a606/?url=https%3A%2F%2Flogin.becommerce.com.br%2FcancelaEmailMarketing%3FmeliId%3D%40meliId%40%26emailCliente%3D%40emailCliente%40]
Re: [RFC] Change PCH "checksum"
On Mon, 25 Feb 2019, Mark Wielaard wrote:
> 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.
Yeah, as said it's currently a hack...
> > +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
Ick, that's of course worse ;) So it's not entirely clear what
the correct thing to do is - from how I read the mail at the above
link only iff sh_align of the note section is exactly 8 the above
ALIGN would use 8 byte alignment and else 4 is correct (independent
on sh_align). Or can I assume sh_align of the note section is
"correct" for all existing binaries? Note also the eventual difference
between note sections and note program headers which have another,
possibly different(?) alignment? It's of course "easy" to replace
4 above by info->dlpi_phdr[i].p_align (but the align field differs
in width between elfclass 32 and 64 ... :/).
So - is merely changing the re-alignment from 4 to
info->dlpi_phdr[i].p_align "correct"?
Richard.
> Cheers,
>
> Mark
>
>
--
Richard Biener
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB
21284 (AG Nuernberg)
Re: [RFC] Change PCH "checksum"
On Tue, 2019-02-26 at 09:33 +0100, Richard Biener wrote: > On Mon, 25 Feb 2019, Mark Wielaard wrote: > > 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 > > Ick, that's of course worse ;) So it's not entirely clear what > the correct thing to do is - from how I read the mail at the above > link only iff sh_align of the note section is exactly 8 the above > ALIGN would use 8 byte alignment and else 4 is correct (independent > on sh_align). Or can I assume sh_align of the note section is > "correct" for all existing binaries? Note also the eventual > difference > between note sections and note program headers which have another, > possibly different(?) alignment? It's of course "easy" to replace > 4 above by info->dlpi_phdr[i].p_align (but the align field differs > in width between elfclass 32 and 64 ... :/). > > So - is merely changing the re-alignment from 4 to > info->dlpi_phdr[i].p_align "correct"? Yes, you will have multiple note segments one that combines the 4 padded notes and one that combines the 8 padded notes. Some tools put 0 or 1 in the align field, so you might want to use (completely untested): align = (p_align <= 4) ? 4 : 8; offset += ALIGN ((ALIGN (sizeof (uint32_t) * 3 + namesz, align) + descsz), align); Cheers, Mark
Re: [RFC] Change PCH "checksum"
On Tue, 26 Feb 2019, Mark Wielaard wrote: > On Tue, 2019-02-26 at 09:33 +0100, Richard Biener wrote: > > On Mon, 25 Feb 2019, Mark Wielaard wrote: > > > 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 > > > > Ick, that's of course worse ;) So it's not entirely clear what > > the correct thing to do is - from how I read the mail at the above > > link only iff sh_align of the note section is exactly 8 the above > > ALIGN would use 8 byte alignment and else 4 is correct (independent > > on sh_align). Or can I assume sh_align of the note section is > > "correct" for all existing binaries? Note also the eventual > > difference > > between note sections and note program headers which have another, > > possibly different(?) alignment? It's of course "easy" to replace > > 4 above by info->dlpi_phdr[i].p_align (but the align field differs > > in width between elfclass 32 and 64 ... :/). > > > > So - is merely changing the re-alignment from 4 to > > info->dlpi_phdr[i].p_align "correct"? > > Yes, you will have multiple note segments one that combines the 4 > padded notes and one that combines the 8 padded notes. > Some tools put 0 or 1 in the align field, so you might want to use > (completely untested): > align = (p_align <= 4) ? 4 : 8; > offset += ALIGN ((ALIGN (sizeof (uint32_t) * 3 + namesz, align) > + descsz), align); That would mean when p_align == 8 the note name isn't 8-aligned but just 4-aligned? That is, sizeof (Elf*_Nhdr) == 12, and the name starts right after that instead of being aligned according to p_align? That sounds odd... So p_align only applies to the descriptor? Richard. > Cheers, > > Mark > > -- Richard Biener SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
Re: [RFC] Change PCH "checksum"
On Tue, 26 Feb 2019, Richard Biener wrote:
> On Tue, 26 Feb 2019, Mark Wielaard wrote:
>
> > On Tue, 2019-02-26 at 09:33 +0100, Richard Biener wrote:
> > > On Mon, 25 Feb 2019, Mark Wielaard wrote:
> > > > 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
> > >
> > > Ick, that's of course worse ;) So it's not entirely clear what
> > > the correct thing to do is - from how I read the mail at the above
> > > link only iff sh_align of the note section is exactly 8 the above
> > > ALIGN would use 8 byte alignment and else 4 is correct (independent
> > > on sh_align). Or can I assume sh_align of the note section is
> > > "correct" for all existing binaries? Note also the eventual
> > > difference
> > > between note sections and note program headers which have another,
> > > possibly different(?) alignment? It's of course "easy" to replace
> > > 4 above by info->dlpi_phdr[i].p_align (but the align field differs
> > > in width between elfclass 32 and 64 ... :/).
> > >
> > > So - is merely changing the re-alignment from 4 to
> > > info->dlpi_phdr[i].p_align "correct"?
> >
> > Yes, you will have multiple note segments one that combines the 4
> > padded notes and one that combines the 8 padded notes.
> > Some tools put 0 or 1 in the align field, so you might want to use
> > (completely untested):
> > align = (p_align <= 4) ? 4 : 8;
> > offset += ALIGN ((ALIGN (sizeof (uint32_t) * 3 + namesz, align)
> > + descsz), align);
>
> That would mean when p_align == 8 the note name isn't 8-aligned
> but just 4-aligned? That is, sizeof (Elf*_Nhdr) == 12, and the
> name starts right after that instead of being aligned according
> to p_align? That sounds odd... So p_align only applies to
> the descriptor?
So rather like the following (simplified for _GNU_SOURCE since
link.h includes elf.h there). I've not yet come along binaries
with different p_align so I can't really test it.
#if _GNU_SOURCE
#include
#define ALIGN(val, align) (((val) + (align) - 1) & ~((align) - 1))
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;
ElfW(Nhdr) *nhdr
= (ElfW(Nhdr) *)(info->dlpi_addr + info->dlpi_phdr[i].p_vaddr);
ptrdiff_t size = info->dlpi_phdr[i].p_filesz;
ptrdiff_t align = info->dlpi_phdr[i].p_align;
if (align < 4)
align = 4;
while (size >= (ptrdiff_t)sizeof (ElfW(Nhdr)))
{
if (nhdr->n_type == NT_GNU_BUILD_ID
&& nhdr->n_namesz == 4
&& strncmp ((char *)nhdr
+ ALIGN (sizeof (ElfW(Nhdr)), align),
"GNU", 4) == 0
&& nhdr->n_descsz >= 16)
{
memcpy (data,
(char *)nhdr
+ ALIGN (sizeof (ElfW(Nhdr)), align)
+ ALIGN (nhdr->n_namesz, align), 16);
return 1;
}
size_t offset = (ALIGN (sizeof (ElfW(Nhdr)), align)
+ ALIGN(nhdr->n_namesz, align)
+ ALIGN(nhdr->n_descsz, align));
nhdr = (ElfW(Nhdr) *)((char *)nhdr + offset);
size -= offset;
}
}
return 0;
}
Re: [RFC] Change PCH "checksum"
Hi,
On Tue, 26 Feb 2019, Richard Biener wrote:
> get_build_id_1 (struct dl_phdr_info *info, size_t, void *data)
> {
Isn't this all a bit silly? We could simply encode the svn revision, or
maybe even just some random bytes generated once in stage1 at build time
as "checksum" and be done with. In the latter case PCHs will then not
work across different compiler builds, but so what?
Ciao,
Michael.
Re: [RFC] Change PCH "checksum"
On Tue, 26 Feb 2019, Michael Matz wrote:
> Hi,
>
> On Tue, 26 Feb 2019, Richard Biener wrote:
>
> > get_build_id_1 (struct dl_phdr_info *info, size_t, void *data)
> > {
>
> Isn't this all a bit silly? We could simply encode the svn revision, or
> maybe even just some random bytes generated once in stage1 at build time
> as "checksum" and be done with. In the latter case PCHs will then not
> work across different compiler builds, but so what?
Yes, a random number would work for PCH purposes but of course not
for reproducible builds. Somehow even compile-options are relevant
though so I'm not really sure how volatile the PCH format is.
That is, whether for example checksumming sources would work.
But yeah, I considered a --with-pch-checksum=XYZ to make this
configurable (where we could for example checksum the rpm
changes - iff PCHs of two different builds - say, one with checking
enabled and one with checking disabled - really interoperate).
Still, using the build-id looks so "obvious" ...
Richard.
Re: [RFC] Change PCH "checksum"
On Tue, 2019-02-26 at 15:36 +0100, Richard Biener wrote: > On Tue, 26 Feb 2019, Mark Wielaard wrote: > > > On Tue, 2019-02-26 at 09:33 +0100, Richard Biener wrote: > > > On Mon, 25 Feb 2019, Mark Wielaard wrote: > > > > 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 > > > > > > Ick, that's of course worse ;) So it's not entirely clear what > > > the correct thing to do is - from how I read the mail at the > > > above > > > link only iff sh_align of the note section is exactly 8 the above > > > ALIGN would use 8 byte alignment and else 4 is correct > > > (independent > > > on sh_align). Or can I assume sh_align of the note section is > > > "correct" for all existing binaries? Note also the eventual > > > difference > > > between note sections and note program headers which have > > > another, > > > possibly different(?) alignment? It's of course "easy" to > > > replace > > > 4 above by info->dlpi_phdr[i].p_align (but the align field > > > differs > > > in width between elfclass 32 and 64 ... :/). > > > > > > So - is merely changing the re-alignment from 4 to > > > info->dlpi_phdr[i].p_align "correct"? > > > > Yes, you will have multiple note segments one that combines the 4 > > padded notes and one that combines the 8 padded notes. > > Some tools put 0 or 1 in the align field, so you might want to use > > (completely untested): > > align = (p_align <= 4) ? 4 : 8; > > offset += ALIGN ((ALIGN (sizeof (uint32_t) * 3 + namesz, align) > > + descsz), align); > > That would mean when p_align == 8 the note name isn't 8-aligned > but just 4-aligned? That is, sizeof (Elf*_Nhdr) == 12, and the > name starts right after that instead of being aligned according > to p_align? That sounds odd... So p_align only applies to > the descriptor? Yes, it is that odd. There are 3 kinds of ELF notes. The traditional ones as used by GNU and Solaris, which use 4 byte words for everything whether in ELFCLASS32 or ELFCLASS64 and which are 4 byte aligned themselves. The gabi ones, which are similar for ELFCLASS32 but for ELFCLASS64 all words are 8 bytes and 8 bytes aligned themselves (as used by HPUX). And the new style GNU Property notes, only used in ELFCLASS64, which use 4 byte words for the first 3 fields, immediately followed by the name bytes, padded so that desc is 8 bytes aligned and the note as a whole is 8 byte aligned. Cheers, Mark
Re: [RFC] Change PCH "checksum"
On Tue, 26 Feb 2019, Mark Wielaard wrote: > On Tue, 2019-02-26 at 15:36 +0100, Richard Biener wrote: > > On Tue, 26 Feb 2019, Mark Wielaard wrote: > > > > > On Tue, 2019-02-26 at 09:33 +0100, Richard Biener wrote: > > > > On Mon, 25 Feb 2019, Mark Wielaard wrote: > > > > > 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 > > > > > > > > Ick, that's of course worse ;) So it's not entirely clear what > > > > the correct thing to do is - from how I read the mail at the > > > > above > > > > link only iff sh_align of the note section is exactly 8 the above > > > > ALIGN would use 8 byte alignment and else 4 is correct > > > > (independent > > > > on sh_align). Or can I assume sh_align of the note section is > > > > "correct" for all existing binaries? Note also the eventual > > > > difference > > > > between note sections and note program headers which have > > > > another, > > > > possibly different(?) alignment? It's of course "easy" to > > > > replace > > > > 4 above by info->dlpi_phdr[i].p_align (but the align field > > > > differs > > > > in width between elfclass 32 and 64 ... :/). > > > > > > > > So - is merely changing the re-alignment from 4 to > > > > info->dlpi_phdr[i].p_align "correct"? > > > > > > Yes, you will have multiple note segments one that combines the 4 > > > padded notes and one that combines the 8 padded notes. > > > Some tools put 0 or 1 in the align field, so you might want to use > > > (completely untested): > > > align = (p_align <= 4) ? 4 : 8; > > > offset += ALIGN ((ALIGN (sizeof (uint32_t) * 3 + namesz, align) > > > + descsz), align); > > > > That would mean when p_align == 8 the note name isn't 8-aligned > > but just 4-aligned? That is, sizeof (Elf*_Nhdr) == 12, and the > > name starts right after that instead of being aligned according > > to p_align? That sounds odd... So p_align only applies to > > the descriptor? > > Yes, it is that odd. There are 3 kinds of ELF notes. > > The traditional ones as used by GNU and Solaris, which use 4 byte words > for everything whether in ELFCLASS32 or ELFCLASS64 and which are 4 byte > aligned themselves. > > The gabi ones, which are similar for ELFCLASS32 but for ELFCLASS64 all > words are 8 bytes and 8 bytes aligned themselves (as used by HPUX). > > And the new style GNU Property notes, only used in ELFCLASS64, which > use 4 byte words for the first 3 fields, immediately followed by the > name bytes, padded so that desc is 8 bytes aligned and the note as a > whole is 8 byte aligned. I wonder how to distinguish the latter two - does one really need to test the size of ElfW(Nhdr).n_namesz for example? Why was the GNU Property one chosen this way?! Is the first case (traditional GNU note) with p_align == 8 invalid? That is, is testing p_align really the correct way to determine how the individual parts are aligned? I guess not. So - how do I identify a GNU Property note vs. a traditional note vs. a gabi one? Why was the third one added?! (I guess I asked that already...) Richard. > Cheers, > > Mark > > -- Richard Biener SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
Re: [RFC] Change PCH "checksum"
On Tue, 2019-02-26 at 18:13 +0100, Richard Biener wrote: > > > That would mean when p_align == 8 the note name isn't 8-aligned > > > but just 4-aligned? That is, sizeof (Elf*_Nhdr) == 12, and the > > > name starts right after that instead of being aligned according > > > to p_align? That sounds odd... So p_align only applies to > > > the descriptor? > > > > Yes, it is that odd. There are 3 kinds of ELF notes. > > > > The traditional ones as used by GNU and Solaris, which use 4 byte > > words > > for everything whether in ELFCLASS32 or ELFCLASS64 and which are 4 > > byte > > aligned themselves. > > > > The gabi ones, which are similar for ELFCLASS32 but for ELFCLASS64 > > all > > words are 8 bytes and 8 bytes aligned themselves (as used by HPUX). > > > > And the new style GNU Property notes, only used in ELFCLASS64, > > which > > use 4 byte words for the first 3 fields, immediately followed by > > the > > name bytes, padded so that desc is 8 bytes aligned and the note as > > a > > whole is 8 byte aligned. > > I wonder how to distinguish the latter two - does one really need > to test the size of ElfW(Nhdr).n_namesz for example? I think the second one is only used on HPUX. Everything else uses the 4 byte words variant. I have only encountered the traditional note types and the new GNU Properties notes (on Fedora, I don't believe any other distro has, yet?, adopted them). > Why was the GNU Property one chosen this way?! All I can do is point you at the "consensus" document: https://sourceware.org/ml/binutils/2018-09/msg00282.html and the replies to that. > Is the first case (traditional > GNU note) with p_align == 8 invalid? Yes, I believe so. > That is, is testing p_align > really the correct way to determine how the individual parts are > aligned? I guess not. I do think that is the only way. If the PT_NOTE segment or SHT_NOTE segment has an alignment of 8 then it is a GNU Properties note with the new layout (at least on GNU systems). Cary did propose some additional constraints which might be helpful: https://sourceware.org/ml/binutils/2018-09/msg00359.html > So - how do I identify a GNU Property note vs. a traditional > note vs. a gabi one? > > Why was the third one added?! (I guess I asked that already...) Yeah... See above. Cheers, Mark
Results for 8.3.0 (GCC) testsuite on x86_64-w64-mingw32.
Test results here: https://gcc.gnu.org/ml/gcc-testresults/2019-02/msg03095.html Complete logs can be found here: https://cloud.emrich-ebersheim.de/index.php/s/g9D245XdCW6GD5W signature.asc Description: OpenPGP digital signature
