On 01/25/2011 02:36 AM, Richard Henderson wrote:
On 01/24/2011 01:44 PM, Stefano Bonifazi wrote:
Wow wonderful! So you fixed the code for PIC (ET_DYN) support?
Yes.
how can I get your sources?
I was mistaken -- a later version of the patch set was in fact merged.
I simply forgot to delete
On 01/26/2011 03:07 AM, Stefano Bonifazi wrote:
P.S. Please just answer that last question, whether it is possible to
have a variable showing the upper bound of heap (some brk_end) for a
target process
No, the heap grows until it reaches some other memory mapped entity.
r~
On 01/26/2011 04:38 PM, Richard Henderson wrote:
On 01/26/2011 03:07 AM, Stefano Bonifazi wrote:
P.S. Please just answer that last question, whether it is possible to
have a variable showing the upper bound of heap (some brk_end) for a
target process
No, the heap grows until it reaches some
Richard Henderson writes:
On 01/26/2011 03:07 AM, Stefano Bonifazi wrote:
P.S. Please just answer that last question, whether it is possible to
have a variable showing the upper bound of heap (some brk_end) for a
target process
No, the heap grows until it reaches some other memory mapped
On 01/26/2011 12:17 PM, Lluís wrote:
Richard Henderson writes:
On 01/26/2011 03:07 AM, Stefano Bonifazi wrote:
P.S. Please just answer that last question, whether it is possible to
have a variable showing the upper bound of heap (some brk_end) for a
target process
No, the heap grows
On 01/26/2011 09:19 PM, Richard Henderson wrote:
On 01/26/2011 12:17 PM, Lluís wrote:
Richard Henderson writes:
On 01/26/2011 03:07 AM, Stefano Bonifazi wrote:
P.S. Please just answer that last question, whether it is possible to
have a variable showing the upper bound of heap (some brk_end)
Richard Henderson writes:
On 01/26/2011 12:17 PM, Lluís wrote:
Richard Henderson writes:
On 01/26/2011 03:07 AM, Stefano Bonifazi wrote:
P.S. Please just answer that last question, whether it is possible to
have a variable showing the upper bound of heap (some brk_end) for a
target
On 01/25/2011 01:06 AM, Mike Frysinger wrote:
On Mon, Jan 24, 2011 at 11:29, Mulyadi Santosa wrote:
I wrote an article about understanding ELF years ago, here is the URL:
http://www.linuxforums.org/articles/understanding-elf-using-readelf-and-objdump_125.html
i also highly recommend Linkers
On 01/25/2011 12:32 AM, Mike Frysinger wrote:
On Mon, Jan 24, 2011 at 16:44, Stefano Bonifazi wrote:
http://lists.gnu.org/archive/html/qemu-devel/2010-07/msg01626.html
A noob question, how can I get your sources? Is there a simpler solution
than copypaste all the code from your messages
On 01/25/2011 02:36 AM, Richard Henderson wrote:
On 01/24/2011 01:44 PM, Stefano Bonifazi wrote:
Wow wonderful! So you fixed the code for PIC (ET_DYN) support?
Yes.
how can I get your sources?
I was mistaken -- a later version of the patch set was in fact merged.
I simply forgot to delete
On 01/25/2011 01:18 AM, Mike Frysinger wrote:
On Mon, Jan 24, 2011 at 19:06, Mike Frysinger wrote:
On Mon, Jan 24, 2011 at 11:29, Mulyadi Santosa wrote:
I wrote an article about understanding ELF years ago, here is the URL:
On Tue, Jan 25, 2011 at 03:47, Stefano Bonifazi wrote:
On 01/25/2011 02:36 AM, Richard Henderson wrote:
On 01/24/2011 01:44 PM, Stefano Bonifazi wrote:
Wow wonderful! So you fixed the code for PIC (ET_DYN) support?
Yes.
how can I get your sources?
I was mistaken -- a later version of the
Sorry.. merged with qemu? What version? I have qemu.0.13.0 and there are no
your fixes..
How can I get the fixed qemu sources?
you probably want to use the latest git tree
http://git.qemu.org/qemu.git/
-mike
Wow man! I got your work through the git!
Very good job! Now everything is much
On 01/25/2011 09:53 AM, Mike Frysinger wrote:
On Tue, Jan 25, 2011 at 03:47, Stefano Bonifazi wrote:
On 01/25/2011 02:36 AM, Richard Henderson wrote:
On 01/24/2011 01:44 PM, Stefano Bonifazi wrote:
Wow wonderful! So you fixed the code for PIC (ET_DYN) support?
Yes.
how can I get your
On 01/25/2011 09:53 AM, Mike Frysinger wrote:
On Tue, Jan 25, 2011 at 03:47, Stefano Bonifazi wrote:
On 01/25/2011 02:36 AM, Richard Henderson wrote:
On 01/24/2011 01:44 PM, Stefano Bonifazi wrote:
Wow wonderful! So you fixed the code for PIC (ET_DYN) support?
Yes.
how can I get your
On 01/25/2011 02:47 AM, Stefano Bonifazi wrote:
You keep getting the name of the dynamic linker from the PT_INTERP program
segment, but that gives you the absolute position of the dynamic linker
inside the machine the target binary was created in.
Here qemu-user is an emultaor used for
On 01/25/2011 03:06 AM, Stefano Bonifazi wrote:
start_brk 0x
end_code0x400102e0
start_code 0x4000
start_data 0x4001024c
end_data0x400102e0
start_stack 0x40811438
brk 0x400102e4
entry 0x40828c24
that is start_brk is 0
As far as I understood brk is the
On 01/25/2011 05:22 PM, Richard Henderson wrote:
On 01/25/2011 02:47 AM, Stefano Bonifazi wrote:
You keep getting the name of the dynamic linker from the PT_INTERP program
segment, but that gives you the absolute position of the dynamic linker inside
the machine the target binary was created
On 01/25/2011 05:26 PM, Richard Henderson wrote:
On 01/25/2011 03:06 AM, Stefano Bonifazi wrote:
start_brk 0x
end_code0x400102e0
start_code 0x4000
start_data 0x4001024c
end_data0x400102e0
start_stack 0x40811438
brk 0x400102e4
entry 0x40828c24
that is
Stefano Bonifazi writes:
Is there a heap end address? Is it possible to set it someway? It
would be really very helpful for me!!
See the man page for brk(2):
Calling sbrk() with an increment of 0 can be used to find the
current location of the program break.
Lluis
--
And it's
Pardon me for any possibly stupid answer...so here we come :)
On Mon, Jan 24, 2011 at 18:34, Stefano Bonifazi
stefboombas...@gmail.com wrote:
First of all:
info-start_mmap = (abi_ulong)ELF_START_MMAP;
What is this?
Start address in which address the ELF code section, in reality (not
under
Hi!
Thank you for answering me!
Start address in which address the ELF code section, in reality (not
under qemu-user) should be mapped. in x86 32 bit it's 08048000, you
can check it by yourself by executing:
cat /proc/self/maps
Wait, like that I don't understand anything more.. As far as I
On 01/24/2011 03:34 AM, Stefano Bonifazi wrote:
I am working on a project based on qemu-user. More exactly it is
qemu-ppc (version 0.13.0) with x86 host. All the project and
documentation about qemu will be open for everybody as it is a
project for my university that is a public one.. I have
On Mon, Jan 24, 2011 at 13:16, Stefano Bonifazi wrote:
Start address in which address the ELF code section, in reality (not
under qemu-user) should be mapped. in x86 32 bit it's 08048000, you
can check it by yourself by executing:
cat /proc/self/maps
Wait, like that I don't understand
Hi!
Thank you for your answer!
he is telling you what ELF_START_MMAP is all about. it is the base
address that the linux kernel for that architecture will start giving
out addresses. so when running Linux on an x86 system, the first
mmap() a process does will start at 0x8000 and move up.
On Mon, Jan 24, 2011 at 15:58, Stefano Bonifazi wrote:
review the mmap() man page ... MAP_FIXED is always a *suggestion* and
never a requirement. the app must check the return value to see what
the kernel actually gave it.
Sorry, wrong!
MAP_FIXED
Don't interpret addr as a
but that can happen with the app running natively too, so any app not
handling MAP_FIXED failures is buggy and not qemu's problem.
-mike
How? For what I learned each process executing on a OS with an mmu sees
its virtual address space, and normally only its code is loaded there
(well I am
On Mon, Jan 24, 2011 at 17:24, Stefano Bonifazi wrote:
how can the ldso possibly prevent clashes ? it has no idea what
addresses an app will ask for at runtime.
plus, if the kernel is employing ASLR (which isnt uncommon nowadays),
the load addresses could be anywhere.
Well not alone, in my
how can the ldso possibly prevent clashes ? it has no idea what
addresses an app will ask for at runtime.
plus, if the kernel is employing ASLR (which isnt uncommon nowadays),
the load addresses could be anywhere.
-mike
Well not alone, in my mind ld.so asks the memory manager through calling
Yes. Have a look at
http://lists.gnu.org/archive/html/qemu-devel/2010-07/msg01626.html
where I tried to clean this up last year. The patch never got properly
reviewed, however.
All that said, unless you have an executable that's been properly
prepared for relocation, e.g. an ET_DYN
On Mon, Jan 24, 2011 at 16:44, Stefano Bonifazi wrote:
http://lists.gnu.org/archive/html/qemu-devel/2010-07/msg01626.html
A noob question, how can I get your sources? Is there a simpler solution
than copypaste all the code from your messages into patches and then
applying them? Can you just
On Mon, Jan 24, 2011 at 16:52, Stefano Bonifazi wrote:
but that can happen with the app running natively too, so any app not
handling MAP_FIXED failures is buggy and not qemu's problem.
How? For what I learned each process executing on a OS with an mmu sees its
virtual address space, and
On Mon, Jan 24, 2011 at 11:29, Mulyadi Santosa wrote:
I wrote an article about understanding ELF years ago, here is the URL:
http://www.linuxforums.org/articles/understanding-elf-using-readelf-and-objdump_125.html
i also highly recommend Linkers Loaders:
http://linker.iecc.com/
some
On Mon, Jan 24, 2011 at 19:06, Mike Frysinger wrote:
On Mon, Jan 24, 2011 at 11:29, Mulyadi Santosa wrote:
I wrote an article about understanding ELF years ago, here is the URL:
http://www.linuxforums.org/articles/understanding-elf-using-readelf-and-objdump_125.html
i also highly recommend
On 01/24/2011 01:44 PM, Stefano Bonifazi wrote:
Wow wonderful! So you fixed the code for PIC (ET_DYN) support?
Yes.
how can I get your sources?
I was mistaken -- a later version of the patch set was in fact merged.
I simply forgot to delete my working branch afterward.
r~
35 matches
Mail list logo
