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
> >
> Did you get a reject message? If so, that should have caused you to
> stop and think a little...
>
I sent:
Date: Wed, 25 Nov 2009 02:53:21 -0800
From: "H.J. Lu"
To: gcc-patc...@gcc.gnu.org
Subject: PATCH: Remove trailing white spaces
User-Agent: Mutt/1.5.19 (2009-01-05)
Hi,
I am c
Snapshot gcc-4.5-20091126 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20091126/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
On 11/26/2009 08:18 AM, Michael Matz wrote:
How, for goodness sake, can pure trailing whitespace changes, which by
necessity you can't even _see_ in an editor (except if you activate modes
that explicitely show them e.g. in different color) clean up code? Have
you looked at the patch or fallout
Michael Matz wrote:
Hi,
On Wed, 25 Nov 2009, Basile STARYNKEVITCH wrote:
1. What to do in the immediate term with the repo. I've got no strong
opinions here.
I do understand most of the opinions, but I would rather prefer that we
don't revert the trailing whitespace patch. I definitely can
Michael Matz wrote:
> I Don't Want To Work Around useless unapproved mass changes.
Hey, nor do I. (In fact, I don't even like having to work around useful
approved mass changes, merging is always dull and tedious work. But I think
of it as just something that goes with the territory.)
> To a
On 11/25/09 16:51, Lu, Hongjiu wrote:
Sorry for that. I did send an email and though it was an obvious fix. I guess the
patch may be too big,> 400K with bz2.
Did you get a reject message? If so, that should have caused you to
stop and think a little...
Jeff
Hi,
On Wed, 25 Nov 2009, Basile STARYNKEVITCH wrote:
> > 1. What to do in the immediate term with the repo. I've got no strong
> > opinions here.
>
> I do understand most of the opinions, but I would rather prefer that we
> don't revert the trailing whitespace patch. I definitely can live wi
Hi,
On Wed, 25 Nov 2009, Richard Kenner wrote:
> > In my mind it's very simple: trailing whitespace poses exactly _no_
> > problem (except of being against the coding standard),
>
> It's against the coding standards for a very good reason, which is that it
> makes patching harder because you h
On 2009-11-26 10:12:39 +1100, Ben Elliston wrote:
> On Wed, 2009-11-25 at 15:17 -0500, Kaveh R. GHAZI wrote:
> > Finally, we have a process for reverting a patch. If anyone wants to
> > revert some part, it needs to be followed. Otherwise *that* would be
> > breaking the rules...
>
> Won't rever
On 2009-11-25 17:49:39 +0100, Richard Guenther wrote:
> On Wed, 25 Nov 2009, Richard Kenner wrote:
> > Why the latter? I agree with the problems this can cause, but if
> > they can't be fixed by removing it from the database, why revert
> > it? All things being equal, trailing blanks in fact aren't
Richard Guenther writes:
> Does svn rely on patch for merging
No, it uses an internal diff3 algorithm. You can make it use an
external diff3 program via the command line or the config file.
> and can it be taught to use -l?
The internal diff/merge will ignore whitespace if you use -x -w.
--
On Thu, Nov 26, 2009 at 9:56 AM, Paolo Bonzini wrote:
> On 11/26/2009 12:20 AM, Alexandre Oliva wrote:
>>
>> sed -i 's,[ \t]*$,,' probably won't work, if there are all-blanks lines
>> being left alone in the patch (so the rx will match the patch markers
>> too), but something slightly more elabora
Jonathan Wakely wrote:
> It's under discussion
That's certainly a good news. Anyway, I'll wait
with porting my framework to the newest GCC,
until this issue is settled, as:
a) "= default" works as I expect on gcc 4.5-20090604
and maybe it will still do in the future;
b) gcc 4.5-20091119 reports
On 11/26/2009 12:20 AM, Alexandre Oliva wrote:
sed -i 's,[ \t]*$,,' probably won't work, if there are all-blanks lines
being left alone in the patch (so the rx will match the patch markers
too), but something slightly more elaborate preserving a fixed number of
leading blanks dependng on the patc
2009/11/26 Jonathan Wakely:
>
> This still lets you use defaulted functions, but the base is not
> trivially copyable.
Oops, I meant the base is not a trivial class ... but then it can't be
anyway as you have a virtual function.
2009/11/26 Piotr Wyderski:
>
> Clean, simple and GCC used to happily accept that.
Only with the experimental C++0x mode, which is a moving target and
you shouldn't really complain if it changes.
> But now it is illegal because of 3 draft violations:
>
> Base() shall be public, but is not
> ~Base(
23 matches
Mail list logo
