Thursday, March 23, 2017

Digest for comp.lang.c++@googlegroups.com - 25 updates in 8 topics

fir <profesor.fir@gmail.com>: Mar 22 11:59PM -0700

if you got a dll it is easy to read its export and import names (i use total commander plugin to see it), (this means that reversing dll is easier than reversing exe)
 
i wonder if it is realatively easy to read (probably by some disasemmbly) the number and size (and maybe partial type like if pointer or not) of arguments that those functions take
 
could someone put some light on it?
"Chris M. Thomasson" <invalid@invalid.invalid>: Mar 23 12:04AM -0700

On 3/22/2017 11:59 PM, fir wrote:
> if you got a dll it is easy to read its export and import names (i use total commander plugin to see it), (this means that reversing dll is easier than reversing exe)
 
Have you ever gave:
 
http://www.dependencywalker.com
 
a try ;^)
 
 
Christian Gollwitzer <auriocus@gmx.de>: Mar 23 08:23AM +0100

Am 23.03.17 um 07:59 schrieb fir:
 
> i wonder if it is realatively easy to read (probably by some
> disasemmbly) the number and size (and maybe partial type like if
> pointer or not) of arguments that those functions take
 
This information is not stored within the DLL typically, you will need
the header file. Only if you got debug information, then the full
signature is stored there. Since you are talking about DLL and EXE,
assuming Windows 64 bit, you can find the calling conventions here:
 
https://en.wikipedia.org/wiki/X86_calling_conventions#Microsoft_x64_calling_convention
 
Some arguments are passed in the registers, only if it is too much they
are passed via the stack. The return from the procedure can give you a
hint if it pops something off the stack, but otherwise you'll need to
read and understand the assembly code of the function.
 
BTW: Since this is all platform specific and independent of the
programming language, it is off topic here in clc++.
 
Christian
fir <profesor.fir@gmail.com>: Mar 23 01:12AM -0700

W dniu czwartek, 23 marca 2017 08:23:37 UTC+1 użytkownik Christian Gollwitzer napisał:
 
> BTW: Since this is all platform specific and independent of the
> programming language, it is off topic here in clc++.
 
> Christian
 
i know that.. (assume more 32 bit btw..) .. the question is if this this disasembly would be hard or easy (and how exactly it would be) as it is some kind of pattern that repeats same in each case you maybe not need whole analysis but something more simple.. (im not so much into it to know it just right away)
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Mar 23 09:15AM +0100

On 23-Mar-17 7:59 AM, fir wrote:
> if you got a dll it is easy to read its export and import names (i
> use total commander plugin to see it), (this means that reversing dll
> is easier than reversing exe)
 
There are a great many tools that do provide you with such lists: GNU's
objdump etc., Microsoft dumpbin, Borland's (whoever has it now) tdump,
Matt Pietrek's dump facility (pdump? I don't remember), etc. etc.
 
 
> i wonder if it is realatively easy to read (probably by some
> disasemmbly) the number and size (and maybe partial type like if
> pointer or not) of arguments that those functions take
 
That depends.
 
I think that often the total size is encoded in the name mangling. That
mangling depends on the compiler used, though.
 
More portably, /some/ DLLs provide a type library, and Windows provides
APIs to read type libraries, plus the OLE/COM object viewer tool. After
all that's what the type libraries are for, to provide this information.
But they're intended for scripting languages.
 
 
> could someone put some light on it?
 
As someone else mentioned, this has nothing to do with C++ as such,
except that if you want to invest unreasonably much work into code to
read type libraries then C++ is The Thing™, and it has nothing to do
with some earlier discussion in this group, so it's really off-topic.
 
 
Cheers!,
 
- Alf
Christian Gollwitzer <auriocus@gmx.de>: Mar 23 09:22AM +0100

Am 23.03.17 um 09:12 schrieb fir:
 
Some arguments are passed in the registers, only if it is too much they
> as it is some kind of pattern that repeats same in each case you
> maybe not need whole analysis but something more simple.. (im not so
> much into it to know it just right away)
 
