[uClinux-dev] SSHD in MicroBlaze: BINFMT_FLAT: relocoutsideprogram
ndprasad at gmail.com
Tue Jan 31 17:05:47 EST 2006
Actually this was the output (mb-objdump -t sshd.gdb > sshd.dump) for
the variable that caused the problem.
001558d0 l .bss 00000004 options
0014e210 g O .bss 00001eec options
The first one is for the static variable (possibly from a library) and
the second one is for the global variable defined in sshd.c and used
as extern in other ssh files. It didn't add any extension for the
static variable from the library.
The strange part is i try to test is standalone by 3 files, first one
declaring a variable static, second file declaring another variable of
the same name and third one extern for the same name. It did work
correctly and loaded properly (but it still didn't rename the static
So i thing, elf2flt gets confused for the sshd somehow. Not sure why.
On 1/31/06, Gavin Lambert <gavinl at compacsort.com> wrote:
> Quoth Jamie Lokier [jamie at shareable.org]:
> > GCC marks the symbol as static, instead. In nm's output, it
> > shows as the difference between "T" and "t", or "D" and "d",
> > etc. Isn't that standard for all ELF compilers?
> Possibly, but I'm fairly new to Linux and ELF. I'm familiar with
> several Windows compilers though, and invariably they cope with it by
> munging the name of the static symbol (similar to C++ name mangling).
> > If elf2flt is ignoring the static flag on symbols, that's a
> > bug in elf2flt.
> That's my suspicion. At least that there's a bug in there somewhere,
> anyway. Mind you, I might be using an old version of elf2flt -- I'm
> just using the one that came with the m68k-elf-gcc 3.4.0 compiler
> > Other than source symbols, the compiler also generates lots
> > of conflicting static symbols with names like ".L1", ".L2"
> > etc. Even if you rename static variables in the source code,
> > there are still lots of conflicting ".Lnnn" static symbols in
> > the final link. How is that those aren't a problem, and yet
> > symbols named from source variables are?
> It could be the other way around -- note that in my example, there was
> only one static symbol and two common references (it's C, so the fact
> that one of them was declared "extern" is irrelevant, unlike C++). It's
> entirely possible that elf2flt *does* keep static symbols separate, but
> is mistakenly mapping the common symbol on top of one of the statics,
> rather than the static on top of the common. from my example you can't
> tell the difference.
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> This message was resent by uclinux-dev at uclinux.org
More information about the uClinux-dev