Dynamic linking with LD_PRELOAD - get it compiled

Hello group,

I'm currently working on a tool which generates code that can be
compiled with gcc to form a shared object. This shared object then can
be preloaded with the LD_PRELOAD variable and shadows other library
functions (read, write, printf and such).

The intercepted functions do a dlsym with the RTLD_NEXT parameter on the
name of the actual function - then they are called. This gives me the
possibilty to hook code in before and after library calls and maybe
change the return value of those.

Anyways, it's working nicely with open(), close(), read(), write() and
such, but then I tried select() - suddenly the compiler complains:


$ gcc -O2 -Wall -fPIC -shared -ldl -o libtrapper.so libtrapper.c Custom.o
libtrapper.c:155: error: conflicting types for ‘select’
/usr/include/gentoo-multilib/amd64/sys/select.h:112: error: previous
declaration of ‘select’ was here
make: *** [libtrapper.so] Error 1

Well, of course I redefine it - however with different parameters. I
always use void* in my declaration. I know it is not 100% correct, but
it works (at least on x86_64) - but how do I convince gcc to compile the
code anyways?

Regards,
Johannes

--
"PS: Ein Realname wäre nett. Ich selbst nutze nur keinen, weil mich die
meisten hier bereits mit Namen kennen." -- Markus Gronotte aka Makus /
Kosst Amojan / maqqusz / Mr. G / Ferdinand Simpson / Quartillia
Rosenberg in dse <45608268$0$5719$9b4e6d93@newsspool3.arcor-online.net>

Johannes Bauer wrote:
[color=blue]
> Well, of course I redefine it - however with different parameters. I
> always use void* in my declaration. I know it is not 100% correct, but
> it works (at least on x86_64) - but how do I convince gcc to compile the
> code anyways?
>[/color]

why don't you use the correct parameters?

--
SF

Games are very educational. Scrabble teaches us vocabulary, Monopoly teaches
us cash-flow management, and Dungeons & Dragons teaches us to loot dead bodies.

On Mar 8, 7:44 pm, Johannes Bauer <dfnsonfsdu...@gmx.de> wrote:
[color=blue]
> Well, of course I redefine it - however with different parameters.[/color]

This it not legal. C does not permit two functions to have the same
name, nor does it permit a single function to have inconsistent
parameters.
[color=blue]
> I
> always use void* in my declaration. I know it is not 100% correct, but
> it works (at least on x86_64) - but how do I convince gcc to compile the
> code anyways?[/color]

You can't. The code is simply not sensible. Why do you say "it works"
when it generates a compiler error? It doesn't work at all.

DS

Dildo Bogumil di Boscopelo schrieb:
[color=blue]
> why don't you use the correct parameters?[/color]

Because then the code generator needs to know the exact prototype -
which it doesn't. It doesn't need to look into the data, just pass on
the pointer. The function handling the data then might include the
headers and interpret the pointer correctly.

Greetings,
Johannes

--
"PS: Ein Realname wäre nett. Ich selbst nutze nur keinen, weil mich die
meisten hier bereits mit Namen kennen." -- Markus Gronotte aka Makus /
Kosst Amojan / maqqusz / Mr. G / Ferdinand Simpson / Quartillia
Rosenberg in dse <45608268$0$5719$9b4e6d93@newsspool3.arcor-online.net>

David Schwartz schrieb:[color=blue]
> On Mar 8, 7:44 pm, Johannes Bauer <dfnsonfsdu...@gmx.de> wrote:
>[color=green]
>> Well, of course I redefine it - however with different parameters.[/color]
>
> This it not legal. C does not permit two functions to have the same
> name, nor does it permit a single function to have inconsistent
> parameters.[/color]

I know it is not correct C. However I also know that at least on x86_64
compiled with gcc all pointers (including function pointers) have the
same length (64 bits) which is exactly the length of a void*. It
shouldn't matter for the prototype.
[color=blue][color=green]
>> I
>> always use void* in my declaration. I know it is not 100% correct, but
>> it works (at least on x86_64) - but how do I convince gcc to compile the
>> code anyways?[/color]
>
> You can't. The code is simply not sensible. Why do you say "it works"
> when it generates a compiler error? It doesn't work at all.[/color]

It only generates a compiler error if I include the appropriate header
files - which I usually don't. For some functions, however, I need to
include them. Apart from you thinking the code is sensible or not - how
do I force the compiler to compile it anyways? Is there no way to
undefine a prototype?

Regards,
Johannes

