Repeating section names in ELF binary
Hello, we are working on a project to make module debugging for the Linux kernel easier. We want to improve it in such a way that gdb automatically loads the symbols of modules. However, we are facing the following difficulties: gdb needs to know all section of the ELF files. We were told that gcc may produce multiple sections in an ELF binary with the same name (some of them might be empty). This has been observed on the PARISC architecture, however, we were told that it might happen on any architecture when using -ffunction-sections. We could not reproduce it in our tests on x86_64. So, our question is the following: does gcc under any architecture (besides PARISC) produce an ELF binary where the sections' names are not unique? Thanks!
Re: Repeating section names in ELF binary
On Sat, Apr 6, 2013 at 3:09 AM, Sebastian Wankerl wrote: > > we are working on a project to make module debugging for the Linux > kernel easier. We want to improve it in such a way that gdb > automatically loads the symbols of modules. However, we are facing the > following difficulties: gdb needs to know all section of the ELF files. > We were told that gcc may produce multiple sections in an ELF binary > with the same name (some of them might be empty). This has been observed > on the PARISC architecture, however, we were told that it might happen > on any architecture when using -ffunction-sections. We could not > reproduce it in our tests on x86_64. So, our question is the following: > does gcc under any architecture (besides PARISC) produce an ELF binary > where the sections' names are not unique? Why do you care? To care whether there are duplicate section names suggests that you are doing something wrong. That said, since you mention Linux kernel modules I'm guessing that you are looking at objects linked using -r. Offhand I can't think of a way to get duplicate section names after linking with -r, because the linker will tend to agglomerate sections with the same name. Ian
Can -mno-big-switch be removed from the PA port?
Hello,
I'm trying to get to a point where the CFG is useable even in the
delay-slot filling pass (dbr_schedule) and I'm currently stuck on a
transformation that the PA port does if -mno-big-switch is in effect.
With !TARGET_BIG_SWITCH, the PA port "explodes" a JUMP_TABLE_DATA to
real code, i.e. actual jumps (see the example at the end of this
mail).
The problem is that the new code with the explicit jumps is not inside
a basic block: It's substituted in the place where the JUMP_TABLE_DATA
rtx was. It is important to maintain this exact order of the code
because the casesi0 jump_insn is not a jump to a label but a jump to
an absolute distance measured from the CODE_LABEL before the
JUMP_TABLE_DATA, so the length of the explicit jump_insns must be
constant.
I have no idea how to maintain the CFG and "freeze" the exploded code
to protect it from being changed by following passes. Having the code
not inside basic blocks breaks verify_flow_info, and hides the insns
that fill the delay slots from the DF machinery and from the analysis
code in sched-deps.c.
Exploding the jump tables only happens with !TARGET_BIG_SWITCH. The
reason to explode the jump table is because it makes the delay slots
of the explicit jump_insns visible to the dbr_schedule pass.
But TARGET_BIG_SWITCH has been the default since GCC 4.0, see
http://gcc.gnu.org/ml/gcc-patches/2004-02/msg02401.html
Are there any reasons against removing !TARGET_BIG_SWITCH support? It
would really help if this code can go away...
Ciao!
Steven
from the .expand dump:
(note 317 8 9 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
(jump_insn 9 317 10 4 (set (pc)
(mem:SI (plus:SI (mult:SI (reg:SI 97)
(const_int 4 [0x4]))
(label_ref 10)) [0 S4 A32])) t.c:15 -1
(nil)
-> 10)
(code_label 10 9 11 4 "" [1 uses])
(jump_table_data 11 10 12 (addr_vec:DI [
(label_ref:SI 13)
(label_ref:SI 16)
(label_ref:SI 19)
(label_ref:SI 22)
(label_ref:SI 25)
(label_ref:SI 28)
(label_ref:SI 31)
...
(label_ref:SI 307)
(label_ref:SI 310)
]))
(barrier 12 11 13)
After the machine dependent reorg patch:
(note 317 8 9 [bb 3] NOTE_INSN_BASIC_BLOCK)
(jump_insn 9 317 10 (set (pc)
(mem:SI (plus:SI (mult:SI (reg:SI 26 %r26 [97])
(const_int 4 [0x4]))
(label_ref 10)) [0 S4 A32])) t.c:15 193 {casesi0}
(expr_list:REG_DEAD (reg:SI 26 %r26 [97])
(nil))
-> 10)
(code_label 10 9 328 4 "" [1 uses])
(insn 328 10 329 (const_int 1 [0x1]) 212 {begin_brtab}
(nil))
(code_label 329 328 330 104 "" [1 uses])
(jump_insn 330 329 331 (parallel [
(set (pc)
(label_ref 13))
(const_int 0 [0])
]) 192 {short_jump}
(nil)
-> 13)
(barrier 331 330 332)
(code_label 332 331 333 105 "" [1 uses])
(jump_insn 333 332 334 (parallel [
(set (pc)
(label_ref 16))
(const_int 0 [0])
]) 192 {short_jump}
(nil)
-> 16)
(barrier 334 333 335)
...
(barrier 625 624 626)
(code_label 626 625 627 203 "" [1 uses])
(jump_insn 627 626 629 (parallel [
(set (pc)
(label_ref 310))
(const_int 0 [0])
]) 192 {short_jump}
(nil)
-> 310)
(insn 629 627 628 (const_int 2 [0x2]) 213 {end_brtab}
(nil))
Re: Can -mno-big-switch be removed from the PA port?
On 6-Apr-13, at 12:25 PM, Steven Bosscher wrote: Are there any reasons against removing !TARGET_BIG_SWITCH support? It would really help if this code can go away... Yes, branch distances are limited to what can be encoded in a 17-bit pc relative offset. Large code will break with !TARGET_BIG_SWITCH. I think the answer is to move the jump table from the text to read- only data. This would require another instruction or two to load the label for the table. The HP compiler does this. Although this is unclear, I suspect there are situations where what we do now can cause TLB thrash. This occurs on machines with shared instruction and data TLBs. Would this help? Dave -- John David Anglin dave.ang...@bell.net
Re: Compiling gcc473-RC-20130404 with -Wextra
On Sat, Apr 6, 2013 at 6:51 AM, Дилян Палаузов wrote: > Hello, > > I compile gcc473-RC-20130404 with > > CFLAGS='-pipe -O3 -march=native -Wl,-S -Wl,--hash-style=gnu -Wl,-O1 > -Wl,-z,relro -flto -Wall -Wextra' > ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var > --enable-threads=posix --enable-nls --enable-interpreter --with-system-zlib > --enable-libgcj-multifile --enable-languages=all --enable-targets=all > --with-system-libunwind --without-x > > make 2> stderr > > using gcc472 as compiler. According to my understandings, there shall be no > warnings, when gcc is compiled, but there are some (see below). > > I suggest to release GCC, when compiling it with -Wextra using the previous > most recent compiler does not produce any warnings. -Wextra has many controversial warnings, some of them get fixed in future releases. I don't think your proposal is a starter. -- Gaby
Re: Can -mno-big-switch be removed from the PA port?
On Sat, Apr 6, 2013 at 7:09 PM, John David Anglin wrote: > On 6-Apr-13, at 12:25 PM, Steven Bosscher wrote: > >> Are there any reasons against removing !TARGET_BIG_SWITCH support? It >> would really help if this code can go away... > > > Yes, branch distances are limited to what can be encoded in a > 17-bit pc relative offset. > Large code will break with !TARGET_BIG_SWITCH. That would be a reason why !TARGET_BIG_SWITCH *can* go away ;-) TARGET_BIG_SWITCH i.e. -mbig-switch is the default for all hppa targets since your 2004 patch. !TARGET_BIG_SWITCH i.e. -mno-big-switch is not tested in the test suite and probably not used by anymore. And it's the -mno-big-switch that's causing me headaches. Ciao! Steven
Re: Can -mno-big-switch be removed from the PA port?
On 6-Apr-13, at 3:16 PM, Steven Bosscher wrote: On Sat, Apr 6, 2013 at 7:09 PM, John David Anglin wrote: On 6-Apr-13, at 12:25 PM, Steven Bosscher wrote: Are there any reasons against removing !TARGET_BIG_SWITCH support? It would really help if this code can go away... Yes, branch distances are limited to what can be encoded in a 17-bit pc relative offset. Large code will break with !TARGET_BIG_SWITCH. That would be a reason why !TARGET_BIG_SWITCH *can* go away ;-) TARGET_BIG_SWITCH i.e. -mbig-switch is the default for all hppa targets since your 2004 patch. !TARGET_BIG_SWITCH i.e. -mno-big-switch is not tested in the test suite and probably not used by anymore. And it's the -mno-big-switch that's causing me headaches. I was mixed up on which option was causing grief. "-mno-big-switch" can go. Probably, nobody will notice... Dave -- John David Anglin dave.ang...@bell.net
gcc-4.7-20130406 is now available
Snapshot gcc-4.7-20130406 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20130406/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_7-branch revision 197545 You'll find: gcc-4.7-20130406.tar.bz2 Complete GCC MD5=f25c0aa9bb428999382a55b01a4e6c72 SHA1=5488ae88954e8e9aa06a256cd9a7452427ab12ab Diffs from 4.7-20130330 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.7 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.