So you want to write an automated code analyser which gives you the
number / type of parameters? This is most probably not possible. In 16
bit, it would be partly possible, because 16 bit x86 passes everything
on the stack. The return from the procedure cleans up the stack, so "ret
20" tells you that there are 5 16bit words as parameters. But for 32bit
and 64bit you are out of luck because the parameters are passed in
registers. This is one of the things that makes today's compilers fast.
They do not compute the args, then move to the registers and call the
function - instead the computation is adapted such that the parameters
end up in the corresponding registers. Therefore it would als be next to
impossible if you had a call site for the DLL for analysis.
 
Your best bet as a human reverse engineer would be to go to the
beginning of the procedure and note down, which parameters are first
touched, i.e. copied, used etc. If there are parameters on the stack,
you will see access to [rsp+xx] or the frame-pointer thingy mov %rsp,
%rbp and access to [rbp+xx].
 
Christian
Cholo Lennon <chololennon@hotmail.com>: Mar 23 09:53AM -0300

On 03/23/2017 03:59 AM, fir wrote:
> if you got a dll it is easy to read its export and import names (i use total commander plugin to see it), (this means that reversing dll is easier than reversing exe)
 
> i wonder if it is realatively easy to read (probably by some disasemmbly) the number and size (and maybe partial type like if pointer or not) of arguments that those functions take
 
> could someone put some light on it?
 
If you can get it, you can use a proprietary tool: IDA (the Interactive
DisAssembler), by far the best dissasembler out there (it has a debugger
too). Not only it is capable of disassemble a wide number of executable
files, but it also has the ability to convert detected functions to C
code (among other useful features).
 
Regards
 
--
Cholo Lennon
Bs.As.
ARG
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Mar 23 06:44AM -0700

On Thursday, March 23, 2017 at 2:59:33 AM UTC-4, fir wrote:
> if you got a dll it is easy to read its export and import names (i use total commander plugin to see it), (this means that reversing dll is easier than reversing exe)
 
> i wonder if it is realatively easy to read (probably by some disasemmbly) the number and size (and maybe partial type like if pointer or not) of arguments that those functions take
 
> could someone put some light on it?
 
It is not easily possible. That information is not contained within
the DLL in explicit form, so it must be derived. You must derive
the calling convention, the nuances of the caller/callee relationship.
You cannot know if the code was generated as custom assembly, or by
compiler output. There are hints and signs, but it's very difficult
to know in well-optimized code.
 
CAlive has addressed this by allowing compiler options for DLLs and
other forms of compiled binaries, including Manual, Limited, Extended,
and Full:
 
https://groups.google.com/d/msg/caliveprogramminglanguage/VE6omApXpUk/_evQOFQ2BAAJ
 
These will allow compile-time information to be conveyed through the
binary in a standard form that can be queried upon demand, sent through
standard parsing algorithms, which can yield information about what the
code contains.
 
Thank you,
Rick C. Hodgin
Bonita Montero <Bonita.Montero@gmail.com>: Mar 23 04:28PM +0100

When I first saw your posting I thought I'll read a recommendation
on how to analyze the DLL-exports by the help of the lord. ^^
 
--
http://facebook.com/bonita.montero/
"Chris M. Thomasson" <invalid@invalid.invalid>: Mar 23 01:56AM -0700

On 3/20/2017 6:13 AM, Chris Vine wrote:
> "Chris M. Thomasson" <invalid@invalid.invalid> wrote:
>> This queue can be spiced up with exotic C++ atomics and such, but for
>> now, lets focus on this simple construct:
[....]
> You might well want rate-limiting on a queue of this kind to prevent
> producers overrunning consumers. That introduces all sorts of other
> trade-offs.
 
Right. Well, I am thinking of a fun way to do this. We can add some
semaphore logic in the existing condvar-mutex relationship, or get rid
of the condvar for a semaphore. Hummm... Need to think here.
 
Are you familiar with the following "fast" semaphore logic, membars
aside for a moment, pseudo-code:
_________________________________________
struct fast_sem
{
int count = initial count;
slow_sem_os = os_sempahore with a count of zero;
 
dec() // wait
{
if (ATOMIC_DEC(&count) < 0) slow_sem_os.dec();
}
 
inc() // post
{
if (ATOMIC_INC(&count) <=0) slow_sem_os.inc();
}
};
_________________________________________
 
Pretty compact, and completely doable in std C++. ;^)
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Mar 23 02:44PM

On Thu, 23 Mar 2017 01:56:18 -0700
> };
> _________________________________________
 
