[llvm-dev] what does read-only data section consist?

[Kenneth Adam Miller via llvm-dev]

This mailing list probably isn't suited to answer your question.

Perhaps the reddit reverseengineering community can help you with this,
since what you ask is more concerned with data sections according to what
is defined by source.

In any case, the size of the read only data section can be reverse
engineered as it is on disk with something like CFF explorer, and you can
estimate from what that returns what it will be in memory, which is usually
the next highest page size multiple.

What is defined by source doesn't usually establish any strict
correspondence as to what actually happens with the final binary, as since
compilers span languages and decades of development it's unlikely that
there's consistency in terms of where what will be placed or the name of
the section or just about anything except the mere minimum that the OS
needs in order to load and execute the result.

On Mon, Oct 19, 2015 at 4:19 AM, 慕冬亮 via llvm-dev <llvm-dev at lists.llvm.org>
wrote:

> In C language programming, which content of variable will store in
> read-only data section?
>
> void func( int i ){
>     printf("%d\n", i);
> }
>
> int main()
> {
>     const str = "const string";
>     int b;
>
>     func(b);
>     return 0;
> }
>
> Look at the program before, what, I already know, will be stored in
> read-only data section is constant string like "const str = "const
> string"", jump table(switch ... case), printf/scanf fomat string like
> "%d\n".
>
> What do I miss? And for a ordinary application, what's the size of
> read-only data section?
> Is there any difference between GCC with LLVM about the content of
> read-only data section?
>
> Thanks in advance.
>     - mudongliang
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151019/e4be256b/attachment.html>