--
"PS: Ein Realname wäre nett. Ich selbst nutze nur keinen, weil mich die
meisten hier bereits mit Namen kennen." -- Markus Gronotte aka Makus /
Kosst Amojan / maqqusz / Mr. G / Ferdinand Simpson / Quartillia
Rosenberg in dse <45608268$0$5719$9b4e6d93@newsspool3.arcor-online.net>

On Mar 10, 11:58 am, Johannes Bauer <dfnsonfsdu...@gmx.de> wrote:
[color=blue]
> It only generates a compiler error if I include the appropriate header
> files - which I usually don't. For some functions, however, I need to
> include them. Apart from you thinking the code is sensible or not - how
> do I force the compiler to compile it anyways? Is there no way to
> undefine a prototype?[/color]


Although I don't recommend it, you can do things like:

#define select(a,b,c,d,e) select(void *)
#include <unistd.h>
#undef select

Now, it's as if unistd.h made the declaration:
extern int select( void *);

Johannes Bauer <dfnsonfsduifb@gmx.de> writes:[color=blue]
> David Schwartz schrieb:[color=green]
>> On Mar 8, 7:44 pm, Johannes Bauer <dfnsonfsdu...@gmx.de> wrote:[/color][/color]

[...]
[color=blue][color=green][color=darkred]
>>> I
>>> always use void* in my declaration. I know it is not 100% correct, but
>>> it works (at least on x86_64) - but how do I convince gcc to compile the
>>> code anyways?[/color]
>> You can't. The code is simply not sensible. Why do you say "it works"
>> when it generates a compiler error? It doesn't work at all.[/color]
>
> It only generates a compiler error if I include the appropriate header
> files - which I usually don't. For some functions, however, I need to
> include them.[/color]

"It only generates a compiler error if I want to compile incorrect
code" ...
[color=blue]
> Apart from you thinking the code is sensible or not -
> how do I force the compiler to compile it anyways?[/color]

.... "and how can I force the compiler to compile the incorrect code"?
The answer is 'not at all': Because the code is incorrect, no compiler
can possibly compile it to anything, because it has no defined
meaning. If you want to "fix" this, you have to change the
compiler. The usual course of action would be to fix the code the
compiler doesn't compile, for obvious reasons.

C still supports the possibility to declare a function with an
unspecified parameter list (actually, an emtpy 'identifier list'), eg

int select();

and any call to such a function will, in absence of other
informations, result in performing the 'default argument promotions'
on the actual parameters (any integer smaller than int is either
converted to int or unsigned, depending on representability of the
value, floats are converted to doubles) and then just invoke the
subroutine with them

William Pursell schrieb:
[color=blue]
> Although I don't recommend it, you can do things like:
>
> #define select(a,b,c,d,e) select(void *)
> #include <unistd.h>
> #undef select[/color]

Ah! Thank you. That's the solution I was looking for.

Kind regards,
Johannes

--
"PS: Ein Realname wäre nett. Ich selbst nutze nur keinen, weil mich die
meisten hier bereits mit Namen kennen." -- Markus Gronotte aka Makus /
Kosst Amojan / maqqusz / Mr. G / Ferdinand Simpson / Quartillia
Rosenberg in dse <45608268$0$5719$9b4e6d93@newsspool3.arcor-online.net>

Rainer Weikusat schrieb:
[color=blue][color=green]
>> Apart from you thinking the code is sensible or not -
>> how do I force the compiler to compile it anyways?[/color]
>
> ... "and how can I force the compiler to compile the incorrect code"?
> The answer is 'not at all': Because the code is incorrect, no compiler
> can possibly compile it to anything, because it has no defined
> meaning. If you want to "fix" this, you have to change the
> compiler. The usual course of action would be to fix the code the
> compiler doesn't compile, for obvious reasons.[/color]

*sigh*

Actually, I had here a paragraph about what I need and do not need to
do. About what gcc assumes about pointer types (which I happen to know).
I deleted it. It's pretty pointless.

Williams hack does what I want to be done. Period.
[color=blue]
> C still supports the possibility to declare a function with an
> unspecified parameter list (actually, an emtpy 'identifier list'), eg
>
> int select();
>
> and any call to such a function will, in absence of other
> informations, result in performing the 'default argument promotions'
> on the actual parameters (any integer smaller than int is either
> converted to int or unsigned, depending on representability of the
> value, floats are converted to doubles) and then just invoke the
> subroutine with them[/color]

This doesn't help me, however, as I need to access the parameters within
the function, not just make the call possible.

Regards,
Johannes

--
"PS: Ein Realname wäre nett. Ich selbst nutze nur keinen, weil mich die
meisten hier bereits mit Namen kennen." -- Markus Gronotte aka Makus /
Kosst Amojan / maqqusz / Mr. G / Ferdinand Simpson / Quartillia
Rosenberg in dse <45608268$0$5719$9b4e6d93@newsspool3.arcor-online.net>

