Little late to the party, but I had qemu/efi/gdb debugging working pretty
well a while back to write some luks drive encryption support for efi.
>From my notes the best way to programmatically get all debug information at
once is to iterate the the loaded image protocols, get a list of image
offset
If you are using gdb all you really need is a very simple stub on the
target. GDB on the host side will query about what the stub supports. I
believe the minimum is very simple; read/write memory and registers and gdb
will take care of the rest. For instance if hw breakpoints exist gdb will
defa
| I know it's generally not a good idea to boot a physically installed OS,
but I want to try it anyway?
I did have this working years ago with XP (obviously not EFI) booting bare
metal and as a VM guest. Every time I went between bare metal and the VM
it would complain about activation being inval
What would this get you that just using the qemu built-in gdbserver doesn't?
On Sun, Apr 21, 2013 at 10:42 AM, Laszlo Ersek wrote:
> On 04/21/13 12:24, Piker Alpha wrote:
> > Laszio,
> >
> > I think that one of your links is broken. Shouldn't it be:
> >
> >
> http://www.intel.com/content/www/us
Why don't you have any gdb symbols? Is qemu actually hanging? Those
scripts from before should operate as long as the stub/gdbserver is running
which is part of qemu.
On Tue, Apr 16, 2013 at 5:07 PM, Duane Voth wrote:
> I'm seeing an application hang on termination in OVMF. I'm told this app
3, at 2:13 PM, Duane Voth wrote:
>
> previous thread was: [edk2] OVMF networking revisited
> Spliting off this gdb+qemu+ovmf debugging discussion.
> Versions:
> qemu-kvm 1.2.0
> gdb 7.5.1
> OVMF X64 built on Linux with GCC 4.6
>
> On Tue, Apr 9, 2
This is for the gdb issue not the acpi issue:
I looked at his scripts. They work by loading up his stub/app which isn't
actually running on the target and using the symbols provided by this
binary to use gdb to find the system table pointer (located top of mem -
x*0x40).
The error you are see
EFI_SYSTEM_TABLE_POINTER is loaded by DxeMain so it's only really valid
once you hit the dxe phase. Is acpi before of after that? I've got some
gdb python scripts I was working on that should work pretty easily but it
needs the loaded image protocols and efi_system_table_pointer to load
debugging
The biggest limitation is the edk build tools. It makes the assumption
that all of the code is inside the 'workspace' directory. There is no
reason why you can't just copy files and create your own make files, but
the edk buildtools have some auto generated files and automagically invoke
other to
Hi Gerd,
You can use the EfiRom tool from BaseTools.
e.g.: EfiRom -b -ec -f -i
-o
--Joe
On Wed, Feb 6, 2013 at 4:33 AM, Gerd Hoffmann wrote:
> Hi,
>
> > When you refer to .ROM file … is this just the EFI driver or is this
> > the combined EFI+Legacy Option ROM? You should not sign the
, sorry I was away for a while.
>
> ** **
>
> The image is created successfully. The only warning is:
>
> ** **
>
> LINK : warning LNK4001: no object files specified; libraries used.
>
> ** **
>
> Regards,****
>
> Savitha
>
> ** **
&g
What exactly prevents someone from distributing the fat32 code with other
products? I'm not sure I fully understand the additional terms of the
FAT32 license. What does the "directly managed by" ... “UEFI
Specifications”. Does that mean it can only be used in an EFI compliant
product or somethin
__fltused I think is a special symbol VS injects to load floating point
libraries. There are a few places where even when telling VS you are not
using the default crts it will still try to load symbols like this (another
being memcpy/memset off the top of my head). Both ieee754 and gdtoa deal
wit
Hi David,
It should be able to build under windows using VS2008. Can you copy paste
your build command as well as the output with error?
--Joe
On Wed, Jan 30, 2013 at 9:08 PM, David F. wrote:
> Hi,
>
> I downloaded the UDK2010.SR1.UP1 and tried to build x64 target under
> windows (VS2008) bu
e: [edk2] Driver Signing - Signtool error - Image size issue**
> **
>
> ** **
>
> ** **
>
> On Jan 22, 2013, at 7:06 PM, Joe Vernaci wrote:
>
>
>
>
>
> Can look at the actual size and header reported size of the binary files
> as they are processed post link
Can look at the actual size and header reported size of the binary files as
they are processed post linker, from MyDriver.dll to MyDriver.efi. The two
things off of the top of my head that can change the size of a executable
would be:
objcopy --strip-unneeded (gcc only and part of binutils)
or
Gen
at 7:11 PM, David Woodhouse wrote:
> On Sun, 2013-01-20 at 18:39 -0500, Joe Vernaci wrote:
> > AFAIK the __attribute__((packed)) only allows for unaligned member
> > accesses but assumes the root of the structure will be aligned.
>
> I have often wished that that were true (o
orting things that break the spec, but
it does boil down to the customer experience. Again this is still just
confined to Itanium/EBC at the moment.
--Joe
On Sun, Jan 20, 2013 at 4:02 PM, David Woodhouse wrote:
> On Sun, 2013-01-20 at 15:41 -0500, Joe Vernaci wrote:
> > Could this caus
onstant compares which from a C language standpoint
makes sense.
--Joe
On Sun, Jan 20, 2013 at 4:51 PM, Andrew Fish wrote:
>
> On Jan 20, 2013, at 12:18 PM, Joe Vernaci wrote:
>
> Hi Nikolai,
>
> I think your recast as a UINT32 is the correct change. From the UEFI spec
> 6.2 w
ur sample we get e_*s_neg
> > e_s_pos*
> while without cast *e_s_neg < e_s_pos*.
> It is not a method to work.
> EFI_MEMORY_TYPE must be defined as INT32 but not questionable enum.
>
> Sergey
>
> On 21.01.2013, at 0:18, Joe Vernaci wrote:
>
> Hi Nikolai,
>
>
Could this cause unaligned memory accesses? This is fine for x86/x86_64,
could cause a fault on Itanium, and will always cause a fault on EBC. It
would be a pretty remote use case but still could happen.
On Sun, Jan 20, 2013 at 1:41 PM, David Woodhouse wrote:
> The current vgabios images shippe
Hi Nikolai,
I think your recast as a UINT32 is the correct change. From the UEFI spec
6.2 when allocating "MemoryType values in the range 0x8000..0x
are reserved for use by UEFI OS loaders that are provided by operating
system vendors. The only illegal memory type values are those in
22 matches
Mail list logo
