This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Discussion about merging Go frontend
- From: Dave Korn <dave dot korn dot cygwin at gmail dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: Ian Lance Taylor <iant at google dot com>, Andi Kleen <andi at firstfloor dot org>, Andrew Pinski <pinskia at gmail dot com>, Mark Mitchell <mark at codesourcery dot com>, gcc at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- Date: Sat, 30 Oct 2010 09:16:21 +0100
- Subject: Re: Discussion about merging Go frontend
- References: <mcr7hh8qhb5.fsf@google.com> <4CC45302.9000702@gmail.com> <mcrhbgbyoef.fsf@google.com> <4CC59F1E.7040505@codesourcery.com> <mcrbp6ixhny.fsf@google.com> <AANLkTikEy7ER+CkQdWo0XHPoBORvbp8JZ226QFM68PZv@mail.gmail.com> <87pquy3yh5.fsf@basil.nowhere.org> <4CC60C5E.6050605@gmail.com> <mcr1v79bx8q.fsf@google.com> <4CCB656F.7030203@redhat.com>
On 30/10/2010 01:23, Richard Henderson wrote:
>> + if (!objfile_internal_read (objfile->descriptor,
>> + objfile->offset + eor->shoff + shdr_size,
>> + shdrs,
>> + shdr_size * (shnum - 1),
>> + &errmsg, err))
>
> Do we really want to keep re-reading section data for every section
> lookup we do? Can't we do this in objfile_open_read?
It should only be necessary to do one section lookup per object file anyway.
Keep extra data hanging around in memory in the backend just so that we can
write algorithmically inefficient code in the client? Seems like a bad
tradeoff to me!
>> + set_32 (hdr + offsetof (struct external_scnhdr, s_flags),
>> + (STYP_DATA | IMAGE_SCN_ALIGN_1BYTES | IMAGE_SCN_MEM_DISCARDABLE
>> + | IMAGE_SCN_MEM_SHARED | IMAGE_SCN_MEM_READ));
>
> You're not recording alignment in the coff object file?
It looks to me like he's recording an alignment of 1 byte.
> IMAGE_SCN_ALIGN_<N>BYTES, 1 <= N <= 8192, are all defined
> with a simple function in that nibble.
The line you quoted uses IMAGE_SCN_ALIGN_1BYTES. That's all we'll ever need
for LTO sections.
cheers,
DaveK