Johannes Bauer <dfnsonfsduifb@gmx.de> writes:[color=blue]
> Rainer Weikusat schrieb:
>[color=green][color=darkred]
>>> Apart from you thinking the code is sensible or not -
>>> how do I force the compiler to compile it anyways?[/color]
>> ... "and how can I force the compiler to compile the incorrect code"?
>> The answer is 'not at all': Because the code is incorrect, no compiler
>> can possibly compile it to anything, because it has no defined
>> meaning. If you want to "fix" this, you have to change the
>> compiler. The usual course of action would be to fix the code the
>> compiler doesn't compile, for obvious reasons.[/color]
>
> *sigh*
>
> Actually, I had here a paragraph about what I need and do not need to
> do.[/color]

You believe that you need a language which is not C to express
something you would like a computer to do, but you want to use a
C-compiler to compile code written in this language. This doesn't make
sense, and that you don't understand why it doesn't make sense does
not cause it to make more sense.

[...]
[color=blue]
> Williams hack does what I want to be done. Period.[/color]

And this 'hack' does exactly what I had written above: It uses the
preprocessor to modify a specific declaration in the incorrect code
you would like to feed into a C-compiler for some unknown reason such
that the code is again correct, assuming that this particular textual
substitution does not cause any other issues (which would need to be
checked by examining all headers in its 'scope').

In other words: As soon as you fix your incorrect code, it magically
compiles, which is what you want.

[color=blue][color=green]
>> C still supports the possibility to declare a function with an
>> unspecified parameter list (actually, an emtpy 'identifier list'), eg
>> int select();
>> and any call to such a function will, in absence of other
>> informations, result in performing the 'default argument promotions'
>> on the actual parameters (any integer smaller than int is either
>> converted to int or unsigned, depending on representability of the
>> value, floats are converted to doubles) and then just invoke the
>> subroutine with them[/color]
>
> This doesn't help me, however, as I need to access the parameters
> within the function, not just make the call possible.[/color]

Dear imbecile. a function declaration cannot 'access parameters'
because it is a declaration and not a definition.

Rainer Weikusat schrieb:
[color=blue]
> In other words: As soon as you fix your incorrect code, it magically
> compiles, which is what you want.[/color]