> Pretty compact, and completely doable in std C++. ;^)
 
You could do it using semaphores, but for a queue of this kind
something more prosaic (using components provided by the standard
library) may be more in keeping. There are two common ways of doing
that. First, have producers block on a condition variable when the
queue reaches a given size, in the same way that consumers block when
the size is 0. Such devices are normally described as some form of
buffered channel. A second is to apply throttling to producers when
the queue exceeds a given size, with a delay that increases
non-linearly (say, quadratically or by cubically) once the threshold
has been hit. The second approach seems better for a queue implemented
using a list or deque, where the throttle size may be large (a queue of
this kind could easily take a million items if each item is small
enough, and it doesn't need a hard edge).
 
I do not think I can get as enthusiastic about this stuff as you are.
The original code you produced with the corrections I mentioned and the
kind of throttling I have described seems good enough to me for most
cases.
Andrey Karpov <karpov2007@gmail.com>: Mar 23 06:16AM -0700

Recently we published 2 articles about TOP 10 errors in C++ and C# projects found in 2016. We got very positive feedback and that made us think - why not to make such a top rating of bugs for a month? Our site has a huge base of errors that is well-structured and that we can use to choose bugs, which were detected during a certain period of time. In this article you will learn about the new blog section "Bug of the month" and how we prepared articles for it.
 
Continue read: https://www.viva64.com/en/b/0490/
kus <bhattacharya.kushal4@gmail.com>: Mar 23 10:49AM +0530

On Wednesday 22 March 2017 09:17 PM, Paavo Helde wrote:
>> i am getting segmentation fault.Why am i
>> getting this behaviour ?
 
> You have a bug in your code. My crystal ball says it is on line 447.
 
Haha ver funny
Paavo Helde <myfirstname@osa.pri.ee>: Mar 23 11:51AM +0200

On 23.03.2017 7:19, kus wrote:
>>> getting this behaviour ?
 
>> You have a bug in your code. My crystal ball says it is on line 447.
 
> Haha ver funny
 
Well, I think your original post was funny!
 
Do you really expect some serious answer if you for example post a
following question to a forum of doctors: "When I walk around the town
each day for say that many days then I suddenly feel there is something
seriously wrong with me. Why am I getting this behaviour?"
kushal bhattacharya <bhattacharya.kushal4@gmail.com>: Mar 23 03:13AM -0700

On Thursday 23 March 2017 03:21 PM, Paavo Helde wrote:
> following question to a forum of doctors: "When I walk around the town
> each day for say that many days then I suddenly feel there is something
> seriously wrong with me. Why am I getting this behaviour?"
 
Sorry my fault actually i totally apologise if my question was a lame one.Actually its a bad habit of mine and i promise i will sort it out
Paavo Helde <myfirstname@osa.pri.ee>: Mar 23 01:57PM +0200

On 23.03.2017 12:13, kushal bhattacharya wrote:
> Sorry my fault actually i totally apologise if my question was a lame one.Actually its a bad habit of mine and i promise i will sort it out
 
No problem, it's hard to step aside and see how your communication looks
for other people. Of course that does not mean that one should not try
to do better.
 
There are some suggestions about posting technical questions to c.l.c++
at http://www.dietmar-kuehl.de/mirror/c++-faq/how-to-post.html#faq-5.8
kus <bhattacharya.kushal4@gmail.com>: Mar 23 06:04PM +0530

On Thursday 23 March 2017 05:27 PM, Paavo Helde wrote:
> to do better.
 
> There are some suggestions about posting technical questions to c.l.c++
> at http://www.dietmar-kuehl.de/mirror/c++-faq/how-to-post.html#faq-5.8
 
HI,
seen all the FAQ's now
Thanks,
Kushal
"Chris M. Thomasson" <invalid@invalid.invalid>: Mar 22 04:32PM -0700

On 3/21/2017 11:45 PM, kushal bhattacharya wrote:
> Hi,
> Could anyone please guide me how to make detached thread in a loop.I am getting some errors making it.
 
What errors? Any why do you need them?
kushal bhattacharya <bhattacharya.kushal4@gmail.com>: Mar 23 03:15AM -0700

On Thursday, March 23, 2017 at 5:02:32 AM UTC+5:30, Chris M. Thomasson wrote:
> > Hi,
> > Could anyone please guide me how to make detached thread in a loop.I am getting some errors making it.
 
> What errors? Any why do you need them?
 
Actually i want to run those in background so that it doesnt inteferrs or disturb other operations
kus <bhattacharya.kushal4@gmail.com>: Mar 23 03:15PM +0530

Hi,
As many of the readers have read from my precious posts,
this post deals with issue of multithreading.So,
my question is which type of container should i use so that from one
thread i am doing only write operation on the thread.But other threads,
just either perform modification on that container(it maybe update on
the element or removal of element according to condtion satisfied)or
read operation on the container.In most of the cases,using stl
containers like deque and vector am not able to eradicate the issue of
invariant broken thus causing segmentation fault.So,what strategy should
i use and which container suits best for the situation?
kus <bhattacharya.kushal4@gmail.com>: Mar 23 03:23PM +0530

On Thursday 23 March 2017 03:15 PM, kus wrote:
> containers like deque and vector am not able to eradicate the issue of
> invariant broken thus causing segmentation fault.So,what strategy should
> i use and which container suits best for the situation?
Sorry for the grammatical errors
bitrex <bitrex@de.lete.earthlink.net>: Mar 22 11:47PM -0400

My main struggle with learning C++1x coming from languages like straight
C and Python is that I might have what I think is a good idea for a
particular software design, but then while attempting to implement it I
find myself bogged down for an afternoon in Stack Overflow posts about
the particulars of performance issues in the "copy and swap" idiom and
blog debates about whether the constructor of a superclass should be
inherited this way or that and I look at my code and ask myself "Um,
will any of this stuff I just did perform well in practice or even
idiomatic or 'correct' in any way at all?
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Mar 23 05:27AM +0100

On 23-Mar-17 4:47 AM, bitrex wrote:
> inherited this way or that and I look at my code and ask myself "Um,
> will any of this stuff I just did perform well in practice or even
> idiomatic or 'correct' in any way at all?
 
How about just ask about one particular concrete problem, with code
(that is complete enough that) that readers can try?
 
Stack Overflow can be a good place to ask about some definite-answer
question, but for the more vague stuff, where you'd like some back and
forth discussion, try this group or e.g. a Reddit or Facebook group.
 
Keep in mind that C++ started as nothing more than /language support/
for certain idiomatic ways to use C. As I recall Bjarne was implementing
simulations with queues, so he needed classes. Oh, yes there's Simula,
that silly verbose Norwegian programming language, it fits this problem
domain, I'll just implement the Simula stuff in C. Oh gosh (whatever,
some exclamation) even with my crafty macros that's a heck of a lot of
boilerplate code, not to mention the casts, repeated all over the place!
I'd better make my own C extension to deal with all of that, grumble...,
let's call it, say, "C with classes", yes... to work!
 
 
Cheers!,
 
