On Thu, Aug 02, 2018 at 01:27:16AM +0000, Chris Co wrote:
> > > The 'data.load.elf' statement in
> > > PeCoffLoaderRelocateImageExtraAction() is particular to Lauterbach
> >
> > Oh, right.
> >
> > That (original) code badly needs reformatting.
> >
> > Still, if that's the only difference - and in a debug printout, why fork the
> > module?
> >
> > If there is a way to identify which debugger is being used, use that.
> > If not, dump all the possible strings.
>
> Currently I didn't find a way to identify the debugger being used.
Well, it was worth a shot.
> Default behavior of the original code assumes ARM platforms use DS5
> debugger. I could introduce a PCD or compile flag so the developer
> can indicate DS5 vs Lauterbach debugger and key the debug print off
> of that.
That would certainly be preferable over keeping a separate copy.
If we find a way to determine dynamically, that would be better.
Maybe it could even be worth to have a dynamic pcd and a menu setting,
defaulting to just printing module names and addresses/sizes if no
specific debugger has been selected? (Where the default could be
platform-specific.)
I have some theory about adding information to qemu fw_cfg to let EDK2
know it's being debugged, but clearly that won't help real platforms.
> Regarding dumping all possible strings, I am not sure exactly how
> the DS5 output string is being used. i.e. does the DS5 software
> receive the serial info directly? If so, does it expect to see a
> specific format? Is the software resilient enough that it can
> handle the Lauterbach spew on the same channel?
So, this predates my involvement with edk2 - but I think it was just
added so you could copy/paste the command line needed to get symbols
in your debugger for a specific file.
(I will note here that the DS5 syntax is also suspiciously like GDB
syntax.)
/
Leif
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.01.org/mailman/listinfo/edk2-devel
