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
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)
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
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 ma
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 oth
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/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 my
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'
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 start_
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 i
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 unde
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 ru
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 source
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 source
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 cleare
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 lat
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:
http://www.linuxforums.org/articles/understanding-elf-using-readelf-and
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 my
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 "copy&paste" all the code from your messages i
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& L
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~
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 recomm
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 pie
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, an
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 "copy&paste" all the code from your messages into patches and then
> applying them? Can
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 binar
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
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 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 lear
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 ad
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 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 understa
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 hav
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
und
Pardon me for any possibly stupid answer...so here we come :)
On Mon, Jan 24, 2011 at 18:34, Stefano Bonifazi
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 qemu-user) should
Hi!
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 the need to relocate the target code in the me
36 matches
Mail list logo