There might as well have been a switch for gcc to ignore inconsistent
prototypes. This might qualify as broken code, yet the resulting
assembly would in no way be different. Pointers do not have a type at
machine level (at least on x86_64 they don't).
[color=blue][color=green][color=darkred]
>>> C still supports the possibility to declare a function with an
>>> unspecified parameter list (actually, an emtpy 'identifier list'), eg
>>> int select();
>>> and any call to such a function will, in absence of other
>>> informations, result in performing the 'default argument promotions'
>>> on the actual parameters (any integer smaller than int is either
>>> converted to int or unsigned, depending on representability of the
>>> value, floats are converted to doubles) and then just invoke the
>>> subroutine with them[/color]
>> This doesn't help me, however, as I need to access the parameters
>> within the function, not just make the call possible.[/color]
>
> Dear imbecile. a function declaration cannot 'access parameters'
> because it is a declaration and not a definition.[/color]

Your "solution" is not helpful, as it does not change the need to use
preprocessor magic. I was talking about the function definition, not the
declaration.

I also might note that your derogatory style of writing and your
oh-so-whitty comments are sickening. You might notice that not all
people besides you are morons some day. Your postings would be of much
more easy reading when you could suppress that kind of insulting drivel.

Regards,
Johannes

--
"PS: Ein Realname wäre nett. Ich selbst nutze nur keinen, weil mich die
meisten hier bereits mit Namen kennen." -- Markus Gronotte aka Makus /
Kosst Amojan / maqqusz / Mr. G / Ferdinand Simpson / Quartillia
Rosenberg in dse <45608268$0$5719$9b4e6d93@newsspool3.arcor-online.net>

On Mar 10, 4:58 am, Johannes Bauer <dfnsonfsdu...@gmx.de> wrote:
[color=blue]
> I know it is not correct C. However I also know that at least on x86_64
> compiled with gcc all pointers (including function pointers) have the
> same length (64 bits) which is exactly the length of a void*. It
> shouldn't matter for the prototype.[/color]

It is almost always a mistake to take "magic platform knowledge" and
try to write C code based on it. The length of pointers is not the
only possible way this can go wrong. What happens, if with the next
version of the C compiler, the total size of all parameters becomes
part of the calling convention when it is known?

DS

David Schwartz schrieb:[color=blue]
> On Mar 10, 4:58 am, Johannes Bauer <dfnsonfsdu...@gmx.de> wrote:
>[color=green]
>> I know it is not correct C. However I also know that at least on x86_64
>> compiled with gcc all pointers (including function pointers) have the
>> same length (64 bits) which is exactly the length of a void*. It
>> shouldn't matter for the prototype.[/color]
>
> It is almost always a mistake to take "magic platform knowledge" and
> try to write C code based on it. The length of pointers is not the
> only possible way this can go wrong. What happens, if with the next
> version of the C compiler, the total size of all parameters becomes
> part of the calling convention when it is known?[/color]

You're right, of course.

But the application is not intended to be portable. Not across different
platforms - not even across different versions of gcc or any of the
libraries it links my application against. Its a quick hack which I use
to reverse engineer some internals of a libusb-driver (no, ltrace is not
sufficient, it doesn't do what I need it to do).

I need to hack it once, get the data, never use it again. So, it is nice
if it is portable and well-written C - but it's definitely not a
requirement for this purpose. Broken, ugly C code is fully sufficient to
get the job done.

Kind regards,
Johannes

--
"PS: Ein Realname wäre nett. Ich selbst nutze nur keinen, weil mich die
meisten hier bereits mit Namen kennen." -- Markus Gronotte aka Makus /
Kosst Amojan / maqqusz / Mr. G / Ferdinand Simpson / Quartillia
Rosenberg in dse <45608268$0$5719$9b4e6d93@newsspool3.arcor-online.net>

On Mon, 10 Mar 2008 15:45:07 +0100 Johannes Bauer <dfnsonfsduifb@gmx.de> wrote:
| William Pursell schrieb:
|
|> Although I don't recommend it, you can do things like:
|>
|> #define select(a,b,c,d,e) select(void *)
|> #include <unistd.h>
|> #undef select
|
| Ah! Thank you. That's the solution I was looking for.

OK, so that works. It's a hack. What I'm curious about is why you could
not just define select to match the library declaration? Are you trying
to make this an intercept function that just passes on the arguments AND
can work no matter which way the function is declared/defined by libc?

--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / [email]spamtrap-2008-03-11-2039@ipal.net[/email] |
|------------------------------------/-------------------------------------|

On Mon, 10 Mar 2008 16:41:12 +0100 Johannes Bauer <dfnsonfsduifb@gmx.de> wrote:
| Rainer Weikusat schrieb:
|
|> In other words: As soon as you fix your incorrect code, it magically
|> compiles, which is what you want.
|
| There might as well have been a switch for gcc to ignore inconsistent
| prototypes. This might qualify as broken code, yet the resulting
| assembly would in no way be different. Pointers do not have a type at
| machine level (at least on x86_64 they don't).

Generally pointers would generate code the same way on the same machine.
But the C compiler is doing more than that. It is making sure that you
don't link up code that would use the pointer in different ways that are
not consistent with each other. C++ is worse.

I'm curious exactly what you are doing. If your code is open source or
otherwise not restricted, can you show it?

--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / [email]spamtrap-2008-03-11-2041@ipal.net[/email] |
|------------------------------------/-------------------------------------|

[email]phil-news-nospam@ipal.net[/email] schrieb:
[color=blue]
> OK, so that works. It's a hack. What I'm curious about is why you could
> not just define select to match the library declaration? Are you trying
> to make this an intercept function that just passes on the arguments AND
> can work no matter which way the function is declared/defined by libc?[/color]

Exactly. It's a code generator which just passes on pointers in the
gerneated code. It links together with user code which has knowledge
about the pointers (so it casts appropriately).

I've not thought about licensing the code itself, but if you want to see
it, I'd like to make it GPL-2. It's a ~1000 lines C++ program which
generates C code (that builds a shared lib which can be used to
LD_PRELOAD and reverse engineer certain other libraries/programs). Is
your mail valid? I'd send it to you then.

Regards,
Johannes

--
"PS: Ein Realname wäre nett. Ich selbst nutze nur keinen, weil mich die
meisten hier bereits mit Namen kennen." -- Markus Gronotte aka Makus /
Kosst Amojan / maqqusz / Mr. G / Ferdinand Simpson / Quartillia
Rosenberg in dse <45608268$0$5719$9b4e6d93@newsspool3.arcor-online.net>

On Mar 12, 7:53 am, Johannes Bauer <dfnsonfsdu...@gmx.de> wrote:

It's funny, you say this:
[color=blue]
> I've not thought about licensing the code itself, but if you want to see
> it, I'd like to make it GPL-2. It's a ~1000 lines C++ program which
> generates C code (that builds a shared lib which can be used to
> LD_PRELOAD and reverse engineer certain other libraries/programs). Is
> your mail valid? I'd send it to you then.[/color]

Yet you say this:
[color=blue]
> But the application is not intended to be portable. Not across different
> platforms - not even across different versions of gcc or any of the
> libraries it links my application against. Its a quick hack ...[/color]

So, you're going to GPL this for all the other people using the same
platform, same version of GCC, and the same libraries your application
links against?!

The moral is, never believe someone who says "it's not intended to be
portable", "it's a quick hack" or "nobody else will ever use this".
They're usually just lazy.

DS

David Schwartz schrieb:[color=blue]
> On Mar 12, 7:53 am, Johannes Bauer <dfnsonfsdu...@gmx.de> wrote:
>
> It's funny, you say this:
>[color=green]
>> I've not thought about licensing the code itself, but if you want to see
>> it, I'd like to make it GPL-2. It's a ~1000 lines C++ program which
>> generates C code (that builds a shared lib which can be used to
>> LD_PRELOAD and reverse engineer certain other libraries/programs). Is
>> your mail valid? I'd send it to you then.[/color]
>
> Yet you say this:
>[color=green]
>> But the application is not intended to be portable. Not across different
>> platforms - not even across different versions of gcc or any of the
>> libraries it links my application against. Its a quick hack ...[/color]
>
> So, you're going to GPL this for all the other people using the same
> platform, same version of GCC, and the same libraries your application
> links against?![/color]

Hey, someone asked for the code and I'm giving it away - what's wrong
with that? I do need the application for myself only, but will give it
away for free. Just because I choose the GPL for my code does not imply
that I'm distributing it (and I won't!)
[color=blue]
> The moral is, never believe someone who says "it's not intended to be
> portable", "it's a quick hack" or "nobody else will ever use this".
> They're usually just lazy.[/color]

Nope, you're wrong. I never ever intended to give the app away in the
first place - if someone asks, however, that's fine with me.

Regards,
Johannes

--
"PS: Ein Realname wäre nett. Ich selbst nutze nur keinen, weil mich die
meisten hier bereits mit Namen kennen." -- Markus Gronotte aka Makus /
Kosst Amojan / maqqusz / Mr. G / Ferdinand Simpson / Quartillia
Rosenberg in dse <45608268$0$5719$9b4e6d93@newsspool3.arcor-online.net>

On Mar 12, 12:06 pm, Johannes Bauer <dfnsonfsdu...@gmx.de> wrote:
[color=blue]
> Nope, you're wrong. I never ever intended to give the app away in the
> first place - if someone asks, however, that's fine with me.[/color]

You never intended to, but code has a way of being used outside the
designer's intentions.

The first thought is, "it's only ever going to be used on this
platform with this compiler, so there's no reason to make it
portable". The next thought is, "hey, maybe it works on this other
platform". Then, "hey, it seems to work, so let's use it". The next
thing you know, it breaks.

The best place to stop this chain is at the very first link. You
should need a damn good reason to do it wrong, not a good reason to do
it right.

DS

David Schwartz schrieb:[color=blue]
> The first thought is, "it's only ever going to be used on this
> platform with this compiler, so there's no reason to make it
> portable". The next thought is, "hey, maybe it works on this other
> platform". Then, "hey, it seems to work, so let's use it". The next
> thing you know, it breaks.
>
> The best place to stop this chain is at the very first link. You
> should need a damn good reason to do it wrong, not a good reason to do
> it right.[/color]

So essentialy what you're saying is that I should respond with "My code
is poorly written, I'm not giving it out" rather then "My code is poorly
written, do whatever you want with it" (as I did)?

I think when it is explicitly stated that the code is of poor quality,
full of ridiculous hacks and induces undefined behavior as of the
C-standard - what else would anyone expect who tried to use it other
than the code breaking? And why do you blame me for this?

Actually I do not think anyone seriously wants to use the code - maybe
take a peek, that's it. With the discussion here, all warnings are
pretty clear (and its being handed out to a reader of c.o.l.d.s., so I
guess he knows what he's doing).

Regards,
Johannes

--
"PS: Ein Realname wäre nett. Ich selbst nutze nur keinen, weil mich die
meisten hier bereits mit Namen kennen." -- Markus Gronotte aka Makus /
Kosst Amojan / maqqusz / Mr. G / Ferdinand Simpson / Quartillia
Rosenberg in dse <45608268$0$5719$9b4e6d93@newsspool3.arcor-online.net>