Re: GCC 4.2/4.3 Status Report (2006-10-17)
I am also planning to incorporate many Ada improvements (such as improved support for Ada 2005) and fixes that I was holding while the 4.2 branch was not created, I assume this is not an issue (and very localized to the gcc/ada/ directory of course). Arno
GTY(()) & GCC garbage collector
Dear All, I finally solved (with help from Sebastian Pop) my problems about GTY(()) etc... I added some blurb on it in the Wiki http://gcc.gnu.org/wiki/Memory_management Please correct if I am wrong Regards -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet aliases: basiletunesorg = bstarynknerimnet 8, rue de la Faïencerie, 92340 Bourg La Reine, France
Re: Modifying ARM code generator for elimination of 8bit writes - need help
On Mon, Oct 02, 2006 at 12:42:04PM +0200, Wolfgang Mües wrote: > Now it's time to give a big "thank you" to all persons involved, > ecpecially Rask Ingemann Lambertsen with his invaluable help. > > As I started this project, I feared that I would never succeed, and > now ... the modified compiler is used about 3 month now, and DSLINUX > with this crude modification is working fine with 36 MBytes RAM > available, and has a good future now. I'm glad to hear that it works. I have a few improvements I'd like to make, but for the next few months, my focus will be on getting my 16-bit x86 into GCC 4.3. You can take a look at the relout_outqi pattern. It uses two scratch registers: One for the address and one as a scratch register for swpb. It is worth investigating if you can safely trash the input operand, since the reason we have an output reload is because a pseudo register got a stack slot instead of a hard register. I.e. reload shouldn't expect the value in operand 1 to be preserved for use in a later insn. But I think a reload expert should comment on this. -- Rask Ingemann Lambertsen
Raw socket...
Hi, I am writting an example program, to create a raw socket on Fedora Core Linx. When I create socket, my linux sustem crashes. I need to powerdown the system. I am running this program as super user to create raw socket. Following line crashes.. rawSocket = socket(AF_INET, SOCK_RAW, IPPROTO_RAW); Any insight on this will be great help. Thanks & regards, Raj __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Raw socket...
Basavaraj Hiremath <[EMAIL PROTECTED]> writes: > I am writting an example program, to create a raw > socket on Fedora Core Linx. > > When I create socket, my linux sustem crashes. I > need > to powerdown the system. I am running this program > as > super user to create raw socket. > > Following line crashes.. > rawSocket = socket(AF_INET, SOCK_RAW, IPPROTO_RAW); Wrong mailing list. This mailing list is for gcc development. Please try a Linux programming list. Ian
Re: C++ name mangling for local entities
On 19/10/2006, at 9:17 PM, Mark Mitchell wrote: Geoffrey Keating wrote: For GCC, I've found it necessary to have a way to name local (that is, namespace-scope 'static') variables and functions which allows more than one such symbol to be present and have distinct mangled names. With my GCC hat on, I don't think this is desirable. For ELF at least, there's nothing that prevents us using the same name for multiple local symbols (since "ld -r" does it). For the sake of both LTO and IMA, we should add a feature to the assembler like: .asm_alias x = y that says references to "x" are emitted as references to a new "y", distinct from all other "y" references. That would obviate the need for multiple statics with the same name, since in the case that you want to do this (IMA) you could instead emit them using whatever name was convenient for generating the assembly file, and then let the assembler emit a symbol with the correct name. That would help to meet the objective that the output from IMA and/or LTO looks like the output from "ld -r", modulo optimization. I think it would be great if you would help implement that, which would then make extending the C++ ABI change unnecessary. On Darwin, all the DWARF information in .o files is matched by name¹ with symbols in the executable, so this won't work. There is no DWARF information in .o files produced with 'ld -r', just an index referring to the original .o files, so it's not a problem there. ¹: That is, the name in the .o file symbol table referenced by a reloc for, say, a DW_AT_pc_begin entry is matched with a STAB in the executable. Matching does not look at the DW_AT_name in the DWARF information. Now, with my C++ ABI hat on, and assuming that the idea above is intractable, then: (a) as you note, this is out-of-scope for the C+ + ABI, if we confine ourselves to pure ISO C++, but (b) if the other ABI stakeholders don't mind, I don't see any reason not to consider reserving a chunk of the namespace. What I currently have implemented is ::= ::= ::= ::=// new ::= L _// new It's distinguishable from the other possibilies, because operator- name starts with a lowercase letter, ctor-dtor-name starts with 'C' or 'D', and source-name starts with a digit. There is no semantic meaning attached to the number in a local-source-name, it exists only to keep different names distinct (so it is not like in a local-name). That's true, but is there a reason not to use the discriminator encoding? There might well be an ambiguity, but I didn't see at first blush. If so, that would seem most natural to me. You mean ::= Z ? Although I think it can't conflict with an actual , you have to at least get to the end of and see the '_' in the discriminator before you can be sure which one you're seeing; you could have _ZZ4func_0v // a local-source-name _ZZ4funcvE1i // a local-name _ZZZ4func_0vE1i // a local-name containing a local-source-name _ZZN5spaceZ4func_0EvE1i // valid _ZZN5spaceZ4func_0vE1i // invalid You can't use a local-name directly (and avoid needing local-source- name at all) because - it doesn't apply to static variables, so you'd have to invent something there anyway, and - you would be unable to mangle some symbols until you'd seen every translation unit, because a function declared 'static' in one might have the same name as a function declared 'inline' in another and they might, for example, both contain static variables of the same name; the 'inline' function must get the ABI-defined discriminator values. Certainly ::= L will work and is more consistent, so consider the proposal amended to have that. smime.p7s Description: S/MIME cryptographic signature
The Linux binutils 2.17.50.0.6 is released
This is the beta release of binutils 2.17.50.0.6 for Linux, which is
based on binutils 2006 1020 in CVS on sources.redhat.com plus various
changes. It is purely for Linux.
Starting from the 2.17.50.0.6 release, the default output section LMA
(load memory address) has changed for allocatable sections from being
equal to VMA (virtual memory address), to keeping the difference between
LMA and VMA the same as the previous output section in the same region.
For
.data.init_task : { *(.data.init_task) }
LMA of .data.init_task section is equal to its VMA with the old linker.
With the new linker, it depends on the previous output section. You
can use
.data.init_task : AT (ADDR(.data.init_task)) { *(.data.init_task) }
to ensure that LMA of .data.init_task section is always equal to its
VMA. The linker script in the older 2.6 x86-64 kernel depends on the
old behavior. You can add AT (ADDR(section)) to force LMA of
.data.init_task section equal to its VMA. It will work with both old
and new linkers. The x86-64 kernel linker script in kernel 2.6.13 and
above is OK.
The new x86_64 assembler no longer accepts
monitor %eax,%ecx,%edx
You should use
monitor %rax,%ecx,%edx
or
monitor
which works with both old and new x86_64 assemblers. They should
generate the same opcode.
The new i386/x86_64 assemblers no longer accept instructions for moving
between a segment register and a 32bit memory location, i.e.,
movl (%eax),%ds
movl %ds,(%eax)
To generate instructions for moving between a segment register and a
16bit memory location without the 16bit operand size prefix, 0x66,
mov (%eax),%ds
mov %ds,(%eax)
should be used. It will work with both new and old assemblers. The
assembler starting from 2.16.90.0.1 will also support
movw (%eax),%ds
movw %ds,(%eax)
without the 0x66 prefix. Patches for 2.4 and 2.6 Linux kernels are
available at
http://www.kernel.org/pub/linux/devel/binutils/linux-2.4-seg-4.patch
http://www.kernel.org/pub/linux/devel/binutils/linux-2.6-seg-5.patch
The ia64 assembler is now defaulted to tune for Itanium 2 processors.
To build a kernel for Itanium 1 processors, you will need to add
ifeq ($(CONFIG_ITANIUM),y)
CFLAGS += -Wa,-mtune=itanium1
AFLAGS += -Wa,-mtune=itanium1
endif
to arch/ia64/Makefile in your kernel source tree.
Please report any bugs related to binutils 2.17.50.0.6 to [EMAIL PROTECTED]
and
http://www.sourceware.org/bugzilla/
If you don't use
# rpmbuild -ta binutils-xx.xx.xx.xx.xx.tar.bz2
to compile the Linux binutils, please read patches/README in source
tree to apply Linux patches if there are any.
Changes from binutils 2.17.50.0.5:
1. Update from binutils 2006 1020.
2. Don't make debug symbol dynamic. PR 3290.
3. Don't page align empty SHF_ALLOC sections, which leads to very large
executables. PR 3314.
4. Use a different section index for section relative symbols against
removed empty sections.
5. Fix a few ELF EH frame handling bugs.
6. Don't ignore relocation overflow on branches to undefweaks for
x86-64. PR 3283.
7. Rename MNI to SSSE3.
8. Properly append symbol list for --dynamic-list.
lists.
9. Various ARM ELF fixes.
10. Correct 64bit library search path for Linux/x86 linker with 64bit
support.
11. Fix ELF linker to copy OS/PROC specific flags from input section to
output section.
12. Fix DW_FORM_ref_addr handling in linker dwarf reader. PR 3191.
13. Fix ELF indirect symbol handling. PR 3351.
14. Fix PT_GNU_RELRO segment handling for SHF_TLS sections. Don't add
PT_GNU_RELRO segment when there are no relro sections. PR 3281.
15. Various MIPS ELF fixes.
16. Various Sparc ELF fixes.
17. Various Xtensa ELF fixes.
Changes from binutils 2.17.50.0.4:
1. Update from binutils 2006 0927.
2. Fix linker regressions of section address and section relative symbol
with empty output section. PR 3223/3267.
3. Fix "strings -T". PR 3257.
4. Fix "objcopy --only-keep-debug". PR 3262.
5. Add Intell iwmmxt2 support.
6. Fix an x86 disassembler bug. PR 3100.
Changes from binutils 2.17.50.0.3:
1. Update from binutils 2006 0924.
2. Speed up linker on .o files with debug info on linkonce sections.
PR 3111.
3. Added x86-64 PE support.
4. Fix objcopy/strip on .o files with section groups. PR 3181.
5. Fix "ld --hash-style=gnu" crash with gcc 3.4.6. PR 3197.
6. Fix "strip --strip-debug" on .o files generated with
"gcc -feliminate-dwarf2-dups". PR 3186.
7. Fix "ld -r" on .o files generated with "gcc -feliminate-dwarf2-dups".
PR 3249.
8. Add --dynamic-list to linker to make global symbols dynamic.
9. Fix magic number for EFI ia64. PR 3171.
10. Remove PT_NULL segment for "ld -z relro". PR 3015.
11. Make objcopy to perserve the file formats in archive elements.
PR 3110.
12. Optimize x86-64 assembler and fix disassembler for
"add32 mov xx,$eax". PR 3235.
13. Improve linker diagnostics. PR 3107.
14. Fix "ld --sort-section name". PR 3009.
15. Updated an x86 disassembler bug. PR 3000.
16. Various updates for PPC
Re: C++ name mangling for local entities
we should add a feature to the assembler like: .asm_alias x = y that says references to "x" are emitted as references to a new "y", distinct from all other "y" references. On Darwin, all the DWARF information in .o files is matched by name¹ with symbols in the executable, so this won't work. In that case, on Darwin, the assembler could leave the name "x" as "x", so that all the names in the object file were unique. Since this is only for local symbols, there's no ABI impact, as you mentioned. Then, we'd have better behavior on ELF platforms and would not have to make any change to the C++ ABI. You could use your suggested encoding in GCC as "x", but it would only show up in object files on systems that don't support multiple local symbols with the same name. Now, with my C++ ABI hat on That's true, but is there a reason not to use the discriminator encoding? You mean ::= Z ? Yes, that's what I meant. I think that would be best, partly because it avoids having to reserve "L", but: ::= L will work and is more consistent, so consider the proposal amended to have that. also seems OK, assuming that we need to do this at all. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
gcc-4.1-20061020 is now available
Snapshot gcc-4.1-20061020 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20061020/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch revision 117913 You'll find: gcc-4.1-20061020.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20061020.tar.bz2 C front end and core compiler gcc-ada-4.1-20061020.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20061020.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20061020.tar.bz2 C++ front end and runtime gcc-java-4.1-20061020.tar.bz2 Java front end and runtime gcc-objc-4.1-20061020.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20061020.tar.bz2The GCC testsuite Diffs from 4.1-20061013 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
GCC 4.2 branch created; mainline open in Stage 1
I have created the GCC 4.2 branch. The branch is open for
regression-fixes only, as is customary for release branches. I believe
I have completed the steps in branching.html with two exceptions:
1. I have not created a mainline snapshot manually. I don't quite
understand how to do that, and if the only issue is incorrect "previous
snapshot" references in the generated mail, it doesn't really seem worth
the trouble. If there's some more grievous problem, please let me know,
and I will try to fix it tomorrow.
2. I have not regenerated {gcc,cpplib}.pot, or sent them off to the
translation project. Joseph, would you please do that, at your convenience?
The mainline is now in Stage 1.
Thanks to those who helped fix PRs to meet the 4.2 branch criteria!
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