- Alf
Bo Persson <bop@gmb.dk>: Mar 23 10:36AM +0100

On 2017-03-23 04:47, bitrex wrote:
> inherited this way or that and I look at my code and ask myself "Um,
> will any of this stuff I just did perform well in practice or even
> idiomatic or 'correct' in any way at all?
 
Start with the 'correct' part. If the program doesn't do what it is
supposed to, it doesn't matter how fast it is.
 
And most parts of a program (97%?) are not important performance-wise.
Like if you create an object once in a program, how fast does the
constructor need to be?
 
Just wait until you see that some parts are not fast enough, and then
look for possible optimizations there. And only there.
 
Remember:
 
"Premature optimization is the root of all evil" (Donald Knuth)
 
https://en.wikiquote.org/wiki/Donald_Knuth#Quotes_about_Donald_Knuth
 
 
 
Bo Persson
"Chris M. Thomasson" <invalid@invalid.invalid>: Mar 22 11:50PM -0700

On 3/21/2017 5:23 PM, Chris M. Thomasson wrote:
> highly efficient queues. Databases are another one. Take the following
> talk into account:
 
> https://youtu.be/qcD2Zj9GgI4
 
I forgot to mention that this is a CppCon 2016 talk from Paul E.
McKenney on sophisticated and efficient means to manipulate a binary
tree wrt the Issaquah Challenge.
 
Slides can be found here:
 
http://www.rdrop.com/users/paulmck/scalability/paper/Updates.2015.01.16b.LCA.pdf
 
 
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)