Thank you! I've known to how to create a *compat* PIC library, firstly using
`-fvisibility=hidden' in compile command line to hidden all symbols, then
using `objcopy -R' to remove .got section totally! However, assemble result is
just like this
call__i686.get_pc_thunk.bx
addl
yunfeng zhang writes:
> Sorry! I've made a mistake! But using LD_PRELOAD to force to reposition a
> variable/function from a module is violating software engineer. And the more
> important is, as the result, all user *all* pay the bill for this even they
> make sure they don't need the feature, s
On Nov 27, 2009, yunfeng zhang wrote:
> The rsult is also same, you go too far.
If the g in the main program didn't preempt the definition in the
library, then something is amiss in your system.
> Here data in 0x1000 and its follower have an *exact* map to foo.so in
> disk, you need review my c
Sorry! I've made a mistake! But using LD_PRELOAD to force to reposition a
variable/function from a module is violating software engineer. And the more
important is, as the result, all user *all* pay the bill for this even they
make sure they don't need the feature, such as, glibc itself.
On 11/26/2009 02:04 PM, yunfeng zhang wrote:
The result is the same
#include
extern int g __attribute__((visibility("hidden")));
int g;
int foo(int a, int b)
{
g = a + b;
printf("%x, %x",&g, foo);
return g;
}
load and call `foo' in the library, an outputting (with v
Yunfeng Zhang, please try this example.
elf.tar.gz
Description: GNU Zip compressed data
yunfeng zhang wrote:
> a.out
> f.map
> is it 5 + 3 = 4 + 4?
If you refuse to look at the source code that gcc generates, you will never
know what the difference is.
I cannot make that decision for you.
cheers,
DaveK
You can run a.out several times
24>>a5e0<<, 249>>41c<<
11>>15e0<<, 110>>41c<<
c7>>85e0<<, c77>>41c<<
8c>>35e0<<, 8c2>>41c<<
...
Now open f.map
g = 0x15e0, foo = 0x41c
is it 5 + 3 = 4 + 4?
2009/11/27 Dave Korn :
> yunfeng zhang wrote:
>
>> have an *exact* map to foo.so in disk
>
> This is wher
yunfeng zhang wrote:
> have an *exact* map to foo.so in disk
This is where your misunderstanding arises. Just as 5+3 can add up to the
same result as 4+4, so you cannot ignore that the final mapped addresses you
are seeing add up to the same result via different routes. Compile your
sources u
The rsult is also same, you go too far.
Code I want to show a fact in Linux, when a process load a library into memory,
such as 0x1000
foo.so 0x1000
ELF header
.text section
.data section
.bss section
...
Here data in 0x1000 and its follower have an *exact* map to foo.so in disk, you
need r
On Nov 26, 2009, yunfeng zhang wrote:
> The result is the same
But the code isn't. See how, with hidden, we use the fixed offset.
Now remove the hidden attribute, define g also in the main program, and
see what it prints.
--
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You
The result is the same
#include
extern int g __attribute__((visibility("hidden")));
int g;
int foo(int a, int b)
{
g = a + b;
printf("%x, %x", &g, foo);
return g;
}
load and call `foo' in the library, an outputting (with vdso) is
cc15bc, cc03fc
and open f.map
0x1
On 11/25/2009 06:24 PM, yunfeng zhang wrote:
It seems that original limitation isn't clear or sufficient
For a sample:
// f.c
int g;
void foo(void)
{
g = 1;
}
compile with `gcc -shared -fPIC -Wl,-soname,f.so,-Map,f.map -o f.so f.c'...
With -fPIC, the variable G may be overridden by a
It seems that original limitation isn't clear or sufficient
For a sample:
// f.c
int g;
void foo(void)
{
g = 1;
}
compile with `gcc -shared -fPIC -Wl,-soname,f.so,-Map,f.map -o f.so f.c',
according to f.map, offsetof(g - foo) in library is 0x1550 - 0x3cc = 0x1184,
however let's load the
On 11/23/2009 05:58 PM, yunfeng zhang wrote:
next:
pop %ebx //<< A.
...
movl new_offset(%ebx), %eax //<< B. load global variable foo to eax.
...
.global foo //<< C.
OK!, to ld, offsetof(C - A) is const...
Your premise is wrong right there. C-A is *not* a constant.
yunfeng zhang wrote:
> The idea I got is about removing .got section in ELF format totally.
>
> Before we go, let's see the limitation on the idea
> 1) It must be deployed on aligned segment model, such as Linux, which cs.start
> = ds.start.
> 2) Currently, I only know how to do on x86 ELF.
>
> H
The idea I got is about removing .got section in ELF format totally.
Before we go, let's see the limitation on the idea
1) It must be deployed on aligned segment model, such as Linux, which cs.start
= ds.start.
2) Currently, I only know how to do on x86 ELF.
Here is a typical sample in PIC model
17 matches
Mail list logo
